I've been reading "Working in Public: The Making and Maintenance of Open Source Software" by Nadia Eghbal. And I like writing little summaries and notes when I've read books with others in a book club style in the past

So for this I'm going to do a 'Book Club' with all of you! As I read each chapter I'm going to write up a summary of the chapter and my thoughts on it.

If you want to buy the book, while supporting me and local bookstores consider using my bookshop.org link below

💰 Affialiate Link: Buy now

"Open Source" the label is about how software is disturbuted, not how its made. While open source projects may be distributed in similiar ways, they can be produced in wildly different ones.

Open source is stereotypically thought of as something where anyone can contribute to any project at any time. But in reality there are more limiting factors. First each project has a relatively smaller set of commiters, who are allowed to actually commit to the project. For others you need to submit a Pull Request and get it reviewed and merged by a maintainer/commiter. For some projects becoming a maintainer can be as straightforward as participating in the community, and in others it can require an in person meeting with a fellow maintainer. Older and larger projects tend to have more roadblocks in place for new contributors.

Github has become the 'core' of an Open Source project, but there is more to a project than just the code. Other things like issues, pull requests and discussion forums are also important channels that a project needs to thrive. Github offers tools for many of these functions, but some communities use their own tools instead.

Projects aren't static in time, they grow and evolve as their members do. There are three 'stages' to an open source project: creation, evangelism and growth. As a project 'grows' up so can the roles of its maintainers. In the creation phase its common for a maintainer to work alone, sometimes before even open sourcing their work for the public. When they release their work its time to evangelize the project and help it grow. This often involves advertising the project among social channels, and giving talks and presentations about your project. The final 'stage' is growth, where the project is growing and attracting new users. Here the maintainers role might change again, where they shift to a more managerial-organizational role. They may spend more time organizing contributors and answering questions than they do coding their project.

Just like there are different stages to an open source project there are also different types of projects. The main factors that determine a projects types are: technical scope, support required, ease of participation and user adoption.

Federations are what we think of as the typical open source project. Both the maintainers and users are growing, and the communities can start to look similiar to a company. There are often sub-groups of maintainers that each control a sub-section of the entire project. As the project grows and scales each of these sub-sections might grow enough to be split up even more

Clubs are defined by having a network of users, where a majority of them as also contributors to the project. The user growth is slower, but users are more likely to become contributors as they feel a sense of belonging to the group. Clubs can be highly "sticky" in that they retain most of their users, even if they are slow to attract new ones.

Toys are small projects that aren't intended to grow. Maybe something the author works on in their freetime for themselves.

And finally stadiums are projects where single developer or small group of maintainers, runs large project with many many users. They will often recieve contributions from users, but the core base of maintainers does not scale with the user growth. Stadiums are less about the community between members, and more about the relationship of the maintainers with each indivodual. Stadiums are more closely related with creators who build a community around themselves, as much as their projects.

Different project types have different needs from their tools. Clubs, for example, are usually more able to change platforms, since they have a highly engaged community. Where Stadiums rely much more on the platforms, like Github, to manage their communities. Stadiums are more likely to stick with the same tools that help them reduce the support burden of their projects.

I like both the definitions in this chapter; the stages and types of open source projects.

The thoughts on clubs seemed specifically relevant to Battlesnake. I think one thing that I want to keep in mind is that Battlesnake is probably closest to a club today, so we don't need to act like a Federation or a Stadium.

From a toolmaker perspective the stadiums seem like the segment to go after. Clubs and Federations feel more likely to build their own software and tools. And toys likely won't be buying as many tools. This chapter mentions that this makes GitHub so valuable to stadiums, and I think adjacent tools are in the same category.