This week I read chapter 3 of Nadia Eghbal’s Working in Public: The Making and Maintenance of Open Source Software with my open source book club at work. I wanted to write my response because it was a very thought-provoking chapter about the different types of members in open source communities.

Types of open source communities

Before discussing my thoughts in response to chapter 3, I need to mention her four models of open source communities (which she defines in chapter 2). According to Eghbal, open source communities can be broken up into four types of communities along two axes: number of contributors and number of users. It’s less important to pay attention to the raw number of contributors or users as it is to note the relative ratio of these populations in the community. As projects mature and change, they will move through these different types of community structures:

Federations are rare but they are the examples we most typically think of when we talk about open source. This includes communities like Rust, Node.js, and Linux.

As for stadiums, my workplace’s open source community Salt is likely somewhere on the continuum between a stadium and a federation, but leaning more closely to a stadium. In the stadium model, a few contributors do the vast amount of work while being observed by a lot of users. Salt is a Python-based configuration management software project with over 2,000 contributors listed on . However, most of those are casual contributors and only a small percentage of those are active contributors. The active contributors do most of the work for the project. As a side note, I sometimes personally feel like I’m in a stadium when I run a Salt docs jam, an open source docs clinic, or a Salt docs working group meeting. That’s largely because we usually stream these events live to the community. It feels a little bit like working in a fishbowl or performing on a stage: I’m quite literally working in public. It’s not necessarily a bad experience, but occasionally it does feel a little surreal.

My other open source community The Good Docs Project is more like a club at this stage. The goal of the Good Docs Project is to improve open source software documentation by providing both high quality templates and writing instructions to the open source community. We have a vibrant community of technical writing contributors, but our project is still young and hasn’t attracted a user base yet. We have some grand ambitions to increase the templates we offer to open source projects and expand our user base, but we still have a way to go.

As for toys, if I’m ever stumped about how to find something to talk about with a developer at work, I just ask them whether they have a personal open source project. They often get a gleam in their eyes and excitedly tell me all about it (and then say they’d love my help documenting it). It feels like every developer has a pet project like this. Some of them are really cool ideas with a lot of real-world potential. But often they are the only ones working on the project or using it.

Active vs. casual contributors

In chapter 3, Eghbal defines and discusses her research about the different kinds of participants in open source projects. This chapter felt a little like reading an anthropological study of open source social structures.

I made a graph illustrating the different types of community members that contribute to open source projects that Eghbal discusses:

I’m not going to define or describe each of these types of community members in depth; you can read the book itself to get the details. (And I do recommend reading this amazing book!) But I want to comment on my take-aways from this chapter about active contributors vs. casual contributors.

According to Eghbal, active contributors and casual contributors are quite different from each other. Active contributors:

• Make higher quality commits because they have more context for the project.
• Stay with the community over the long term.
• Occupy a position of trust within the community.

What was interesting to me was that, as Eghbal notes:

While contributors are sometimes described as moving through a “funnel” from user –> casual –> active –> maintainer, there’s evidence that incentives to participate differ between casual and active contributors from day one.

Active contributors might look like casual contributors at first… but their motives are different. During their first month, active contributors tend to exhibit prosocial attitudes, demonstrating a higher level of motivation to help others. …

Active contributors who stick around do so not because they successfully made their first contribution, but because they already came in with the intent to stick around. In other words, they were never really casual contributors in the first place. …

An active contributor is often motivated by a desire for community, but they might have secondary motivations around reputation and learning. They enjoy the social aspects of the project and want to feel as if they’re “part of something" (98-99)

What I think is particularly worth highlighting here is that active contributors start out with different, more pro-social incentives to contribute from the beginning. They are motivated to participate because “they perceive than they can make a meaningful contribution” (p. 98).

As a teaser to go and read more of the book, she also discusses that there are four elements that are necessary to have a successful commons in an open-source project:

1. Intrinsic motivation – Members do the work because they want to.
2. Modularity – The project is organized into clear subcomponents that can easily fit back together.
3. Granularity – Each module is small and easy for anyone to jump in and complete the task without too much pre-existing knowledge.
4. Low coordination costs – Maintenance costs that ensure quality such as onboarding and mentoring new members, reviewing contributions, and merging in pull request should not outweigh the benefits of the project.

How the Good Docs attracts active contributors

In the interest of exploring how to attract more active contributors to open source communities, I wanted to validate Eghbal’s findings with my own personal experience in the Good Docs Project. I started out as a contributor to this project in May and then moved into the role of a maintainer after a few months (which this community calls the project steering committee).

I think Eghal is right about active contributors being different than casual contributors from the start. I first came to the Good Docs with the intent to stay. I found out about the project through a talk by Erin McKean at a Write the Docs Bay Area meetup and felt an instant interest in it and a desire to know more. What attracted me was that it seemed like a significant project to which I could make a meaningful contribution. Writing high quality templates and helping review other people’s templates is something I felt pretty confident I could help with. (Plus, Erin just seemed like she’d be really fun to work with!)

I had some secondary motivations too. I hoped that any high quality documentation templates that other tech writers submitted to the project could possibly be used upstream at Salt. I also thought that it would be a great way to grow my network and improve my skills since this project gives me a chance to work with and be mentored by other technical writers, many of whom have some impressive credentials.

It has also been fairly easy to make a meaningful contribution to the project. If you have a technical writer background, it’s easy to pick up a task and make a contribution as an individual without too much onboarding or preparation. The coordination costs are relatively low and the tasks are modular and granular. Although our project could still iron out some of our processes for reviewing and merging pull requests to make them more smooth, it’s still relatively easy to submit work and get high quality reviews before merging it into the project.

In this chapter, Eghbal included an image in which a developer at a Python conference holds up a shirt that says, “Came for the language, stayed for the community.”

That’s how I felt over the course of time working for The Good Docs. I came for the project, but ended up staying for the community. I’m starting to feel like the folks at the Good Docs are my friends and that they’re just really fun and interesting to work with. I discovered through this project that one of my favorite ways to socialize with people is by working together with a common purpose to make a difference.

In September everything shifted for me when one of the project’s leaders, Cameron Shorter, nominated me to join the Good Docs project steering committee. This nomination came as a total surprise. At this point, I hadn’t planned or intended to climb the ranks of the community. But something about the nomination felt very validating in a way I hadn’t expected. It instantly kindled a deep sense of loyalty to the community and a desire to make long-term commitments to the project.

I sincerely enjoy participating in the Good Docs project. As I said before, I love the community and learn so much from working with them. In the past, I’ve been part of a lot of other community service projects that felt more like stadiums in which a few people (often me) did all the work while everyone else spectated. It’s refreshing to be part of a healthy community where everyone pulls their own weight and works their hardest to make a difference. Hopefully, other open source projects that would like to attract more active contributors can take some of the best practices used in the Good Docs and try to apply them to their communities as well.