Things I’ve enjoyed reading about open source in 2016

I started this post back in February after reading Nadia Eghbal’s “What success really looks like in open source” so that I’d have something other than tweets to reference when I wanted to refer back to some good stuff.

So here’s a list, not in any particular order, and including the article already mentioned, of some things I’ve enjoyed reading about open source in 2016:

There were many more great articles that I likely forgot to add here, but that list is a good one to revisit.

The next two are videos. The first is Pieter Hintjens on building open source communities. I was so in love with this talk from the beginning that I opened a new post window to start writing while I was watching.

Pieter Hintjens on Building Open Source Communities

Hintjens, who passed away earlier this year, left behind a so very useful body of work in his writings on open source, development, and everything else. I know I’ll continue to go back and discover nice pieces.

The next video is Joshua Matthews on optimizing your open source project for contribution. Yet another one where I was just nodding along the entire time. I know I picked up a few useful tips from this.

I kind of like that I kept this post rolling this year, so I’m going to try to do the same thing next year. It’d probably be good if I wrote a sentence or two along the way on why I felt the piece was important enough to revisit!

Enjoy and feel free to send me links on open source that you think might be missing from the list above.

Pieter Hintjens on Building Open Source Communities

This was a really interesting listen. Pieter Hintjens, the founder of ZeroMQ, lays out a handful of rules for building open source communities.

  1. Put people before code.
  2. Make progress before you get consensus.
  3. Problems before solutions.
  4. 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.”