Ten rules for open source success

[[151765]]

Everyone wants it, and many are trying, but the process of creating it is full of tears. I'm talking about free software, also known as open source software (Translator's note: The focus of this article is not to distinguish the concepts of free software and open source software. The author says so, so let's assume that the two are the same thing). Today I want to talk about my thirty years of experience in writing code with ten proven rules.

1. People first, code later. This is the golden rule, taught to me by Isabel Drost-Fromm. Focus on building the community, not the software. Without a community, your code may solve the wrong problem. It will be abandoned, ignored, and eventually die. Attract talent first, then give them room to collaborate. Give them challenging work. Don't write the code yourself.
2. Use a share-alike license. Share-alike licenses are the insurance policy for open source software. Don't boast that you don't need them. One day you will be slapped in the face and covered in bruises. Don't be slapped in the face. Use a share-alike license. If GPL/LGPL is too political for you, use MPLv2.
3. Don't expect consensus. Seeking consensus before making a decision is like expecting to find your ideal life partner. It's a bit unrealistic. Github threw consensus away and designed a fork/pull-request process, so you don't have any excuses in 2015. Just accept patches, just like Wikipedia accepts additions. Merge code first, then fix problems, then discuss them. Put all development work on the master branch. Don't keep users waiting. This is how you get de facto consensus.
4. Problems first, solutions later. Focus yourself and your teammates on problems, not features. Every patch must solve a real problem. Experimental code is welcome, and wild ideas are welcome. But don't let these things become too big. Collect good solutions and discard bad ones. Allow failure, failure at all levels. It is the only way to grow.
5. Define first, then implement. Actively document and test the definitions of APIs and protocols. Use continuous integration to test public APIs and protocols. Code coverage is not important, and code documentation is not important. What matters is that the code implements what is defined, and implements it well.
6. Internal development: Make contributors maintainers, and maintainers owners. Do this calmly and relaxedly, don't be afraid. Keep the power to kick out bad performers. Encourage people to create their own projects, especially new projects based on existing projects, or projects that compete with existing projects. Remove power from those who perform poorly on a daily basis.
7. Write down the rules. Once you have your own rules, you should write them down so that everyone knows them. In fact, you don't have to write them at all. Just use the C4.1 rules we designed for ZeroMQ. If you want, you can simplify these rules.
8. Use your power to enforce the rules, not to bully others into agreeing with the project's vision. Most importantly, follow the rules yourself. There is nothing worse than encouraging a small group of maintainers who will kill a patch simply because they don't like it. OK, that's a bit of an exaggeration, there are worse things. But these small groups are harmful to the project.
9. Strive to build a group of small, independent, self-organizing, competing projects. Don't build big projects. By "big projects" I mean projects with two or three core developers. Don't use submodules or the like to specify dependencies. Let others choose the projects they want to integrate. This is the basic rule.
10. Keep a happy atmosphere Maybe you noticed that I didn't mention "innovation". If I did, it would probably be 11 or 12th. No matter what, you should create a positive and happy atmosphere for the community. Don't call a question stupid, don't call a person stupid. There will always be some people in the community who behave badly and break the rules even when they are clear. Apart from these people, everyone else is worth cherishing and we should treat them like guests from afar.