orib.dev: Simplicity and Ecosystems

Software for users should serve the needs of users, and not the needs of giant corporations with nearly limitless resources.

Forks are an essential part of ensuring that software serves the user. When maintainers aren’t serving user needs, forking can allow users to resolve the situation.

Discontent with Xfree86 leadership led to the X.org fork. The split was triggered by licensing, but there were rumblings of discontent with the slow pace of progress and closed leadership style. This fork dragged X11 kicking and screaming out of the 1980s, bringing dynamically reconfigurable multihead, composited desktops, and working hardware acceleration – all while shrinking the codebase by more than 10,000 lines for the first several releases.

Discontent with the slow progress of GCC development led to the EGCS fork. EGCS added many optimizations for contemporary processors, improved C++ support, added more frontends, and generally improved things. This fork proved so successful that the original GCC ceased development. EGCS got rebranded as GCC, and replaced the original.

There are many other examples of successful forks. Many are former Sun projects, which forked after Oracle took ownership.

But for forks to be possible, the projects need to be simple enough to be forkable. Even better, they need to be simple enough that multiple alternative implementations can coexist, all growing independently and serving separate niches.

Complexity forms barriers. These barriers can squeeze out alternative implementations by increasing the resources needed to maintain a fork. They make it harder for a community to form and provide alternatives to users.

On top of that, if the costs of maintenance are high, a source of money becomes necessary. This means either a revenue stream, or an investor that expects a return on their investment. Monetization becomes necessary.

This can result in a feedback loop. Implementers that aren’t raking in the megabucks drop out. Those who remain standing grow their market share. They benefit from a rise in complexity and the barriers that come with it. Because there are fewer options, they can tighten the screws further to increase revenue, which increases their ability to fund complexity. This can push the weaker players out of the market, and the cycle repeats.

The result of this is that only a small number of well-funded implementations survive, all of them trying to maximize profits. Without people able to maintain viable forks, the owners of an implementation can set a direction, and users are dragged along.

At this point, some of you are certainly thinking of browsers. Browsers are just one cautionary tale. Manifest V3 is being rammed through, hobbling ad blockers. This change would be harder to make stick if users have places to go. But the choices are Chrome, Firefox, and Safari. The first two are funded by Google ads.

But the problems caused by complexity aren’t restricted to browsers. Network protocols, deployment tools, operating systems, init systems, and file formats are all at risk. As the complexity grows, the ability to own our software decreases.

Open standards aren’t enough for healthy ecosystems. Both standards and their implementations need to be simple enough to fork and maintain.