Choosing components
We look at how mature the project is, how active the repository stays, how many maintainers it has, which licence applies and how easily developers already familiar with it can be found locally.
Open software removes two exposures at once: a licence bill that climbs with every new hire, and reliance on a vendor free to rewrite its price list or retire the product. That does not make it free. Instead of a licence you pay for skills and for the discipline of keeping things updated. Our job has two halves: doing that arithmetic honestly at your scale, then building on components somebody genuinely looks after.
Open does not mean maintenance-free. Part of what you save on licences has to go back into updates and security watch, or the bill returns later with interest.
We look at how mature the project is, how active the repository stays, how many maintainers it has, which licence applies and how easily developers already familiar with it can be found locally.
PostgreSQL, Linux, PHP with Laravel or Symfony, Python with Django, Keycloak for single sign-on, Metabase for dashboards. Ready-made pieces are used only where they genuinely fit.
Docker, automated builds and deployments, separate test and production environments. A release reaches the server the same way every time, with no hand-copied files on a Friday evening.
Automated dependency scanning and a software bill of materials. Buyers covered by NIS2 increasingly ask their suppliers for that document when assessing them.
We list the licence of every component, GPL, AGPL, MIT, Apache 2.0, and flag those that deserve attention given how you intend to use the software. The legal reading belongs to your lawyer, not to a technical supplier.
When we fix a defect in a library, the patch goes back to the original project. That saves you from maintaining a patched copy that drifts apart at the next release.
Development takes about as long as it would on a proprietary platform. The gap opens later, as user numbers grow while the licence bill stays exactly where it was.
We study the need and look for serious candidates. If the open equivalent falls clearly short on a decisive feature, we say so without dressing it up.
The technology is tried on a small, clearly bounded part of the need, before you commit to it for several years.
Development on components with active maintainers that publish security fixes on a regular, verifiable rhythm.
Code, an architecture description, the SBOM, a licence table and installation and update procedures, written for whoever arrives after us.
A library kept alive by one person in the evenings will stop one day. Its flaws stay open, and swapping a component out of a running system is expensive. So we look past the feature list: who backs the project, how many maintainers it has, how long they take to publish a fix once a flaw is announced. A foundation behind a project is often worth more than an extra feature.
On licences, nearly always, and the gap widens with every additional user. On development and running costs the difference is small. Compare a full cost over three to five years, hosting, updates and support included, rather than the price of the initial project alone.
Any team that knows the technology, which is exactly the point. The code and documentation are yours, the components are public, the market of suppliers is wide. A proprietary platform from a single vendor gives you none of that freedom on the day the relationship sours or the price doubles.
It sits well there: open formats make exchanges between online services easier, support published open data and the reversibility expected at the end of a contract, and the buyer receives the complete code. Drafting the tender remains the buyer's responsibility with its own advisers; we help write the technical part of the requirement.
It is visible to attackers and equally to the thousands of people auditing it. Flaws in widely used projects are reported and fixed quickly, so everything rests on your update discipline. We follow project bulletins and CERT-FR advisories, and critical vulnerabilities are handled outside the usual release rhythm.
We do, under the maintenance agreement. That is the real difference from a proprietary product: support does not come attached to a licence, it is bought separately. Response time, the scope covered and how to raise an incident are written down, exactly as for any other service commitment.
Describe the need and what irritates you about your current licences. We will propose specific components and point out where the open answer falls short.
Message received
An answer follows inside one working day. Report an outage that is stopping people working and it moves ahead of everything else.
Nothing here under that name. Check the spelling, or simply choose the nearest large city instead. Since every engagement runs remotely, whichever you pick changes nothing about what we do for you.