Open source can improve transparency, portability and shared development, but source availability alone does not create sovereignty. Real control depends on maintainers, governance, skills, infrastructure and the ability to operate the technology independently.
What matters most
A project can be open source yet depend heavily on one supplier or external service.
Maintainer capacity and security response are operational assets.
Licences define permissions but not project governance or sustainability.
Public procurement can support open standards and exit options.
Forking is meaningful only when an organisation can build, test and operate the fork.
Contribution strategy should protect upstream relationships rather than create isolated copies.
Questions to answer before acting
Use these questions to turn a broad topic into a defined decision, test or work package:
- Who maintains the critical components?
- Can the organisation build and operate them independently?
- What licence and contribution obligations apply?
- What happens if a supplier or maintainer exits?
A practical sequence
- Step 1. Map critical software and service dependencies.
- Step 2. Assess licence, governance and maintainer health.
- Step 3. Test build, deployment and data portability.
- Step 4. Contribute fixes upstream where practical.
- Step 5. Fund lifecycle maintenance and exit capability.
Common traps
- Equating an open licence with independence
- Ignoring maintainer capacity
- Creating an unsupported internal fork
Where this fits in the wider system
This topic belongs to the site’s Strategic technology infrastructure pillar. The strongest route normally connects several pillars: a research result may need a testbed, a consortium, an appropriate programme, standards work and a scale-up plan.
Use the planning tools to identify the next uncertainty, then verify the route through the official-source directory.