- Put people before code.
- Make progress before you get consensus.
- Problems before solutions.
- Contracts before internals.
Everything you do as a founder of a community should be aimed at getting the people into your project and getting them happy and getting them productive.
And one of the ways to do that, according to Hintjens in rule 2, is to merge pull requests liberally and get new contributors’ “vision of progress on record” so that they immediately become members of the community. Worry about fixing the progress later.
His thoughts around licensing (our contract) were also interesting. Without formal contracts, then pull requests rely on the license applied to a project. If a project has a very lenient license, such as MIT, and somebody forks your project, it’s feasible that a different license could be applied to code the submit back to the project through a pull request. If a project has a share-alike license—his example was MPLv2, I’m familiar with GPL—then you can rely on incoming patches already being compatible without additional paperwork.
I’d like to explore more around that, as I’m sure there are some other legal angles. It does further stress that paying attention to the license you choose is good. It would be interesting to see if my thinking had changed during our late license selection process for VVV.
The Q/A has some good gems too, great questions and great answers, so keep listening. Here are two of my more favorite answers. 🙂
“throw away your ego, it will help a lot”
And, in response to someone asking why you shouldn’t just let everyone commit directly to master.
“If you send a pull request and somebody says merge, it feels good. […] If you’re merging your own work, […] it feels lonely, you feel uncertain, you start making mistakes, and no one is there to stop you.”