Why we rely on open source in customer projects

When we start a customer project, one question arises early on: which building blocks do we use? Ready-made platforms, proprietary libraries — or open source? Our answer is usually the same. Not out of principle, but because in most cases it’s the better decision.

Transparency instead of relying on promises

Proprietary software requires trust: trust that the provider will close security gaps promptly, trust that the API will remain stable, trust that the product will still exist in five years’ time. We can read open source code, check it and adapt it ourselves if necessary. This isn’t a theoretical advantage — in practice, it means we can solve problems instead of waiting for a support ticket.

Independence belongs to the customer

A project based on open source doesn’t bind the customer to us. Any other team with the right skills can develop the software further, maintain it or take it in a different direction. That’s intentional: we build software that belongs to the customer — not only contractually, but also practically.

Longevity can be planned

Many of the frameworks and libraries we use are supported by large communities. Security updates often come faster than with commercial providers. And if a project does fall dormant, the code remains available — a fork is possible, a transition can be planned. With proprietary software, the software often dies with the provider.

No dogma

We use open source where it makes sense. If a proprietary tool offers a better solution — for specialised industry software or regulatory requirements, say — we recommend it openly. The decision belongs to the customer, and it’s our job to present the options honestly.

What often gets lost in all of this: open source isn’t just a technical decision. It’s a commitment to collaboration, to open standards, and to the idea that good software doesn’t have to disappear behind licence keys. That’s in line with how we work — and with what most of our customers expect.