One of the core values of open-source platforms is collaboration and the sharing of knowledge. Even the most vibrant communities face coordination challenges—and because people, not machines, run them, they can never operate with perfectly clockwork precision. Understanding both the strengths and limitations of large‐scale collaboration helps us design processes that maximize contribution while minimizing friction.
Eric Raymond declares Linus’ Law “Given enough eyeballs, all bugs are shallow.” (Raymond 1999). According to Raymond’s reasoning, the diversity of developer perspectives ought to be embraced, not avoided. Therefore, more developers mean more vulnerabilities are found, fixed, or even prevented. However, contrary to this argument, an empirical study was conducted to examine the correlations between known security vulnerabilities in the open-source project and developer activity metrics. Files developed by otherwise independent developer groups were more likely to contain vulnerabilities, supporting Linus’ Law. However, files with changes from nine or more developers were 16 times more likely to have a vulnerability than files changed by fewer than nine developers, indicating that the involvement of many developers in code changes may have a detrimental effect on the system’s security (Meneely and Williams, 2009).
Reflecting on these findings in light of my own experience contributing to MDN Web Docs, I observe similar patterns. The translated content repository currently has 2 895 contributors (see Figure 1) and supports translations into eight languages.
The Russian-language review team, by contrast, comprises just six members (see Figure 2). Per the project guidelines, the team is expected to review and merge all pull requests within two weeks, triage and resolve every actionable issue within one month, and make steady weekly progress keeping MDN’s Tier 1 content synchronized with the en-US versions—whether by updating articles to match the English originals, removing outdated or low-quality pages, or otherwise ensuring consistency. I submitted my first pull request on May 3; however, the assigned reviewer’s last activity was on April 26, 2022, indicating that the two-week review window is not being met in this case (see Figure 3).
A more dramatic example of reliance on key maintainers and what can happen when they suddenly disappear comes from the Core-JS polyfill library, where Denis Pushkarev, a Russian developer who had guided the project for years, was arrested and later imprisoned following a fatal hit-and-run incident. As was discussed at the lecture, overnight, the project lost its principal maintainer, leaving thousands of downstream projects scrambling for patches, leadership, and a clear governance path. In Core-JS’s case, the community had to reorganize rapidly, appoint new stewards, and reestablish trust in release practices—illustrating that beyond sheer contributor numbers, the availability and accountability of key maintainers are equally critical to a project’s health.
Taken together, these case studies illustrate that open-source collaboration is as much an exercise in human coordination as it is in technical execution. While broad participation brings invaluable diversity of thought and accelerates discovery, it also introduces the risk of fragmentation and bottlenecks. The key is to strike a balance: embrace the “many eyeballs” principle by encouraging contributions, but pair it with robust governance, clearly defined roles, automated checks, and fallbacks when core volunteers become unavailable.
References:
Meneely, A., & Williams, L. (2009, November). Secure open source collaboration: an empirical study of Linus’s law. In Proceedings of the 16th ACM conference on Computer and Communications Security (pp. 453-462).
Raymond, E., 1999. The cathedral and the bazaar. Knowledge, Technology & Policy, 12(3), pp.23-49.