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

  1. Community fragmentation and duplicated effort

  2. Maintenance burden

  3. Security risks

  4. Cultural cost

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.

Another metaphor: the community seed bank

The book metaphor above describes the big, deliberate fork. Most divergence does not start there. It starts with a small fix that nobody thinks of as a fork at all.

Imagine the LA community as gardeners sharing a common seed bank: the upstream ALA repositories. Everyone grows from the same stock, and everyone is expected to deposit back what they select.

One dry summer, one of your plants survives where the others fail. You eat the fruit and you keep a handful of its seed in your own shed for next season. You did nothing wrong, the harvest was yours. But that seed never reaches the bank: it stays in one garden only, in an unlabelled jar. The variety lasts as long as the gardener who knows what is in that jar stays on the team, and it is gone the day that person leaves and the next gardener sows from the common stock again. Meanwhile everyone else keeps sowing the same stock as before, and losing the same plants every dry summer.

What this looks like in practice:

  • Depositing the seed costs a little more than keeping it in your shed. Labelling the jar, writing down what the plant survived, walking it to the bank: that extra step is the distance between "it works on our portal" and offering the change back to the shared codebase. The work lands right when the problem has already stopped hurting you.
  • The label matters as much as the seed. An unlabelled bag helps nobody. Neither does a change with no explanation of what was broken and what it now does.
  • Seeds locked in a shed are not in the bank. A private repository, or a public copy that nobody ever checks against the original, looks like sharing but is not. If no one can see what you changed, review it and sow it themselves, the variety is still lost.
  • Whoever does not deposit re-sows the same thing every year. Several LA nodes have spent seasons fighting the same pest, each inventing its own remedy, each paying the full cost alone.

None of this requires bad faith, only silence.

You kept the good tomato's seed in your own shed and never took it to the bank. You did nothing wrong, but that variety now grows in one garden only, for as long as someone there still remembers the jar.

How you actually deposit a seed

In our tooling these words mean:

  • Upstream is the seed bank itself: the official ALA repositories everyone grows from.
  • An issue is a note left at the bank saying "this plant failed here, this is what I saw". It costs minutes and it already counts as depositing. You do not need to know how to fix it.
  • A pull request (PR) is handing over the actual seed with its label: your change, plus a short description, offered to the ALA maintainers. They review it, ask questions if needed, and if accepted it becomes part of the next release and is maintained by the community from then on.

The threshold is lower than people assume. A change that never goes upstream is not a fix, it is a debt that comes due at every upgrade. Your team pays it first, and the whole community pays it again every time another node has to solve the same problem from scratch.

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.