pieterh wrote on 08 Feb 2016 12:47

Projects and companies die for different reasons. Sometimes it's money, and sometimes it's pride. In this post I'm going to expand on Drew Crawford's "nanomsg postmortem and other stories".

It was about four years ago that the ZeroMQ community ejected its main contributors, who forked it as Crossroads, and then rebooted that as Nanomsg. Our motivation for that coup was almost exactly the pain and angst that Drew describes in his article, which we'd suffered for years in ZeroMQ.

The contract that binds the ZeroMQ community is, increasingly, not a technical one. It is C4.1, RFC 22, which has as its core principle:

Everyone, without distinction or discrimination, SHALL have an equal right to become a Contributor under the terms of this contract.

If you send a correct patch (as defined by the RFC), it shall be merged. Period. This simple, brutal rule had several effects:

• It silenced the arguments over ideology that used to pollute zeromq-dev.

• It removed the discriminatory "I don't like you so I don't like your code" power of dominant maintainers.

• It opened the door to new waves of contributors, who have turned ZeroMQ into a much larger and more aggressive collective project.

RFC 22 is revolutionary. No other project has defined the rights of contributors in such a way before, using the language of contracts and protocols. It established a bill of rights for contributors that focused on recruiting contributors. As Drew writes,

Open source projects hinge entirely on contributors.

The main argument against inclusive diversity is a tired and clichéd appeal to exceptionalism. "I'm smarter than average so I write good code, alone," is the way it usually goes. It is provably wrong. Good code is code that survives. This is how the market works, there is no other basis for value judgments on code except "people use it, people invest in it, and it survives"

Nanomsg was designed to fail. There are powerful lessons here that anyone starting, using, or contributing to an open source project can profit from.

Let me list the vulnerabilities, if they're not already clear to everyone:

• The lack of a bill of rights for contributors, allowing the maintainers to discriminate.

• Starting with a core maintainer who had a long record of working poorly with others. In 2011 we had four incompatible versions of the core ZeroMQ library (2.x, 3.0, 3.1, 4.0), due to endless and chaotic changes coming from Martin Sustrik.

• The use of a MIT license, which encourages "dark forks," as Drew calls them.

Mix this together and the results were predictable. In ZeroMQ we had the same ideological hostility towards contributors, which we massaged away with endless diplomacy. Much of my time went just to that, for years. The license made it hard for people to create dark forks. So, we worked hard to get consensus, and mostly we succeeded.

The lessons here are clear:

• First, please do not use a leaky license. MIT/BSD is not "business friendly," so much as "community hostile." MPLv2 is broadly accepted by businesses and discourages dark forks.

• Second, please use a strong bill of rights for contributors. Use C4.1, as-is, and you will avoid the pain that Drew and others went through. We learned this lesson in 2012.

• Third, when things hurt, stop and fix them far earlier. We seem to be so patient with pain. Learn to recognize that pain is not a good sign.

In conclusion I'm going to quote Doron Somech: "Crazy Idea: Clone nanomsg, move to zeromq organization, relicense as MPL, support ZMTP, only new socket types and expose CZMQ API."