Working in Public: the making and maintenance of open source software

[BekahHW]

Working in Public: The making and maintenance of open source software

Every Friday, I'll post discussion questions in this thread and provide a link in Slack. Feel free to join in and participate in ways that are meaningful to you. You don't have to start at the same time as everyone else. Consider this an async book club that you can jump into at any point.

Part 1: How People Make

July 14: Intro + Chapter 1 - GitHub as a Platform
July 21: Chapter 2 - The Structure of an Open Source Project
July 28: Chapter 3 - Roles, Incentives, and Relationships

Part 2: How People Maintain

August 4: Chapter 4 - The Work Required by Software
August 11: Chapter 5 - Managing the Costs of Production
August 18: Conclusion

[BekahHW]

Week One: Intro + GitHub as a Platform

Intro

• The introduction talks about maintainer challenges related to initiatives supporting more developers getting into open source, resulting in "low-quality contributions" and a lack of community (9). What are some possible solutions to this problem? How can contributors or external communities support maintainers?
• Another challenge maintainers face is balancing "reactive tasks (community interactions) with proactive ones (writing code)" (12). How can platforms, tooling, and even ai help? At what point do platforms, tooling, and ai hurt the community interactions?
• Are contributor communities necessary for a successful open source project?

GitHub as a Platform

• Chapter 1 explores the history of open source software and hacker culture. It also defines the difference between free and open source software. How has this culture shaped the values and principles of the open source movement and how has that changed? In what ways does the culture of open source influence the motivations and behavior of contributors?

• The author says that "[the GitHub generation of oss developers] prioritize convenience over freedom (unlike free software advocates) or openness (unlike early open source advocates)" (30). What do you think about this according to your personal experience with OSS and your observations of OSS?

• Chapter 1 talks about maintainers as creators (32-3), influencers (36), and teachers (40). How does this complicate the role? Do you think this is a good thing or a bad thing?

• As you reflect on the intro and Chapter 1, what aspects of open source surprised you or challenged what you thought about open source? What questions or general thoughts do you have that you hope the book will address?

[dominicduffin1]

The introduction talks about maintainer challenges related to initiatives supporting more developers getting into open source, resulting in "low-quality contributions" and a lack of community (9). What are some possible solutions to this problem? How can contributors or external communities support maintainers?

Another challenge maintainers face is balancing "reactive tasks (community interactions) with proactive ones (writing code)" (12). How can platforms, tooling, and even ai help? At what point do platforms, tooling, and ai hurt the community interactions?

My thoughts about these two problems are that open source projects that aim to be big and have lots of code contributors also need lots of non-code contributors that can handle the "reactive tasks" like project and community management. To facilitate this, I think there is a need for the platforms to recognise this kind of work on an equal footing to code contributions, like an equivalent to the green square graph but for commenting on issues, assigning work, doing tasks in Github Projects, etc. Maybe this is somewhere a third party tool such as OpenSauced can help?

[LaurenC2022]

I liked @jdwilkin4 response with a solution that already exists. The tooling is being made to help solve some issues with open source. I wonder if GitHub Actions are a response to the book and the author's research or if it existed before the book.

Another solution might be a good README page with well defined details on how to contribute.

@dominicduffin1 response with a reference to https://opensauced.pizza, is interesting. It does advertise on the homepage that it's the place to start your open source journey. The non-coding tasks are for newbies and so I think you are right. OpenSauce is providing a service to the open source community

[dominicduffin1]

I'd like to push back a little on @LaurenC2022's point that non-coding tasks are for newbies, with the caveat that non-coding tasks do offer good opportunities for people who are new to coding and don't yet feel confident about making code contributions, especially if they can draw on previous non-coding experience.

I think open source communities can benefit strongly from experienced non-coding contributors who contribute to all the other things that go into making good software other than writing code, from project management to design to providing support to users and contributors. Many of these contributors won't be newbies, they are just people who don't need code to do what they do, though some of them may also be coders.

[dominicduffin1]

The author says that "[the GitHub generation of oss developers] prioritize convenience over freedom (unlike free software advocates) or openness (unlike early open source advocates)" (30). What do you think about this according to your personal experience with OSS and your observations of OSS?

I do think this is a general phenomenon today, that as highly convenient models of platform technology have developed and become mainstream, convenience has become a high priority for a lot of people. I think a ripe challenge for some talented UX designers is to figure out how to meld convenience with values-related stuff like not being tied to one platform. I'd like to see more focus on interoperability and tools that manage the complexity of freedom in an intuitive way.

[CuriousCurmudgeon]

Starting to catch up on the book this week. Here are jumbled thoughts from my notes.

The author mentions Karl Fogel's Producing Open Source Software (https://producingoss.com/), which I read a long time ago. I see there is a second edition now too. I'm interested to see how perspectives have changed over the years. Hopefully I'm not misremembering, but the distinction between open source and free software was very prevalent back then. It was yet another tech holy war. It's a bit weird for me to not see that distinction today. I had never considered that GitHub's social model had pushed everybody towards MIT-style licenses.

I am skeptical about the idea that the absolute number of contributors being smaller on most projects today than before. I'm not sure if that was actually the author's position, but they weren't very explicit about it. The author presented zero evidence in the intro and first chapter that the number of contributors to important projects used to be higher. Given the explosion in usage though, it's undeniable that the ratio of contributors to users is way more unbalanced than it used to be though.

I had never considered the aspects of influencer culture with large open source projects, but it makes sense. There is certainly a strain of project maintainer that is very open. There are devs I've never met that I feel like I know. I hadn't made the jump to considering that a para-social relationship though, which it absolutely is.

I was happy to see the author bring up platforms vs. aggregators. I'm a big fan of Ben Thompson's aggregation theory. My mind was already going there when the author brought it up themselves. GitHub and package managers have reduced the amount of friction around pulling in 3rd party dependencies that it's hard to remember just how painful it used to be. And the abundance of packages also gives me a certain level of analysis paralysis. I'll see something and think that I could contribute to it, only to very quickly learn about some other package in the ecosystem that also interests me. The overwhelming abundance makes it easier to default to doing nothing. To not making a choice at all.

This contributes to drive-by contributors too. I very occasionally fix bugs in projects, but never stick around.

[BekahHW]

Week 2: The Structure of an Open Source Project

1. What were your key takeaways or ideas that interested or surprised you the most in this chapter?

2. How does trust play a role in open source? How does this differ for maintainers and contributors?

3. What did you think about the different stages of an OSS project (53-55): creation, evangelism, growth? Which stage do you think is the most challenging and why? How can challenges in the later stages be addressed in the earlier stages?

4. The author gives 4 production models (59-67): federations, clubs, stadiums, toys. How do you think someone should decide which theirs falls into? What do you think about hybrid models? What are the major considerations to utilizing each model? Where do you think communities like VC and FCC fall into this?

[dominicduffin1]

Where do you think communities like VC and FCC fall into this?

I'd put VC into the Club category. A fairly high percentage of community members are committed contributors who hang around for the long term, and I feel hopeful that if times got tough on one platform, the community might move but it wouldn't fall apart. Of course, partly how VC remained a club was through becoming conscious about how to manage membership growth when it became clear it could become more like a federation, without the resources required to manage a community on that scale.

What did you think about the different stages of an OSS project (53-55): creation, evangelism, growth? Which stage do you think is the most challenging and why?

I think growth is definitely the most challenging stage in OSS, unless you are a corporate-backed project. In the earlier stages, the stuff that doesn't scale well, such as user support, and the stuff that requires money as it scales, such as computing resources, are at a manageable level. Code, by contrast, scales well. Since code scales better than the other things, it is inevitable that non-code activities will take up an ever-greater share of resources as a project grows. The book also points out that the code is the easiest part to find contributors for a lot of the time, which only increases the challenges of growth.

How can challenges in the later stages be addressed in the earlier stages?

I think that making a conscious effort to encourage participation in the non-code aspects of a project early on before the project management becomes so challenging would be important here. Also, developing good documentation from the get-go, even if at first you're the only one reading it.

[CuriousCurmudgeon]

What were your key takeaways or ideas that interested or surprised you the most in this chapter?

I liked the comparison between open source and companies. I've worked at a lot of companies. There are certainly similarities that make it easier to show up at a new company, but that has limits. I hadn't considered the same to be true for open source projects. I know the broad strokes to look for when looking to contribute to an open source project, but the details can differ wildly.

I also appreciated getting terminology for different open source project structures and quickly realized that I'm really drawn to clubs. I've worked as part of both massive, federation style ecosystems and in smaller clubs. I much prefer the clubs. I feel like I can actually reach out to an important member in the community and have a connection. That isn't possible in both federations and stadiums.

What did you think about the different stages of an OSS project (53-55): creation, evangelism, growth? Which stage do you think is the most challenging and why? How can challenges in the later stages be addressed in the earlier stages?

I liked the differentiation between maintainer views of growth. Some maintainers want their projects to be enormous. Others pull back in on themselves and focus on their priorities. Growth isn't the end all, be all for them. They want to run a project under their terms, not expand governance by bringing in other maintainers.

[BekahHW]

Week 3: Roles, Incentives, and Relationships

1. What were your key takeaways or interesting things you learned this chapter?

2. The chapter talks a lot about the hidden costs of OSS: burnout, emotional labor, overwhelm, etc. What are some different approaches to dealing with these costs? How can communities help to reduce these hidden costs?

3. Motivation is necessary for maintainers and contributors. What are the different forms of motivation and how can maintainers, contributors, and users support each other to stay motivated? Sometimes people hang on after the motivation is gone. What should happen at this point?

4. The author differentiates between code/active/casual contributors, members, active/regular users, and maintainers. How does identity play a role in the success, health, or growth of the project?

5. It's hard to find a standard way to judge the health of an open source project. How should maintainers approach evaluating their projects and setting those standards? How should contributors approach evaluating a project to determine if it's healthy and/or worth contributing to?

[dominicduffin1]

What were your key takeaways or interesting things you learned this chapter?

• It talks about the history of internet communities in terms of the "villages" that were later connected by the "highways" that are big public social platforms such as Facebook and GitHub and the homogenizing effect of these highways. An interesting question that occurred to me was that there seems to be a slow drift away from the large "highways" in general online communities with more people saying they rarely look at public social media anymore, but remaining engaged with more private communities. I wonder whether over time internet communities will revert back toward the "villages" with much less traffic on the "highways" and whether that trend will also spread to open source?

• There is ample mention of intrinsic motivation to participate in open source but it doesn't really mention the intrinsic motivation that is most important to me: a motivation derived from one's belief systems, in my case that the internet should continue to be a place where, unlike most of history in many parts of the world, people are free to publish and innovate without the approval of a centralized authority. In my view, open source software is an integral part of that vision of the internet, because we can only safeguard digital freedoms if individuals can exercise freedom at the level of the code itself. I do, of course, enjoy writing code, and I also have extrinsic motivations, but my intrinsic motivation to contribute comes instead from a belief in the open source model.

[CuriousCurmudgeon]

What were your key takeaways or interesting things you learned this chapter?

I was happy to add the term commons-based peer production to my vocabulary. I found it very similar to the ideas that Jessica Kerr explores in this talk https://www.youtube.com/watch?v=nVRUv30coyA. I haven't watched it in a long time, but she uses the Florentine Camerata as a jumping off point for how creativity works in teams.

I also liked the framing of the platform itself as the community instead of individual projects. This works best for the massive number of solo projects on GitHub. The collection of projects themselves form the community instead of each individual one being a separate community.

This book is really clarifying my thoughts around why I'm attracted more to some communities and ecosystems than others. The through line seems to be smaller groups where my contributions can be seen. I feel less motivated and invested in large groups. I've never made a strong connection with anybody in a large group setting. The idea of making friends on a broadcast style social media platform feels completely alien to me.

This applies both socially and professionally. I'm much more comfortable exploring the smaller ecosystem of Elixir than I ever was in .NET. The community isn't so massive that I feel like everything has been said and done. I feel like I can pick up some small project and my contribution will be meaningful.

Rough consensus is achieved when all issues are addressed, but not necessarily accommodated.

This quote from the IETF about consensus-seeking really resonated with me in the context of VC as well. In any large group, there are going to be opposing views. Not everybody can have their needs accommodated, but they can be heard.

[LaurenC2022]

How do you mean?

The author talked about the complexity of a healthy open source community, which included developer and non developer contributors.

If you mean, it's almost not worth contributing to OSS, because contributors have to understand the social norms of an online community build around a project, that I can understand.

[LaurenC2022]

5. It's hard to find a standard way to judge the health of an open source project. How should maintainers approach evaluating their projects and setting those standards? How should contributors approach evaluating a project to determine if it's healthy and/or worth contributing to?

Nadia Eghbal, the author, said the number of maintainers could be an indication of the health of a project. A small number of maintainers would lead to over worked people. Too many contributors could mean the community has a high turnover rate.

In the case of a non authoritarian maintainers, a code of conduct can insure health in a project.

Eghbal had to rely on non technical information about what healthy commons-based peer production looks like. She took information about general healthy ecosystems seen outside of the software context and applied them to the online community. Eghbal said the About section on GitHub is a good place to look for health indicators. She also said places outside of GitHub, like video tutorials, and fund raising contribute to the over all health of a project. I don't believe there is a chart for rating the over all health of a project, though someone might be able to make a chart given the collection of knowledge Eghbal impart on her readers.

I enjoyed the thought provoking ideas brought up by Eghbal, and look forward to seeing the repercussions of her impact by way of new metrics for measuring online communities' health and potential.

[LaurenC2022]

1. What were your key takeaways or interesting things you learned this chapter?

I don't remember if it was from this book or a podcast from this week, but I remembered this week I heard that if you make a project/ design files open source then developers of a company are more likely to adopt it. This is really interesting to me from a management standpoint and something to look into if/when managing a team

[BekahHW]

Week 4: The Work Required By Software

1. What were your key takeaways or interesting things you learned in this chapter?
2. This chapter talked a lot about static v. active state. How does that contribute to the "hidden costs"?
3. With marginal costs, the author includes physical infrastructure, user support, and community moderation. What are some of the biggest problems with each of these? What are some potential solutions?
4. Temporal costs include Technical debt, dependency management, and adapting to user needs. Which one most interested you and why? Any surprises here?
5. Substitutability and reputation kind of go hand-in-hand. Do you think these factors in the success of a project lead to burnout, mission-drift, or other problems we've talked about so far? How do you think they impact the longevity of the project?

[dominicduffin1]

What were your key takeaways or interesting things you learned in this chapter?

I think the top two takeaways are the observation that software never dies, but rather may decline in use like the exponential decay of radiation, never completely disappearing; and that software is inherently fragile, with such a web of interdependency that is only likely to grow.

This chapter talked a lot about static v. active state. How does that contribute to the "hidden costs"?

I think hidden costs relate to the fact that software that is in use is not really just static lines of code on a virtual page, it is reliant on a social, physical and software infrastructure around it, and that infrastructure imposes costs that are largely unrelated to the basic act of copying software.

With marginal costs, the author includes physical infrastructure, user support, and community moderation. What are some of the biggest problems with each of these? What are some potential solutions?

I think the biggest problem is that our model of what open source projects need is largely based around the code. The issues around the marginal costs of software include a significant amount of valuable work that doesn't involve the actual writing of code, and I don't think open source has developed the social and institutional capital to value that non-code work like it has the code work. I think we need tools and metrics to value and grow the reputation of people who do that work.

[CuriousCurmudgeon]

What were your key takeaways or interesting things you learned in this chapter?

I've always found "free as in beer" to be a very awkward phrase, but I immediately took to "free as in puppy" from Jacob Thornton, the co-creator of Bootstrap. Creating a popular open source projects starts off new and exciting, but the reality of maintenance hits at some point. The project doesn't just go away because you don't enjoy it as much anymore. It's those realities that make forking an open source project so undesirable.

The phrase even works with reputation. Your friends are often excited to see the puppy at first. It's exciting. But then it becomes normalized and the reputation bump goes away.

This is a tangent, but I'm also annoyed by the author's continuing usage of the air as a non-rivalrous, non-excludable good. Climate change has shown us that even what is thought of as the quintessential example of this type of good has its limits. There is a scale where it stops being non-rivalrous, non-excludable.

[BekahHW]

Week 5 Managing the Costs of Production (first half to 181)

1. What were your key takeaways or interesting things you learned in this chapter?
2. The Christmas lights analogy does a good job of demonstrating the problem of consumption v. production. What are some other analogies we could use to demonstrate this problem? How can maintainers share this information with contributors in a meaningful way?
3. What do you think about the idea of public v. participatory (161)? Would limiting contributors' abilities decrease the problems with dividing maintainer attention?
4. Why do you think some contributors feel entitled to maintainers time, energy, and product roadmap?
5. In the "Managing Producer Attention" section, the author gives ways to manage attention: "Reduce up-front costs, make themselves less available, distribute costs to users, increase total attention available." What do you think about these? Would you say any is better than other? Worse?

[LaurenC2022]

1. Another analogy could be visiting a friend for dinner. It's impolite to make negative remarks on their home or food, and in the same way contributors should be polite when forking and changing some else's work or making requests for new features.

My thoughts on the chapter: I felt the Christmas analogy was excellent for making her point, but conflicted with an analogy used later in the chapter. I feel the book would have better flow and connection if the analogies were tied in a bit better. The book is excellent work and the conclusion did great in tying the book together.

4. I think some contributors could lack understanding and maybe don't know their actions and interpreted as entitlement to maintainers' time, energy, and product roadmap.

5. I think making themselves less available is a polite way of setting boundaries.

Distributing costs to users is an interesting option. The project doesn't need to be for profit, it could just break even and pay the developers/ support team all the money earned. It was said in the book that some people believe distributing the cost to the user can takes away from the spirit of open source, but people have to eat. I think the reality that people need to be compensated to survive is not directly talked about in the book, but is a theme.

[CuriousCurmudgeon]

What were your key takeaways or interesting things you learned in this chapter?

I had never heard of a "time delay" license like the one used by Onivim 2. Looks like they gave up on that model though and relicensed to MIT in Sept. 2021.

Recently, Terraform changed their licensing going forward. In response the community is forking the project with OpenTF. This feels like a good example of a company thinking they have an inelastic good, where few substitutes exist. They underestimated just how many companies rely on Terraform and that might be willing to spend developer resources on it themselves to maintain control.

My spicy take is that I think Hacktoberfest is an overall net negative on the open source community. It increases the maintenance burden on project maintainers by attracting a lot of low value contributions from people who have no intention of ever contributing again. And it compresses it all into one month as people chase trinkets. It feels like a really bad use of gamification.

What do you think about the idea of public v. participatory (161)? Would limiting contributors' abilities decrease the problems with dividing maintainer attention?

I like the distinction. "Public" fits the original ethos of open source software more than "participatory". Participatory is a side effect of the rise of GitHub. Prior to GitHub, there was a lot more friction involved to participate in a project, but the code was still public. GitHub create the illusion that users of a project are also members of the community, but being part of the community requires more effort than that.

I liked the one-way mirror description too. Unfortunately, GitHub doesn't support this model. Maintainers need to turn off features like issues in GitHub and move discussion to a different platform where they can lock down participation. Yes, you can read the discussion, but you can't participate without demonstrating in some way that you are part of the community.

I was really intrigued the by idea of charging money to open a PR or open an issue. I don't know if it's a good idea, but if your goal is to limit low effort contributions and questions, it's worth exploring. It reminded me of a job I used to have where the customer was allowed to escalate issues. Unfortunately, there wasn't any friction in the escalation process, so they just escalated everything. If you want to limit some mode of interaction, like opening issues, then you have to reintroduce friction into the process in some way.

[dominicduffin1]

The Christmas lights analogy does a good job of demonstrating the problem of consumption v. production. What are some other analogies we could use to demonstrate this problem?

I think the Christmas lights analogy goes part of the way and is a good illustration of the attention and motivation problem. I'm struggling to think of a good analogy for open source because I can't think of anything in the physical world that is produced as a result of intrinsic motivation but interacts with the rest of the world in the way software does. Imagine a Christmas lights infrastructure where your lights depended on the work of twenty neighbors to function, and many of them also depended on yours, where parts had to be replaced to work with regular changes in the street plan or the whole thing would break, and if it did it was going to take out all your appliances as well. You'd probably feel entitled to knock on that door sometimes. But somehow, despite all that, people still felt intrinsically motivated to produce.

What do you think about the idea of public v. participatory (161)?

I think it could definitely make sense for many projects to be public rather than participatory for some things. Unless you are an active contributor who can therefore be initiated into the inner circle, you should probably be restricted to simply viewing decision-making processes. There could be different grades of exclusion; some projects could say the general public has a right to participate in the roadmap but not in how it is implemented, while others could restrict the roadmap and the implementation to just the inner circle, depending on how much attention they have to distribute.

What were your key takeaways

Another important issue for open source nowadays that is touched on at the beginning is the fact that open source is transnational, and we don't really know which governments have jurisdiction over open source code. I think governments are going to increasingly try to exert global jurisdiction over parts of open source they care about (but without necessarily providing any support for maintainers). This is something we in open source are going to increasingly have to grapple with. For those of us in democratic countries, this is also something to think about when engaging in political processes: to support politicians and policies that will help to maintain Ostrom's independent commons, and oppose those which seek to interfere in it.

[BekahHW]

Week 5 Managing the Costs of Production (second half post 181)

• What were your key takeaways or interesting things you learned in this chapter?
• Getting paid is complicated. What are your thoughts on funding individuals v. projects?
• what are your thoughts on individuals supporting open source monetarily v. companies supporting oss?
• are there ways mentioned in the chapter to fund oss that you think might work better?
• how can be provide better recognition for maintainers and contributors?

[CuriousCurmudgeon]

Getting paid is complicated. What are your thoughts on funding individuals v. projects?

As usual, the answer is "it depends" and the thing it depends on the most is the size and number of projects. For larger projects, I feel more comfortable funding the project itself instead on an individual. For example, I would feel very strange giving funding directly to Evan You for Vue instead of a project. It feels too large to be giving funding directly to an individual.

On the other hand, JS is full of maintainers with many projects. In that case, funding any individual project makes little sense in comparison to funding the individual directly. It also feels like a difficult boundary to cross. If a project starts with individual funding, how do they handle the transfer of funding to an organization for the project itself?

What are your thoughts on individuals supporting open source monetarily v. companies supporting oss?

As a maintainer, I would prefer to have my project funded through small, individual donations. It leaves the project less beholden to the requests of any single supporter. Large corporate supporters are probably more likely to have expectations about what they'll get for their money. They may want input on the project roadmap and features.

[dominicduffin1]

Getting paid is complicated. What are your thoughts on funding individuals v. projects?
What are your thoughts on individuals supporting open source monetarily v. companies supporting oss?

I think there is room for all these things.

For companies to support open source it's important to remember that companies need to know what they are getting if they pay that they will not get if they simply use the project without paying. There needs to be a tangible benefit to the company of paying out the money (which can include reputational / marketing benefits). For individuals supporting open source tangible benefits could still be important but there is also likely to be a lot more funding for social or intrinsic motivations. There is also a possibility of both companies and individuals paying for the less tangible benefits of long-term involvement in, and recognition of, a community. Another in-between category would be companies offering to fund sponsorships as a perk of employment.

With obviously some exceptions, I'd expect companies to lean more towards funding projects while individuals would be more likely to support either or both. Supporting an individual is probably more compatible with social or intrinsic motivations while supporting a project could offer tangible benefits and/or be compatible with intrinsic motivations.

What were your key takeaways or interesting things you learned in this chapter?

Something I disliked was the authors attempt to compare open source to academia. Open source is a distinct field that is separate from academia with its own culture and conventions, and we want to keep it that way. Which is not to say that academics and academic institutions can't contribute to open source, so long as they don't try to pull open source into the academic bureaucracies, hierarchies and culture.

[BekahHW]

Conclusion

• How did you feel after finishing? Are you optimistic, unsure, still pondering?
• what models of payment do you think work best?
• what contributor management do you think is most effective?
• How do you think oss will evolve from here?
• what was your biggest takeaway from the book?

[CuriousCurmudgeon]

How did you feel after finishing? Are you optimistic, unsure, still pondering?

Before reading this book, I hadn't considered just how important parasocial relationships are in the ecosystem. It makes sense though. Open source maintainers are often interacting with their users through the same social channels that other parasocial relationships develop on. It was just an unexpected (but obvious in hindsight) connection.

What models of payment do you think work best?

I think the gold standard remains being hired to work on an open source project. You could be a prestige higher by a company. Your project could be integral to their future. I haven't seen much evidence that other funding models can provide a reasonable level of security. If you want to work on open source full time independently, you need to be comfortable taking a large pay cut compare to what you could get in a traditional corporate gig.

Ultimately, I think the best payment model is highly dependent on the project, the personality of the maintainer, and the ecosystem it is targeting. There is not one size fits all model to be found.

What was your biggest takeaway from the book?

I was surprised by just how much the conversation has changed over the past 20 years. What percentage of open source contributors even think about licensing now? That's a wildly different world than the one that existed when I read Producing Open Source Software 15 years ago. I was blind to the influence of social media culture on the wider ecosystem. Given the (previous?) importance of Twitter, that's a big miss on my part.

Beyond that, there was a quote in the last chapter that says "Public" does not imply "participatory". I think that's an important takeaway for all participants in the open source ecosystem. As a maintainer, I'm allowed to just put my code out there and not accept contributions. As a user, I'm not entitled to a maintainer's time. Unfortunately, GitHub makes this difficult. You can turn off some features, but you can't turn off PRs.