TL;DR
Modern open-source software isn’t built in one place or along a single path. Tools like Git enable independent development while preserving shared history, provenance, and open collaboration. This allows different organisations to move at different speeds, and supports long-term users without central coordination. Large projects such as the Linux kernel have long operated this way, combining decentralised development with shared standards and open code. What matters isn’t where development happens, but that users receive stable, secure, and openly auditable software that continues to serve diverse needs at scale.
Open source isn’t a single repository
There’s a mental model of a software repository as a single, central place where “the real code” lives, and everything else is somehow downstream of it.
In reality, open source today is a network of repositories, contributors, and workflows, connected by shared history and shared standards – not by a single gate.
And that’s largely thanks to Git.
A quick, practical explanation of Git?
Developed in 2005, Git is the system most modern open-source software uses to manage code.
At its simplest, Git answers three questions:
- What changed?
- Who changed it & when?
- How does this relate to everything that came before?
But the important thing isn’t just tracking changes – it’s how Git enables collaboration.
Everyone has the whole project
With Git, every developer can have a full copy of the codebase on their own machine.
Not just the latest version – the entire history.
That means no single server is “the” source of truth, work doesn’t stop if a service goes offline, and it enables developers to work independently, offline, and in parallel
Each copy is complete and verifiable.
Work happens in many repositories
Instead of everyone editing the same version of the code at once, Git encourages work to happen on clones. There are many reasons for this, but essentially it enables developers to try new features and fixes on the code, without potentially causing disruption to others.
Copies can be short-lived or long-running, shared or private. They’re simple to create, easy to merge, and easy to discard.
Parallel development is the standard operating procedure.
Git makes independence normal - not exceptional
Git isn’t just a version control system; it’s a different way of thinking about collaboration.
With Git:
- Everyone can have a complete copy of the codebase
- Every copy usually includes the entire history, in a cryptographically linked chain
- This makes it extremely difficult to smuggle in malicious changes unnoticed. You can’t quietly rewrite the past – any alteration breaks this chain of links and is immediately detectable.
- Every developer can work on their own code, at their own pace
- A single developer can pull code from multiple remote sources
- Code can flow between repositories, not just “up” or “down”
This is what makes Git a real powerhouse in the programming world. Each commit hash uniquely defines the full history up to that point and the entire repository state. Provenance is built in. Trust is verifiable. Collaboration doesn’t depend on a single server or a single workflow.
Built-in resilience and disaster recovery
One of the most overlooked strengths of Git’s distributed model is resilience. Because every clone is a complete copy of the project – including its full history – the future of the codebase does not depend on a single server, organisation, or hosting provider to survive.
If a hosting platform disappears, the project does not disappear with it. If a company changes direction, the code remains available. If infrastructure fails, development can continue from any full copy.
Traditional software vendors often rely on expensive source code escrow agreements as a safeguard in case a supplier collapses. With open-source software managed by Git, this protection comes baked into the technical architecture for everyone.
Disaster recovery is no longer a contingency plan, it is the default state of the system.
This resilience matters deeply for governments, enterprises, and long-term infrastructure projects. Software that underpins critical systems must not depend on a single point of failure – organisational or technical.
More forks than a restaurant ?
In some git-based development flows, the process of creating your own repository to work on new features and fixes independently is called forking.
On platforms like GitHub, it’s a prominent button at the top of the page because it’s a normal part of how distributed development works.
At the time of this screenshot for example, there were 978 forked copies of the Collabora Online source code – most of them made by developers eager to contribute back to the goodness – we love that!
Multiple remotes, multiple maintainers, multiple priorities, connected by shared code, shared history, bonds of friendship and collaboration powered by the Git synchronisation protocol. The choice of hosting and infrastructure becomes an almost irrelevant detail, with developers choosing the tools and processes that best support their work.
Improvements can be exchanged, and collaboration can happen without requiring everyone to follow the same internal processes or timelines.
At the same time, in ecosystems with many development paths, trusted editors play a critical role in curating, integrating, and supporting coherent, branded, secure releases.
This is how most large open-source projects already work
The largest open-source project in the world is the mainline Linux kernel.
While there is a widely recognised upstream integration tree, Linux development does not start in one place, nor does it follow a single linear path.
Most Linux code is written outside the mainline tree. Subsystem maintainers, vendors, researchers, and long-term support teams all develop in their own repositories, often with different goals, timelines, and constraints. Some of this work is later integrated upstream. Some of it remains long-lived and independent. Both are normal, accepted, and essential to how the ecosystem functions.
What people perceive as ‘Linux’ is usually a distribution kernel which is built not only from the mainline Kernel, but often includes a selection of drivers and updates and fixes maintained in many other Git repositories. This pattern is visible well beyond the kernel itself. Ubuntu is a long-running derivative of Debian. The two projects share a common foundation, diverge where their priorities differ, and regularly exchange fixes and improvements. They cooperate closely, but they are not trying to be the same thing, and both are excellent solutions for their use cases and target audiences.
This model of decentralised development, shared history, and open standards is what allows open-source projects to support different needs and directions without forcing a single pace or a single set of priorities. It’s how mature, secure software scales.
The outcome that matters
At the end of the day, this isn’t about repositories or hosting platforms.
It’s about delivering:
- Stable, well-maintained software
- Faster iteration where it matters
- Long-term support users can rely on
- Open-source code that remains open, auditable, and reusable
Independent development isn’t a departure from open-source values. It is how those values continue to work at scale.
So which repository do I use ?
Most organisations don’t want to build from source or track dozens of repositories. They want dependable releases: professionally built binaries, timely security updates, long-term maintenance, and stable leadership. What matters is having a version that is coherently integrated, responsibly maintained, and ready to deploy.
At the same time, open development thrives on participation. So if you want to contribute, follow the energy! Look at development pace, commit activity, responsiveness, and long-term sustainability. Join the project where work is happening, improvements are welcomed, collaboration is active, and you feel at home.
That’s the role we play with Collabora Office. In a landscape of many repositories and development paths, we provide a stable, security-hardened, professionally supported release – while keeping the door open for collaboration and contribution. Open source gives you the freedom to choose, we aim to be the choice you can build on.
