Working in Public by Nadia Eghbal - Book Review

Open source software powers much of the modern world even though its creators and maintainers are not paid. And in fact, maintaining a popular open source package is quite expensive in terms of the attention and hours required of a skilled software developer who could spend their time elsewhere. So why do developers do it? And how is it that trillions of dollars rest on the work of unpaid–and often unseen–volunteers?

Or, as xkcd just put it:

This is the question addressed in Nadia Eghbal’s recent book, Working in Public: The Making and Maintenance of Open Source Software. Eghbal is a writer who has focused on this issue for the past 5 years, including several years at GitHub, the largest open source repository. She is well suited to tackle the question and interviewed hundreds of open source developers during that time. This is also the first book I’m aware of to focus on the issue since Producing Open Source Software by Karl Fogel, which was first released in 2005.

Personally, I have a strong vested interest in the question. I’m a Board Member (Treasurer) of the Django Software Foundation, the non-profit that runs the Django Web Framework, and intimately familiar with many of the challenges listed in the book.

Eghbal’s work started focused on the lack of funding open source developers face, but she soon learned that money was only one of the issues. Even paid open source developers go through a similar sequence that she describes as follows:

“The cycle looks something like this: Open source developers write and publish their code in public. They enjoy months, maybe years, in the spotlight. But, eventually, popularity offers diminishing returns…a developer who’s employed at a private company works primarily with their colleagues. A developer who writes code in public must work with thousands of strangers.”

Or, as Byrne Hobart memorably put it, “running a successful open source project is Good Will Hunting in reverse, where you start out as a respected genius and end up being a janitor who gets into fights.””

A genuine conflict exists for maintainers who want to encourage newcomers to work on a project, but become overwhelmed by the volume of typically low-quality work that emerges. The maintainer cannot personally mentor each new contributor. For most popular open source projects, it is the norm, not the exception, that a small number of maintainers/contributors perform the majority of the work.

The first half of Working in Public focuses on How People Make, specifically how online platforms like GitHub have expanded and changed the open source landscape. The “typical” structure of an open source project can vary from the small modularity common in the JavaScript world to a larger project like Django and an even more massive one like Linux. A particularly interesting section was Chapter 3, which focused on the various roles developers adopt, and the resulting incentives and relationships that emerge.

The second half of the book looks at How People Maintain, which is more relevant to a mature framework like Django. Simply put, an inordinate amount of work is required to keep software up-to-date and this is not typically “fun” work. It is what most professional developers are paid to do, but it is not what lights the fire in the heart of a developer wanting to do free after-hours work on a project. It is, therefore, an area handled very differently in each case. Some developers simply create new projects and pass off leadership quite freely. For larger projects, this is more of a challenge and often some version of a dictatorship emerges, where a single or small group decides the overall direction.

Django itself was led by two of the creators, Adrian Holovaty and Jacob Kaplan-Moss, as Benevolent Dictators for Life, following the mold of the Python programming language. However they stepped down in 2014. If you’re curious how Django is run today, I wrote a separate post on its structure.

The last part of the book focuses on the role of money in open source, which initially spurred the author’s interest in the topic years ago. It is, unfortunately, the least satisfying because there is no clear approach to adequately compensate open source developers. As she notes, “There is no one-size-fits-all solution here, because open source has matured to the point that, while its distribution licenses have been standardized, we can no longer tell a unified story about how it is produced.”

One insight highlighted is the idea of “attention as the currency of production.” In other words, there is no direct cost to a developer for creating a new project. But juggling requests from newcomers, adjudicating debates among community members, and so on does indeed impose a real cost. It’s not so much the code as the community of people that is taxing.

Personally, I find it interesting to see examples like Laravel, where the creator gives away the code but makes money on the ecosystem, such as a hosting solution or SAAS scaffolding via a project template. Or Tailwind CSS, which is monetizing via Tailwind UI, components that are sold to Tailwind developers at a premium. In both cases, one (or two) people are responsible for the majority of the work so users feel a personal connection to the creators. It also helps that both projects are used by agencies, who can pass along the costs to clients.

Ultimately, Working in Public was a rewarding read. It should be of great interest to any modern software developer. There are insights and examples to takeaway whether you are a newcomer to programming or a professional relying hundreds of open source packages to make your private code work. Even open source maintainers, intimately familiar with the issues listed, will come away with a broader sense of community and new ideas on how to make open source fully sustainable for those involved.