I recently picked up a copy of the book Working In Public by Nadia Eghbal. I was especially interested in reading this book as I recently became a GitHub Star and am currently working full-time on open-source work for the first time.

I am hoping to walk away from this book with a better understanding of how to help folks newer to open-source who are interested in making meaningful contributions to open-source as well as, what does (or could) sustainable open-source look like.

Introduction

In the introduction of Working in Public, Eghbal discusses the tension between initiatives to help more developers contribute to open source and the fact that often the responsibility of working with new contributors is delegated to a few people (maintainers) who might feel overwhelmed by an influx of casual contributors. Casual meaning they only make one-off contributions and might even disappear before submitting their first contribution!

Knowing that maintaining takes time, energy and is often volunteer-based leaves me wanting to further explore how can I help people make meaningful contributions to open-source? I believe that for most projects that welcome contributions, a high-quality contribution outweighs the cost of maintenance, but I also am not the maintainer of an open-source project that gets a significant amount of casual contributors.

I've viewed open-source as a community effort but the most popular open-source projects are often predominately the resulting work of a few active contributors or maintainers. This lopsided distribution of work within open-source is evident in contributor graphs and Eghbal points out that 73% of commits to the popular design framework, Bootstrap can be attributed to three developers (Working in Public, Page 10). The amount of people that benefit from a particular open-source can far outweigh the amount of contributors.

GitHub as a Platform

GitHub has risen as the predominate platform for sharing open-source code, although there are some notable projects that have decided to not use GitHub (for example GNU). Some projects choose to use GitLab over GitHub, as GitLab is open-source. However it is noted that Python project felt compelled to move from GitLab to GitHub because of its better developer tooling for automation (Working in Public, Page 30). GitHub is popular largely because it's convenient, has strong developer tooling and a lower learning curve as a lot of developers are already familiar with its interface.

Further Reading: The history behind the decision to move Python to GitHub

Things like package managers have shifted how easy it is to install seemingly trivial but out-sourced logic. Tools like NPM and GitHub may have lowered the barrier to entry to contribute to or use open-source software but have they also increased the obligation of end-users to contribute to improving the software that they use? What are the responsibilities of a user of open-source software?

As the community of folks who contribute to open-source grows, how can one be a "good" contributor or user? How can maintainers set up new contributors for success?

Effective onboarding is crucial

Part of the "cost" of onboarding new contributors is newcomers aren't intimately familiar with the norms and standards for a specific project. There are some universal contributing practices you can take from project to project but there are also certain things that are more salient or specific to a particular community. I think taking advantage of GitHub Actions to automate things like linting and testing as well as using and their tools for building a strong community can help alleviate some of the responsibility that falls on both maintainers and contributors.

If you are working on a project that welcomes new contributors what tools, types of automation and documentation do you need to get newcomers up-to speed as quickly as possible? As new contributor I generally look for documentation in the form of READMEs and Contributor Guidelines or Code of Conducts.

The Structure of an Open Source project

Where do you even start with contributing?

Contributing to open-source can seem more intimidating than someone's day to day work, regardless of skill-level required, as when new contributors often onboard to a new project they aren't familiar with the social conventions of the project. This is why if you're looking to onboard new contributors it's crucial to set them up for success by documenting certain norms in an obvious place (i.e, README, issue template, PR template).

Open Source is not monolithic. Eghbal reminds us that "The term 'open source' refers only to how code is distributed and consumed. It says nothing about how it is produced" (Working in Public, 44). There are certain trends within open source but a lot can vary from project to project.

What types of contributions are valued or accepted?

While open source projects allow contributions from everyone there is generally a review process and it may be more or less thorough from one project to another. I find that unless there's already an open issue that a maintainer has given a green light to or a glaring bug it's often best to run a change by a maintainer before going through the effort to implement it. If you want to add a one-off feature that mostly only benefits your use-case and you're not a significant stakeholder then your proposal likely won't make it past the approval process.

I've previously used Open-Source software that I wanted to function differently (i.e, adding pagination) but sometimes the maintainer would rather someone fork (copy and modify the software) as opposed to commit directly to the main repository and change that functionality for everyone. Maintainers balance different interests and can be opinionated in different ways about their project than contributors based on having more context regarding usage and long-term goals.

Getting the keys to an open-source project (write-access)

Getting commit access to a larger open source project unlocks the ability to directly merge changes into the main codebase and be more closely a part of the review process of PRs. How does one get commit access?

There might not be just one way to get commit access to a project but I imagine a lot of people are similar to Brett and end up getting direct write access to a project once they've shown that they have a long-term investment in contributing high-quality updates to a project. Most communities function similarly, generally when you're a positive contributor and more active within a community you are offered more responsibility to contribute back to a community.

Eghbal points out that "it's common among JavaScript developers to give away commit access more freely" as Javascript "is designed to be modular" (Working in Public, Page 46). In the JavaScript ecosystem the benefits (distributing the responsibility of maintenance) of prematurely giving someone commit access may outweigh potential risks (a project being compromised but having minimal impact on the larger ecosystem). I've mostly contributed to the JavaScript open-source community and therefore am not sure how easy or difficult it is to get write access to projects within other ecosystems but I can imagine the effects being devastating for projects that are less modular.

An open-source project can extend beyond just a repository on GitHub. Its community can also live on Stack Overflow, mailing lists, Discord, etc.

Open-source projects are fluid and evolve over time.

There can be a creation phase where there's a lot of foundational work being put into the project and the project isn't seeking or advertising for outside contributors or users. After the creation phase there's an evangelism phase where open source authors want to encourage new users to try out their software and gather as much feedback as possible to use to iterate on the future development of the software. Some projects reach the growth phase where there is significantly more adoption and which Eghbal uses "when maintainers start doing more non-code than code work on the project, such as triaging issues and reviewing others' pull requests" as a signifier of this stage being reached (Working in Public, 55). This growth phase is often when maintainers have to shift to be more selective with what type of contributions and issues they'll entertain from external contributors in order to be mindful of their time.

I would think overall maintainers would be most eager for new external contributors during the evangelism phase as opposed to the creation or growth phase. I also wonder if a project can switch between the evangelism and growth phase...i.e, when a new version of Python is released, although Python is a mature project is there a huge initiative to encourage people to submit feedback and start adopting the newer version.

Aside from projects changing over-time due to adoption and maturity Eghbal also mentions that there are 4 types of open source projects classified by user and contributor growth:

• Federations - High User Growth, High Contributor Growth (very active open-source project, may be the first thing that comes to mind when you think of open source - Rust, Node, Linux, etc.)
• Stadiums - High User Growth, Low Contributor Growth (Widely used but don't have many contributors, i.e. Babel)
• Clubs - Low User Growth, High Contributor Growth (Niche programming languages such as Clojure and Haskell attract a narrow range of users and thus contributors)
• Toys - Low User Growth, Low Contributor Growth (i.e, a side project you didn't create with the intention of distributing to other developers although who knows it could develop traction)

Measuring the value of code

Eghbal brings up questions surrounding how do you measure the value of code? Is it based on the amount of dependencies and their value?

Infamously the JavaScript library, Left-pad, broke a lot of things when it was briefly deleted from the NPM registry as it was an underlying dependency for important and prevalent software. Babel relied on left-pad and Babel is a dependency of millions of software projects. Once something is released into the open source universe it takes on a life of its own and isn’t just yours, it becomes part of a complex ecosystem. Due to the interdependent nature of software on an 11-line package (left-pad) NPM decided to restore the package against the original authors' wishes.

Monetizing Open-Source

You might think that the inherent value derived from open-source software would make it easy to monetize, however, there are some things that make code difficult to monetize:

• Developers are sensitive to price for a good that they could theoretically create themselves. Some software is more prone to this like web frameworks vs databases. Developers are more likely to build their own frontend technology solutions vs. infrastructure related solutions.

• The diversity and breadth of open-source is both a blessing and a curse when it comes to monetization. There’s a lot of variety in the open source world and a lot of software can be substituted or easily replaced with alternative open source solutions

Eghbal shares an example of Sorhus who is able to work full-time in open source based on financial support from patreon and GitHub sponsors. However she believes that it’s his reputation and visibility and not the value of his software alone that has given him enough traction to live off of sponsorship. His sponsors aren’t sponsoring a specific project of his but overall investing in him based on his reputation.

Outside of crowd-sourced sponsorship from individuals, sometimes companies find it worthwhile to support a project’s maintainers as full time employees for reasons like branding, reputation purposes or to have a more direct influence on the future of a project.

The Law and Distribution of Software

The law can’t keep up with software.The US government used to regulate the export of cryptography related software and treated it as a munition export that required tighter regulations. The Pretty Good Privacy (PGP) author Phil Zimmerman ended up releasing the source code as a book PGP source code and internals which could then be more easily distributed around the world since it was protected under free speech (page 157) unlike the actual software in its digital form.

Participatory Open-Source

Eghbal explores various metaphors for how people interact with open source software. What stood out from the metaphors is that a lot of people expect open-source software to welcome participation regardless of the project. Some creators of open-source projects may be perfectly happy sharing their code freely but have no desire to spend additional time tweaking their library to appeal to other users as the intended user of their software is themselves and open-sourcing it is just a "bonus". Eghbal compares this to how some people put up elaborate holiday light displays on their houses for their own enjoyment, as a byproduct their neighbors and travelers also enjoy their light display but the people who put up the lights are not planning on updating details of their light display based on feedback.

“Much of the fatigue that open source developers experience comes not from making their code public but from the expectations around making their code participatory” (page 161).

External participants to a software project often have different interests than maintainers and too many opinions outside of the core group that contributes to and maintains and project can lead to too many cooks in the kitchen.

Final Thoughts

I enjoyed reading Working in Public and having the opportunity to discuss it with the Party Corgi Community, an inclusive community of content creators helping each other grow. Eghbal's research and claims provided important historical context for open-source and pushed me to adopt a more critical lens to how I view the open-source ecosystem. I think the biggest takeaway for me, as someone who wants to make contributing to open-source more approachable (especially as a GitHub Star), is that it is crucial to proactively encourage meaningful contributions and to educate people on open-source norms in an effort to ease some of the responsibilities that are often placed on maintainers.

Further Reading (and listening)

• Get a copy of Working In Public
• Nadia Eghbal and Henry Zhu have a podcast, Hope in Source about faith and open source.
• Henry Zhu also has another podcast, Maintainers Anonymous that is focused on the experience of being a maintainer across various disciplines.
• Why My Blog is Closed-Source
• @richhickey's post "Open Source is Not About You" about his views on the boundaries between open-source creators and contributors
• I Just Hit $100k/yr On GitHub Sponsors! 🎉❤️ (How I Did It)
• The Ethical Open Source Movement

Book Notes from other Party Corgis

• Chris' notes on Working in Public
• Will's notes on Working in Public
• Benjamin's notes on Working in Public