Books for software engineers and managers

Working in Public

The Making and Maintenance of Open Source  Software

by Nadia Eghbal

Categories:
Tech Lead,
Star Engineer,
New Engineer

Open source creators are intrinsically motivated by fun, not external factors like money or  fame

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.

Creators quickly turn into maintainers and become overwhelmed with  requests

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.

Developer anxiety comes from expectations around collaboration, not making code  public

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?

Shallow, small pull requests are overall detrimental to open  source

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.

Fear of committing faux paus prevents  contributions

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.

Open source depends on  heroes

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.

We shouldn’t be so confident in the companies behind OSS like React and  Flutter

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.

Working in Public

How strongly do I recommend Working in Public?
8 / 10

Although the author previously worked at Github, this book is about open source development and interactions, not Github.

This book is very well written and flows naturally. I finished reading in three days. My favorite parts were quotes from open source creators of projects like Bootstrap, Node.js, Sprockets, webpack, Rust, and many more.

The author focuses on the most popular projects, where the interactions and expectations are much different than the open source personal projects many developers casually release onto Github and never revisit.