C4.1 - an Exothermic Process

pieterhpieterh wrote on 16 Sep 2015 20:49


In February 2012 the ZeroMQ community said "adieu" to its long time maintainers, and set sail in a new direction. Using a new process called C4.1 as its compass, we headed off into unknown territory. Looking back three and a half years later, what is the result? Did ZeroMQ lose its way, as many predicted and feared? Or did the new process work as planned?

C4.1 claims its first goal is to "maximize the scale of the community around a project." Community means many things. Above all it means life. If no-one uses or contributes to your software, the code does not matter.

Here is my analysis of the growth of the ZeroMQ community since we moved to git in mid-2009:


The picture speaks volumes. You can see the activity grow, peak, and slow down for each major version. You can see the clear difference between "before" and "after" the fork in late 2011, when the original maintainers left to create Crossroads.io, and ZeroMQ moved to the C4.1 process.

What is most fun is that ZeroMQ takes zero management these days. It is self-steering, self-feeding, and self-organizing. We have applied C4.1 to old projects like libzmq, and brand new ones. The results are the same. If the project does something useful, it takes off, and contributors join, and everyone enjoys themselves.

C4.1 is an exothermic process. It produces almost perfect software. ZeroMQ's oddities all date from before 2012, and are slowly disappearing. ZeroMQ master is almost always stable. It just does not break stable APIs or protocols. The mailing list is polite and happy. We do not argue.

If you run an open source project, and your commit chart does not look like this, go read ZeroMQ RFC 22.

Here is how I produced this chart:

  • Take all of the repositories in the ZeroMQ organization on github. There are many times more projects that aren't in the organization (about 20 for each one in the organization). I ignored these. There are "stabilization forks" of projects, like zeromq4-x. I ignored these as well.
  • Clone each repository to my laptop, then listed all commits since the start, using this command: git log —date=short —format="format:%ad", for each project.
  • Get the number of commits per day using this command: sort activity.log | uniq -c
  • Run a Perl script that calculates the totals per week, and prints out a comma-separated values file.
  • Load that into LibreOffice and generate a graphic.


Add a New Comment
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License