I’ve just finished reading Working in Public: The Making and Maintenance of Open Source Software by Nadia Eghbal (now Nadia Asparouhova). I discovered it via an a16z podcast episode entitled Learning from Open Source Communities.

People often use the term ‘Open Source’ in a way that downplays the extremely heterogenous landscape:

The term “open source” refers only to how code is distributed and consumed. It says nothing about how code is produced. “Open source” projects have nothing more in common with one another than “companies” do. All companies, by definition, produce something of value that is exchanged for money, but we don’t assume that every company has the same business model. (p.54)

So if we can’t easily refer to ‘Open Source communities’ in general, how are we to understand them?

There are many different scenarios for Open Source projects and the communities around them. One of the most useful parts of Working in Public is a typology based around comparing user growth with contributor growth.

Grid showing typology of Open Source communities
Original image from ‘Working in Public’

The version of this typology below is WAO’s interpretation, which flips the columns in the original to make the high contributor growth and high user growth appear in the top-right quadrant. This is to make it easier to read. We also rename ‘toy’ projects as ‘side’ projects to avoid being dismissive of some types of Open Source projects.

Taking each in turn:

  • 🛹 Side projects — low contributor growth and low user growth. These kind of projects serve to scratch an itch or made just for fun. This is not to say that they can’t be used for more serious activities, but that the original intention wasn’t to scale. Usually, there’s only a single ‘project lead’ (although even that term seems a bit too formal) and it’s unlikely anyone else really uses the product. As a result, there doesn’t really need to be much governance.
  • 👥️ Clubs — high contributor growth but low user growth. These kind of projects tend to be a group of people working on something that may be potentially niche but personally or professionally relevant. Most users in this scenario will also be contributors and they are collectively scratching an itch. There is likely to be more governance and collective decision-making necessary around this kind of project.
  • 🏟️ Stadiums — low contributor growth but high user growth. These kind of projects tend to be either super-niche projects which nevertheless are relied on as infrastructure or popular projects because of parasocial (i.e. one-sided) relationship between ‘creator’ and ‘audience’. Although there will be many ideas and suggestions as part of this community, in terms of governance it’s likely that a very small number of people, make the decisions.
  • 🔱 Federations — high contributor growth and high user growth. These kind of projects tend to be larger and more mature projects which may be backed by an incorporated organisation. As a result, they are more likely to have a governance model which includes established procedures such as decision-making workflows.

This quadrant-based approach is a broad-brushstroke attempt to roughly define how a project sits relative to others. The boundaries are fuzzy:

The difference between these project models is not precisely defined. At either extreme, we can see clear differences. We can say that Linux, a project with multiple subprojects and working groups, does not look like tslib, a small helper library for the programming language TypeScript. But the middle is a little murky. There are some projects with four or five maintainers, and other projects with many contributors who are not deeply involved. (p.77)

Eghbal’s focus is mainly on technical projects which are hosted on GitHub, but I think this is much more widely applicable to some of our client and community work. I’m looking forward to applying this as I think it helps clarify thinking around governance in particular.

For example, presenting the four different types of community around a project makes it easier to ask whether the project lead conceptualises the community as more of a club or a stadium?

If you need some help with your community, get in touch! WAO are specialists in the Venn diagram overlap between learning, technology, and community 🙂