Peter Hinchens on Optimistic Merging: People first, then code. Build the right community and it will write the code you need

I spoke at DomCode in November 2015 (an excellent conference, by the way; was held in a small beautiful town) and talked about my list of rules for building open source communities. One person later asked me to explain why I advise merging patches quickly, without waiting for the Continuous Integration test to complete and without double-checking the code. I will call this strategy optimistic merging (OM). And now I will talk about some of its advantages.

The standard practice for many communities is pessimistic merging (PM). This is when you first need to wait until the continuous integration testing is completed, then review the code, then test the patches on the branch and then give feedback to the author. Then only he can fix the patches, and this whole cycle will begin anew. At this stage, the maintainer can easily say: “I do not like how you did this” or “This does not coincide with our vision of the project.”

In the worst case, weeks and months may pass until patches are accepted. Well, or they may never be accepted, and they will be rejected for thousands of different reasons.

It seems to me that in many projects the concept of PM is somewhat misunderstood. Let's list the problems that PM creates:

• He kind of tells the participants: "you are guilty until proven otherwise." And this negative message causes them negative emotions. Participants who feel at ease will always look for alternatives to this project. It is bad to scare away the participants. But even worse - make yourself quiet, silent enemies.
• He gives accompanying some protection over the contributors , which many abuse. They can do this unknowingly. However, this problem is widespread. Accompanying by nature strive to always remain the main ones in the project. And if they have the opportunity to keep potential competitors at a distance, they will do it.
  
  
• It gives way to discrimination. It can be argued that the project belongs to those accompanying them, so they have the opportunity to choose who to work with. My opinion: projects in which there is discord between the participants will die, and deserve it.
  
  
• It slows down the learning cycle. Innovation requires fast experimentally failed cycles. Some of them help to find a problem or understand that the product is ineffective. Some make corrections, which are then tested and work or fail. So we learn something new. The faster this cycle proceeds, the faster and more accurately the project will advance.
  
  
• It provides an opportunity for outsiders to "troll" the project. This is as simple as rejecting the next patch: “I don't like this code.” Discussing the details can take a lot more effort than writing the code itself. In addition, it is much easier to condemn the finished patch than to write it. All this is honey for trolls and punishment for honest contributors.
  
  
• He burdens each contributor with a separate job , which is ironic and sad at the same time when it comes to open source. “We want to work together, but we were asked to fix bugs separately.”

Now let's see how this happens in the Optimistic Merge (OM).
To begin with, we understand that all patches and all contributors are different.

We can notice at least 4 types of contributors in open source projects:

1. Good contributors who know the rules and write great patches.
2. Good contributors who make mistakes and write useful patches with tons of bugs.
3. Mediocre contributors who write patches that nobody needs.
4. Troll smugglers who ignore the rules and write malicious patches.

The concept of PM comes from the fact that all patches are malicious until they are recognized as clean and useful. While in reality most patches are initially useful and worth the improvement.

Let's compare PM and OM. What happens when all 4 types of contributors consistently come to the project?

1. PM: Depending on arbitrary criteria, merge patches can be fast or slow. And at least one good contributor will remain unhappy.
   OM: Good contributors are happy and appreciated and continue to write great patches until they pass the project.
2. PM: Contributors back down, fix patches and come back somewhat ... humiliated.
   OM: A second type of contributor joins to help fix their first patch. We get a short cool patch party. New contributors now have friends and mentors in the project.
3. PM: We get verbal skirmishes and a lack of understanding of the reasons why society is so hostile.
   OM: Everyone ignores the mediocre contributor. If the patch needs to be fixed, then this is done without delay. The contributor loses interest, and ultimately leaves the project.
4. PM : We get a skirmish in which the troll wins by brute force of arguments, which affects the “fight or run” reaction. The community is pushing disgusting patches.
   OM: All existing contributors immediately return to the project. There are no discussions. The troll may try to attack again and, in the end, will be banned. Malicious patches will forever remain in the history of the gita.

In each of these situations, the consequences of OM are much better than the consequences of PM.

In most cases (for patches that still have a lot to work on), OM creates the conditions for training and mentoring. And this is exactly what can be seen in the ZeroMQ project, and the reason why it is so cool to work with them.

References:

ZeroMQ (http://rfc.zeromq.org/spec:22), C4.1: the Collective Code Construction Contract.

And a few more tips:

• People first, then code. Gather the right community and it will write the code you need.
• Progress first, then consensus. The final progress that you will achieve is more important than the initial established agreements (not counting the rules).
• First problems, then solutions. The process should be based on the problem being solved.
• First rules, then expectations. Record your development process or use rule C4.1.
• First merit, then authority. Treat everyone fairly and equitably.
• First the market, then the product. Strive for a market for competing and collaborative projects, not just create a product.

Translation: Alena Karnaukhova

Publishing support - Edison company , which develops a billing system for providers , as well as develops software for tax reporting via the Internet .

Read more

• Paul Graham's Strategic Speech at Defcon 2005: Inequality and Risk
• Paul Graham: crack, meth, internet and Facebook