C4 is meant to provide a reusable optimal collaboration model for open source software projects.
The short-term reason for writing C4 was to end arguments over the
libzmq contribution process. The dissenters went off
elsewhere. The ØMQ
community blossomed smoothly and easily, as I’d predicted. Most
people were surprised, but gratified. There’s been no real criticism of
C4 except with regard to its branching policy, which I’ll come to later
as it deserves its own discussion.
There’s a reason I’m reviewing history here: as founder of a community, you are asking people to invest in your property, trademark, and branding. In return, and this is what we do with ØMQ, you can use that branding to set a bar for quality. When you download a product labeled “ØMQ,” you know that it’s been produced to certain standards. It’s a basic rule of quality: write down your process, as otherwise you cannot improve it. Our processes aren’t perfect, nor can they ever be. But any flaw in them can be fixed, and tested.
Making C4 reusable is therefore really important. To learn more about the best possible process, we need to get results from the widest possible range of projects.
It has these specific goals:
To maximize the scale of the community around a project, by reducing the friction for new Contributors and creating a scaled participation model with strong positive feedbacks;
The number one goal is maximizing the size and health of the community—not technical quality, not profits, not performance, ...