Collaboration in open source

Every open-source project faces a fundamental question, one which all human organizations grapple with: who gets to make decisions?

Many open-source projects, starting with Perl, have gone with the "benevolent dictator" approach. The progenitor of the project, who may no longer contribute any code, serves as project manager and ultimate arbiter of what direction the project goes in, what code should be included, etc.

Other projects choose to be governed by committee instead. C++, for example, has a standards committee. The problem with this approach are well known: design by committee is how C++ ended up becoming the complex beast it is today. Standards committees, in particular, tend to include members whose interest are diametrically opposed with each other's, resulting in conflict² and stagnation³.

Even worse is a model in which a committee exists, but revolves around a charismatic leader. Python has just such a model, in which complex layers of bureaucracy all lead to Guido van Rossum, resulting in awful decisions like breaking backward compatibility between Python 2 and 3.

Emacs, being a project of the Free Software Foundation (FSF), is not governed by a benevolent dictator or committee, but rather by a "gerontocracy" of long-time contributors. In the early days Richard Stallman (rms) decided what went into Emacs, but as the project grew and an increasing proportion of his time was taken up by traveling and speaking, those who spent the most time on the project ended up becoming decision-makers.

Being governed by people who've been around a long time has certain advantages. For one thing, the decision-makers are Emacs experts and know what they're talking about, down to the smallest technical details.

A major disadvantage, though, is that it raises the barrier of entry for new contributors. Putting aside the inconveniences⁴ of actually submitting a patch for Emacs, it's very difficult to get anything accepted–new ideas that deviate from Emacs' long-established behavior–like the portable dumper–are viewed with suspicion, and breaking backward compatibility is nearly always a no-no⁵.

To get anything accepted into Emacs, it's best for new contributors to first post an issue to the mailing list, then propose–in words, not code–a solution. A slow, torturous discussion⁶ is sure to follow regarding basic strategy. At some point, the contributor should propose creating a proof of concept (POC), which should in fact be a thorough and complete solution to the problem. If the POC is too cursory, it'll need many rounds of code review, and reviewers may take a long time to go through the code, if they bother following the discussion at all.

The key to winning over stakeholders is to demonstrate that you've thought long and hard about the patch's impact on the project and its users, and that, if it's something which will require ongoing maintenance, you'll be the one doing the maintaining. What's really at stake is demonstrating that you're a reliable and trustworthy individual who won't contribute a piece of code, then disappear, burdening other maintainers with it.

Where Daniel's good intentions went wrong is that he submitted a patch with several thousand lines of non-trivial C code, then listed a number of (good) reasons why his code should be merged. This goes against the usual process of discussing the problem with stakeholders first. Once the well's been poisoned, discussion quickly became less about the technical issues and more about a relatively new member of the community threatening its norms.

The FSF was founded not merely as an open-source software shop, but as an ideological organization promoting a certain type of software and a way of developing that software. The process is at the heart of the project, and becoming a member of the community means following it closely. Changing the process, if it could be done at all, is a long-term effort, and certainly not something that's welcomed by a newcomer.