Working in Public

The developers interviewed overwhelmingly create and release open source software (OSS) for fun. They often view their work as a neat hack, solving a problem they directly face.

Jacob Thornton, the co-creator of Bootstrap described it well – you know about free as in beer and free as in freedom, but he introduces free as in puppy.

You’re offered a free puppy and it’s super fun to have a puppy. You’re playing all the time and watching this puppy grow up. Then you realize your puppy is 70 pounds and is actually a dog now that needs real care and ongoing attention.

A similar thing happens in open source. When open source projects gain traction, creators start receiving support requests. While some people request features, many are seeking for implementation help.

Maintainers can be quickly overwhelmed, not with pull requests but with open tickets by users looking for hand-holding.

At this point, some creators go dark. Other maintainers bring on people just to manage issues. And finally some try doing it all themselves.

I’m torn about this. On one hand you want to work with well supported libraries. But on the other hand, users of those libraries need to RTFM and do actual programming. Some of the examples provided illustrate the fact that many developers aren’t willing to do either.

OSS creators generally aren’t worried about making their code public. With the rise of Github, sharing code publicly is the new normal. Rather, these developers feel anxious about the collaboration expectations placed on them.

Should new features be voted on democratically? Who needs to approve pull requests? What is a reasonable response and fix time for issues?

Many people recommend you make a small pull request to get your feet wet in OSS, but overall these have a negative effect on the community.

The author uses the example of language translations. On the surface it sounds great – someone volunteering to translate the documentation into their native language that the author doesn’t know.

But who is going to maintain the translated documentation when methods are deprecated, new patterns emerge, and new versions released? In many cases that contributor has disappeared. Knowing this in advance, the maintainer will politely decline the contribution.

Many developers want to contribute to OSS projects, but are afraid of committing a faux pas.

Some projects like Drupal intentionally create this barrier by hosting outside of Github, where the social norms are unknown to outsiders. In turn, Drupal gets fewer shallow commits.

In 85% of the most popular projects on Github have a developer that participates in 80% of the discussions around a commit. Those developers introduce fewer bugs as well.

In other words, while we like to think about a community being behind a project, we should really be thanking the project heroes.

React was created by Facebook and Flutter by Google. Many developers find comfort in thinking that there’s a big company behind the technology they’re using.

But companies have profit motives. If OSS development or the project itself is no longer demonstrating business value, it may be cut and handed over to the community. Extrinsic motivators are fickle.

Similarly, we find comfort in thinking that the company (thousands of engineers!) is behind the project. But we now know that’s demonstrably false – those projects are also run by a very small group of heroes doing the bulk of the work.