The Myth of More Contributors = More Chaos

Stability Is a Feature

Success Creates Constraints

The Hidden Advantage

What This Means for Builders Linux has thousands of contributors. Yet some commercial applications with dedicated teams seem to break every other update. One of the strangest realizations I had as an engineer was that both of these statements can be true at the same time. At first glance, it doesn't make sense. Surely a project with thousands of contributors should be chaotic. Surely more contributors should mean more bugs. Surely a tightly controlled commercial product should be more reliable. Yet some of the most dependable software in existence is open source. Meanwhile, many commercial products regularly ship regressions, break workflows, remove useful functionality, or introduce bugs into places that previously worked. The obvious explanation is: Open source somehow produces better engineers. I don't think that's true. The real explanation is more interesting. Most people imagine open-source development working like this: That sounds reasonable. It just isn't how mature projects operate. Linux is not a giant shared Google Doc where thousands of people edit whatever they want. What Linux actually looks like is closer to: Contributors propose. Networking maintainers review networking changes. Filesystem maintainers review filesystem changes. Kernel maintainers review kernel changes. The number of contributors is enormous. The number of people trusted to approve critical changes is much smaller. What appears chaotic from the outside is often highly structured on the inside. The next realization was that infrastructure projects optimize for very different outcomes than most applications. Many software companies optimize for: Infrastructure projects optimize for: Those are fundamentally different goals. A Linux user rarely wakes up hoping their operating system feels completely different today. A PostgreSQL user does not want a revolutionary new database experience every month. A Git user is not asking for dramatic workflow changes. Infrastructure succeeds when it becomes predictable. The best infrastructure becomes boring. And boring software survives. Something else happens when software becomes widely adopted. Success makes change expensive. If a side project breaks an interface: If Linux breaks an interface: If PostgreSQL breaks compatibility: If Git changes fundamental behavior: Success creates responsibility. The more successful a project becomes, the more careful it often becomes. The more successful a project becomes, the more responsibility it accumulates. This naturally creates pressure toward stability and backwards compatibility. Not because maintainers hate innovation. Because they understand who depends on them. Many commercial products are evaluated through visible progress. New features are visible. Redesigns are visible. Announcements are visible. Reliability is usually invisible. PostgreSQL successfully preserved my data for another year. Git behaved exactly as expected today. My operating system remained predictable. Yet that's exactly the value these projects provide. Infrastructure software wins when nothing surprising happens. Its greatest achievement is often being forgotten. The most surprising realization was that open source is not powerful because anyone can contribute. It's powerful because anyone can inspect. Bad ideas are visible. Design discussions are visible. Tradeoffs are visible. Mistakes are visible. The reasoning behind decisions becomes part of the project itself. Over time, mature projects accumulate something even more valuable than code. That institutional memory becomes a competitive advantage. New contributors don't start from zero. They inherit decades of lessons. In many cases, the project's greatest asset is not the code. It's the knowledge surrounding the code. For a long time, I assumed reliability came from control. But some of the most reliable software in existence is built through collaboration rather than control. The lesson is not that open source is magically better. The lesson is that reliability is rarely an accident. It emerges from incentives. From review processes. From institutional memory. From maintainers who understand the cost of breaking things. And from cultures that treat stability as a feature rather than an afterthought. The next time a project with thousands of contributors seems impossibly stable, it's worth remembering: Linux does not stay reliable despite having thousands of contributors. Linux stays reliable because it learned how to manage thousands of contributors without sacrificing the things that matter. And that might be one of the most impressive engineering achievements in software. Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to ? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse