The ALA No‐Fork Path - AtlasOfLivingAustralia/documentation GitHub Wiki

Within the Atlas of Living Australia (ALA) ecosystem, we share a large and evolving codebase.

While forking the ALA code is always technically possible, experience from the wider free-libre-open-source world shows that forks should be the last resort. In most cases, they create more problems than they solve.

Problems with Forking

Community fragmentation and duplicated effort
- Forks split developers and users into separate projects.
- Bugs, improvements, and discussions get duplicated instead of shared.
- Empirical studies show that most forks either fail or end up abandoned. 🔗 Carnegie Mellon University – Why Do Hard Forks Happen? (2020)
Maintenance burden
- A fork means taking full responsibility for bug fixes, documentation, security patches, and upgrades.
- Over time this creates technical debt and slows down innovation. 🔗 Salesforce Engineering – No Forking Way (2017)
Security risks
- Forks often lag behind the original in applying upstream security fixes.
- This can expose users to vulnerabilities that have already been solved in the main project. 🔗 Patchstack – Securing Open Source Forks (2023)
Cultural cost
- Forking is seen in open-source culture as a breakdown of collaboration.
- It requires continuous justification and tends to harm trust within the community. 🔗 Eric S. Raymond – Homesteading the Noosphere (1999), section Taboos against forking 🔗 Karl Fogel – Producing Open Source Software, “Forks” chapter

Looking back at more than ten years of LA community experience, the forks that have taken place have consistently shown us the risks and problems described above.

Forks as Short-Term Reactions

Forking often feels like a quick or even “ingenious” way to solve a problem. However, experience shows that this is usually a short-term reaction rather than a sustainable strategy:

A fork can look like the fastest path forward, but it often creates technical debt and extra maintenance work.
It may appear innovative at first, yet it usually divides effort and slows down long-term progress.
Mature open-source communities tend to measure success not by how many forks exist, but by how well contributors collaborate upstream.

Choosing collaboration over forking reflects the maturity of a community that values shared progress over duplicated effort.

Better Alternatives

Before considering a fork, it is almost always better to:

Contribute changes upstream ALA code (via pull requests or shared design discussions).
Use optional configuration functionalities.
Maintain a temporary private branch only until upstream accepts or rejects the change.

Forks explained for managers

Imagine ALA’s software is a technical book authored by many authors. A fork is when a LA team takes the latest edition and makes local changes—fixes typos, adapts chapters, or even translates sections—without sending those edits back to the publisher and original authors. Meanwhile, the official "ALA" book keeps evolving: new editions add features, correct errors, and reflect the latest advances in the field.

What happens to those local changes of other LA team? They quickly drift out of sync. Reapplying them onto each new edition becomes costly and error-prone, because the official text has moved on. These LA Teams end up with two bad options: keep maintaining an outdated edition (and miss improvements), or discard their local edits to return to the current oficial latest edition. With ALA’s software—more like a shelf of multi-volume books written by many authors—the effort and risk compound even further. That is why forks feel fast at first, but become expensive detours over time.

And it gets even worse: local changes, since they are not generalized, are usually of interest only to the team that made them. Other teams cannot benefit from those improvements, nor can they help maintain them.

And that’s why, if a LA local team wants to fix errors, improve a chapter, or add a new section, it’s essential to send those changes promptly to the editors and authors. That way they can review and incorporate them, and—if accepted—your improvements will be included in future editions for everyone’s benefit.

What we have seen in our LA community

Over the years, we have witnessed practical examples of all the above:

LA Portals heavily customized and then frozen in time, because the cost of re-upgrading became prohibitive—or they chose to switch to other software rather than update their customized portal.
LA Portals that eventually discarded large sets of local changes in order to upgrade and use the latest ALA releases.
LA Portals that attempted major improvements but not fast enough to upstream them, missing the window to send changes to the original maintainers.
LA Portal teams solving the same problem independently with varying success, duplicating costs and efforts across the LA community.
And LA portal teams that contributed their changes upstream, had them incorporated into new versions, and now see those improvements maintained alongside the rest of the releases. ✅

Conclusion

Forking may seem like the fastest path, but in reality it often leads to wasted effort, higher maintenance costs, security issues, and divided communities. The ALA community thrives when we work together — so let’s keep forks as a last resort and prioritize collaboration with ALA upstream code.