Peter Hinchens about Optimistic Merging: First people, then code. Build the right community and it will write the correct code

I spoke at DomCode in November 2015 (a great 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 merdzhit patches quickly, without waiting for the completion of testing the continuous integration (Continuous Integration) and without re-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 have to wait until the testing of continuous integration 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 start anew. At this stage, the maintainer can easily say: “I don’t like the way you did it” or “This does not coincide with our vision of the project”.
')
At worst, weeks and months may pass before the patches are accepted. Well, or they can never accept, 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 creates PM:

• He seems to be telling the participants: “you are guilty until proven otherwise.” And this negative message causes them negative emotions. Participants who feel ill at ease will always look for alternatives to this project. Scaring the participants is bad. But even worse - making quiet, silent enemies.
• He gives accompanying people some kind of patronage over many contaminated distributors. They can do it unconsciously. However, this problem is widespread. Accompanying by nature tend to always remain central to the project. And if they have the ability to keep potential competitors at a distance, they will do it.
  
  
• He gives way to discrimination. It can be argued that the project belongs to the maintainer, so they have the opportunity to choose with whom to work. 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 experimental failure cycles. Some of them help to find any problem or to understand that the product is ineffective. Some make corrections that are then tested and work or fail. So we learn something new. The faster this cycle goes, the faster and more accurate the project will progress.
  
  
• It enables outsiders to “troll” the project. This is as simple as a regular patch deviates: “I don’t like this code.” Discussing the details may require much more effort than actually writing the code. 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 at the same time sad 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 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 a bunch of bugs.
3. Mediocre contributors who write the useless patches.
4. Troll contributors who ignore the rules and write malicious patches.

The PM concept assumes that all patches are malicious, as long as they are not recognized as clean and useful. While in reality most patches are initially useful and worth the improvement.

Let's compare the 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 pass quickly or slowly. And at least one good contributor will remain unhappy.
   OM: Good contributors are happy, appreciated, and continue to write excellent patches until they deliver the project.
2. PM: contributors retreat, fix patches and come back a little ... humiliated.
   OM: A second type of contributor joins to help fix their first patch. We get a cool cool patch party. New contributors now have friends and mentors in the project.
3. PM: We get verbal skirmishes and 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 the brute force of the arguments, which affects the “hit or run” reaction. The community is pushing disgusting patches.
   OM: All existing contributors are immediately returned to the project. There are no discussions. The troll can try to attack again and, eventually, will be banned. Malicious patches will forever remain in the history of the gita.

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

In most cases (for patches that still have a lot of work to do) 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:

• First people, then code. Build the right community and it will write the correct code.
• First progress, then consensus. The final progress that you make is more important than the original established agreements (not counting the rules).
• First, problems, then solutions. The process should proceed from the problem being solved.
• First the rules, then the expectations. Write down your development process or use rule C4.1.
• Merit first, then authority. Treat everyone fair and equitable.
• First the market, then the product. Aim for a market of competing and interacting projects, not just a product creation.

Translation: Alena Karnaukhova

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

Read more

• Paul Graham's strategic speech at Defcon 2005: “Inequality and Risk”
• Paul Graham: crack, meth, internet and facebook