"1. People Before Code"<p>Agreed, but if you are the only user, serve yourself first on the project. If you determine that you can't serve yourself and others at the same time, it might be a bad road you are going down.<p>"2. Use a Share-Alike License"<p>First, RMS hates the term "open-source", so it's funny that the idea is to promote GPL here. On top of that, you call for a share-alike license, which is a term used mostly for creative commons licenses, which are usually for creative works.<p>The license matters, but most people suggest Apache. (L)GPL v3 (not v2) is also great if you don't want it to be integrated into business products. I'm not sure why you'd want to use MPL v2 unless you are writing something for a Mozilla product? If you don't give a crap about your rights, choose MIT. Then, use a Creative Commons license for creative works that aren't free.<p>"3. Use an Zero-Consensus Process"<p>"Merge first, fix later"<p>No, don't do that. I understand you are trying to keep other forks from taking over, but you shouldn't allow everything. I've rejected some bad PRs before because the developer didn't understand what they were doing. There's no reason to merge that and then undo it. Explain to them what they are doing wrong and refuse the merge- then they will either fix it or you save yourself the trouble of having to undo it.<p>"4. Problem, then Solution"<p>"Every patch must be a minimal solution to a solid problem" is wrong. New features may not relate to a problem you or others are trying to solve.<p>"5. Contracts Before Internals"<p>Not every project needs its API documented to be successful.<p>"7. Write Down the Rules"<p>Those rules for ZeroMQ are really aggressive sounding. You don't have to use those. I think it's fine to just point people to docs about the PR process and information on how to build, test, release, etc.