Open source software is not just about accessible code. It is a production model that redistributes technical power among organizations, developers, and users. Understanding its advantages requires examining the concrete mechanisms that make it structurally different from proprietary software.
Cyber Resilience Act and open source: what the European regulation 2024/2847 changes
The European regulation 2024/2847 (Cyber Resilience Act) came into effect on December 10, 2024. Its main obligations will apply starting December 11, 2027, with some reporting obligations beginning on September 11, 2026. This regulatory framework redefines responsibilities around software components, including open source.
The key technical point to remember: free software provided outside of a commercial activity benefits from a lighter regime. A volunteer maintainer who publishes a library on a public repository is not subject to the same requirements as a publisher. In contrast, the company that integrates this component into a commercial product bears the responsibility for compliance.
This distinction has direct consequences on software architecture choices. Technical teams must accurately map the open source dependencies of their products, assess the maintenance level of each component, and document the chain of responsibility. The CRA encourages organizations to treat their open source dependencies as industrial components, with formalized vulnerability tracking.
Initiatives like those documented on mondelibre.org help disseminate practices and resources that enable French-speaking stakeholders to navigate this evolving regulatory environment.
Digital sovereignty: public funding for open source components
We are witnessing a strategic shift in how states view free software. Germany, through the Sovereign Tech Fund launched in 2022, has invested over 24 million euros in around sixty structuring projects: cURL, FreeBSD, GNOME, OpenSSL, PHP. These components are not marginal software. They constitute the invisible infrastructure upon which entire sectors of the web and public information systems rely.
The argument goes beyond cost reduction. Directly funding the maintainers of open source projects treats the code as a public interest infrastructure, akin to a road network or a water distribution system. Without this funding, maintenance relies on a few volunteer developers, creating systemic failure points.
This approach also addresses a sovereignty issue. Relying on a single proprietary vendor for a strategic function (encryption, web server, identity management) exposes one to geopolitical and commercial risks. Publicly funded open source reduces dependence on a single vendor while maintaining the ability for independent third parties to audit the code.
Commercial open source: a fully-fledged business model
Open source is not the enemy of the business model. The State of Commercial Open Source 2025 report, presented at the Open Source Summit Europe 2025, estimates the funding raised by commercial open source startups in 2024 at 26.4 billion dollars. This amount confirms that open code serves as a foundation for venture capital-funded companies.
Revenue models rely on support, managed hosting, or premium features. The mechanism is precise. A company publishes the core of its software under an open source license, which accelerates adoption and trust among developers. Revenue then comes from value-added services that professional users are willing to pay for: high availability, regulatory compliance, integration with existing systems.
This model creates a virtuous circle. The more an open source project is adopted, the more the community contributes to its quality, and the more credible the accompanying commercial offer becomes. Companies that adopt open source solutions for their ERP, data management, or cloud infrastructure benefit from a competitive ecosystem where multiple providers can intervene, avoiding vendor lock-in.
Open source code security: collective audit against proprietary opacity
The transparency of source code is a structural advantage for security, not an automatic guarantee. The distinction is fundamental. Proprietary software relies on security through obscurity: only the publisher knows the potential vulnerabilities. Open source software allows any competent auditor to inspect the code, report a vulnerability, and propose a fix.
We recommend not to confuse “open code” with “audited code.” A poorly maintained open source project, with only one active contributor, presents real risks. Attacks targeting maintainers (supply chain attacks) specifically target these orphaned projects. The challenge for organizations is to select actively maintained components, with a diverse contributor community and formalized code review processes.
The criteria to check before integrating an open source component into a professional project:
- Frequency of commits and releases over the past twelve months, indicating the actual activity level of the project
- Number of distinct contributors, as a project relying on a single person constitutes an operational risk
- Existence of a vulnerability disclosure policy and average time to fix reported vulnerabilities
- Compatibility of the license with the legal framework of the final product, especially for copyleft licenses like the GPL
These checks are not optional. With the gradual implementation of the Cyber Resilience Act, documenting the chain of open source dependencies becomes a regulatory obligation for any connected product marketed in the European Union.
Open innovation: why open source projects progress faster
Open source development concentrates contributions from organizations with different needs. A project like a Linux kernel or a web server receives patches from competing companies that share a common interest in the reliability of the technical component. This dynamic produces software tested in usage contexts far more varied than a product developed internally by a single team.
The effect on the speed of innovation is measurable in practice. Open source development cycles allow a developer to submit a patch or feature without going through a commercial process. The barrier to contribution is technical, not contractual.
For companies evaluating their management, development, or security tools, open source offers a lever for adaptation that proprietary solutions cannot match. Modifying an open source ERP to fit a specific business process remains possible without depending on the vendor’s timeline. This technical freedom directly translates into operational agility.
The open source model is not suitable for all contexts. In infrastructure, security, and data processing functions, it represents the most resilient and auditable technical foundation available today.
