A Third Way For Open-Source Maintenance

Contribution

Nate Berkopec

A Third Way For Open-Source Maintenance

by Nate Berkopec

In this video titled 'A Third Way For Open-Source Maintenance,' Nate Berkopec discusses a sustainable model for maintaining open-source projects, particularly drawing upon his experiences with the Puma project. He presents a viewpoint that bridges the existing extremes of maintaining open-source: the notion that 'everyone deserves to be paid' versus the idea that maintainers are 'on their own.'

Key points of the talk include:

- The Current Model: Berkopec expresses concern that current open-source collaboration models, largely shaped by GitHub, limit maintainer labor and create anxiety in the community. He argues that maintainers should not be viewed merely as resources but rather as facilitators for a wider pool of contributors.

- Maintainer Responsibilities: He emphasizes the need for maintainers to focus on encouraging contributions instead of feeling overwhelmed by user demands. He suggests that users often take from maintainers without contributing back, leading to an expectation imbalance.

- Shifts in Contribution Dynamics: Berkopec presents his change in practice since taking over Puma maintenance, leading to a healthier contribution model, where maintainers can view the issues list not as obligations but as opportunities for potential contributors.

- Recruitment and Delegation: He advocates for splitting maintainership tasks to include documentation, issue management, and new contributor onboarding, to enhance project sustainability.

- Protecting Maintainer Attention: Berkopec stresses the importance of maintaining a positive environment for contributors and the need for aggressive moderation of negative behavior that deters participation.

- Challenging the Maintainer Monopoly: He calls for a reevaluation of how projects are owned and maintained, suggesting the need for a system that allows community governance and shared responsibility rather than a sole maintainer monopoly.

In conclusion, Berkopec encourages maintainers to lead their projects as community leaders, enabling them to recruit and inspire new contributors while managing their responsibilities. This new framework fosters an open-source environment that thrives on collaboration and shared contributions, addressing the sustainability concerns faced by many maintainers today.

00:00:05.359 Hi, my name is Nate Berkopec, and I'm here to talk about what I call a 'third way' for open source. This concept lies somewhere between the extremes of the belief that all maintainers deserve to be paid a lot of money, and the idea that maintainers are on their own.

00:00:11.099 I'm discussing this today based on my experiences as the maintainer of a very popular open source project called Puma. You may also know me from my work with The Speed Shop, which is my performance consultancy for Rails applications. At my consultancy, I've written a couple of books about Ruby on Rails application performance, but this talk today will mostly focus on my open source work, which I do as part of my time at The Speed Shop.

00:00:28.140 I spend about 15 minutes per day organizing and maintaining Puma. I do this every single workday. It's been a consistent part of my practice, and I want to share some of what I’ve learned through this experience. I wrote this talk as a response to the anxiety I've observed in the community surrounding open source projects. There’s a prevalent notion that open source is like a massive Jenga tower, where maintainers are overworked and underpaid, and eventually, everything will come crashing down.

00:00:53.100 However, I haven't felt this way with Puma. I think I've found a way that works, and I want to share it. So, why am I the maintainer of Puma? I remember attending a RubyConf where Evan Phoenix approached me in a hallway and asked if I wanted to maintain Puma alongside Richard Schmiemann from Heroku. Evan had started Puma around five or six years prior to our takeover in 2016. It has been a great experience, and I've learned a lot.

00:01:17.100 When Richard and I took over maintenance in 2016, there was a burst of activity, but contributions tapered off to low levels around late 2018. However, in 2019, I began trying a different approach, which is what I refer to as the 'third way' that I want to talk about today. Since then, contributions to Puma have been robust and healthy. Interestingly, this growth isn't because of me but from a small handful of other contributors whom I've encouraged and supported.

00:01:41.880 We've completed numerous releases during this time, totaling hundreds of millions of downloads. That rate of downloads is now increasing exponentially, especially since we became the default server for Rails. Consequently, I've found that we've risen to the challenges of managing this project effectively.

00:02:06.360 My basic thesis here today is that the current open source collaboration model is simply a byproduct of GitHub and its user interface, which artificially constrains the supply of maintainer labor. I want to discuss some strategies to subvert this model and explore creative ways we can operate outside the rigid framework of GitHub. For example, what if we reimagined how open source collaboration worked?

00:02:30.720 Nadia Iqbal's book, 'Working in Public', is essential reading for anyone considering this problem. She outlines the idea that there are two markets for open source software: one for the actual bits and bytes of the software, which is a non-rivalrous good, and another for maintainer attention, which is a rivalrous good. If one person downloads Puma, it doesn't prevent another from doing so; however, there’s only a limited supply of maintainer attention.

00:02:55.080 This leads me to a classic economics framework of supply and demand, where the supply curve represents maintainer attention. As the volume of user requests increases, the volume and importance of issues can surge. However, this representation can be misleading; it suggests that as user demand grows, maintainer attention gets greater. In reality, maintainers' time is often inelastic. Regardless of a project's popularity or the number of issues opened, the actual hours I dedicate to the project remain static.

00:03:36.479 It's important to note that my discussion of maintainer attention specifically excludes services we might consider open-source software, like rubygems.org. These types of services run on hardware and create a different dynamic; for instance, if an increasing number of users download more from rubygems.org, it indeed generates additional maintainer work, which contrasts with the nature of using libraries and packages.

00:04:06.600 Additionally, I’m not focusing on issues of equity or fairness in this talk. Some argue that companies exploit open source software for profit while maintainers do not receive sufficient compensation. While I acknowledge that concern, my primary focus is on how user demands on maintainer attention increase as software gains popularity, leading to a backlog of issues that the maintainer struggles to manage.

00:04:56.880 Consider this: as usage grows, the demands on maintainer attention become more pronounced. It might seem obvious, but it raises questions. Why is it that as more people download a package, maintainers face additional time demands? What do maintainers owe users? This notion is worth exploring because it often gets exaggerated in favor of users.

00:05:34.740 For instance, last week, there was an incident with the Mind Magic repository where everyone’s builds broke. A maintainer of a small dependency received a legal request concerning a copyright violation. This situation forced the maintainer to yank all versions associated with the violation and release a new version. Imagine being that maintainer, faced with this complex legal decision without support.

00:06:23.220 In that moment, what do you owe the users? Should you risk potential legal repercussions for users over issues that might not be their fault? The prevailing expectation is that maintainers should be heroes for their users, which adds to the pressure that maintainers face. It seems the community often expects them to go above and beyond for the sake of users, but fundamentally, this mentality is problematic.

00:06:56.340 Typically, we think about requests such as 'please implement this feature' or 'please fix my bug', but the reality is that users often take and rarely contribute back to the project. More usage doesn't necessarily enhance the project itself, as most maintainers will tell you. It's essential to reset our expectations about what maintainers owe users. As Rich Hickey, the creator of Clojure, emphasized in his essay 'Open Source is Not About You', if your expectations aren't being met, they are your own responsibility.

00:07:52.320 If you want something, make it happen yourself. If you're a user of open source software and you're not a maintainer, this is crucial advice to temper your expectations for maintainers. Personally, I view our issue list on Puma as a resource for future contributors, a repository of information rather than a to-do list to be completed.

00:08:39.780 If I feel inclined to contribute to Puma, I refer to those issues for inspiration. My interactions with users largely consist of labeling issues or helping them clarify their bug reports for reproducibility. If a feature request comes in, I label it and move on, leaving it up to others to take on implementation. This illustrates a valuable mindset: the maintainership role should not solely rest on one person's shoulders.

00:09:34.320 It's vital for us to encourage more extensive engagement with potential contributors. Establishing clear codes of conduct can also assist in managing expectations from users while protecting contributors. Nothing demoralizes volunteers more than feeling entitled users making unreasonable demands. By protecting contributors from these entitled attitudes, we can create a much healthier project environment.

00:10:10.440 On the supply and demand side, it’s critical to recognize that only one side is inherently valuable—maintainer attention. Unfortunately, our current systems don't prioritize this attention effectively. The push for monetary compensation for maintainers has been a significant conversation, with initiatives like Open Collective attempting to create sustainable models.

00:10:45.300 However, the challenge lies in the disparity between the financial rewards for software engineers, which often eclipses any remuneration from open source projects. For instance, even significant donations from users may pale compared to a maintainer's full-time salary from their day job. This reality makes it difficult for maintainers to justify allocating more time to their projects, regardless of how much funding they receive. This leads to doubts amongst new contributors about their own value, thinking that because someone is paid, they might not need their assistance.

00:11:51.300 Solutions need to recognize the wealth of free labor available online in the open source community. We should structure projects to be as contributor-friendly as possible. My favorite example of collaborative potential was the 2008 Merb to Rails merger, which significantly enhanced Rails's modular features and overall experience without attaching any financial reward to it.

00:12:33.120 Maintainership involves more than just writing code. It encompasses documentation, issue triage, code review, version control, and project vision. Only three of these tasks require extensive control rights on GitHub. The majority of these other responsibilities are open to contributions from anyone willing to participate.

00:13:01.920 The first solution I propose is to redefine how we perceive the maintainer's role. We must break down the responsibilities of maintainership and allow others to contribute in valuable but non-code areas. Many projects already embrace this division of labor, forming dedicated issue triage and documentation teams along with release managers.

00:13:51.960 The second solution is recognizing that the most valuable work a maintainer can do is to recruit future maintainers. The '10x coder' concept can be literally applied here; as a maintainer, if I can recruit nine more contributors, I effectively multiply my input into the project. Besides, one practical way to achieve this objective is by ensuring the project is accessible to newcomers. This includes maintaining an effective test suite, clear coding practices, and guides for new contributors.

00:14:28.680 For instance, I’m open to newcomers who want to book a meeting to resolve issues, and I encourage current contributors to offer their assistance. By cultivating new maintainers, we enhance our community's capacity substantially. This also leads to a healthier environment for all contributors, as new maintainers lead to an increase in project activity without overburdening the existing maintainers.

00:15:14.520 Moreover, we need to provide recognition for contributors. At Puma, we reward contributors not just through commitment to code, but by granting them informal titles, like 'Techno King', based on their participation level. This creates camaraderie and offers contributors something fun to strive for.

00:15:58.440 Another way we foster community spirit is through a tradition of naming releases after contributors. This practice honors those who have significantly contributed to a release and recognizes their work publicly in project logs, further engaging the community.

00:16:43.080 To protect maintainer attention, we must be proactive in moderating negative interactions within our project spaces. Open source maintainers often deal with challenging personalities. Therefore, we should establish an environment where positive contributions are prioritized and negativity is mitigated.

00:17:29.100 We should aim to disrupt the maintainer monopoly that exists within the GitHub ecosystem where only the designated maintainer has commit access to the main branch. Forking projects can often become much more complicated than necessary; it should be simpler for the community to assume maintenance or create forks without facing significant barriers.

00:18:16.140 By reflecting on models like Wikipedia, which operates on a consensus-based editing process, we can discover promising frameworks for structuring open source projects. No single individual should possess ownership over a project, especially in a community-driven context, as it does not align with the open source ethos.

00:19:06.960 Users and contributors care about well-maintained projects more than who originally created them. We should strive for greater clarity in ownership to address this effectively and perhaps consider implementing measures to acknowledge community contributions fairly.

00:19:44.520 To summarize my suggestions, the first is to parcel out work and encourage contributions in non-code-related areas, such as documentation and issue management. The second is to actively recruit and select new maintainers to build a more resilient project. Lastly, aggressively protect maintainer attention while promoting positive community engagement.

00:20:26.040 I urge you to be community leaders who invite participation without being bogged down by the expectations of user demands. Remember, your role as a maintainer often means also being a facilitator within the community.

00:21:08.880 Let us appreciate the opportunities available within the open source ecosystem and recognize the immense free labor that our community offers. By designing more contributor-friendly projects and fostering active engagement, we can circumvent many issues that plague maintainership today.

00:21:55.920 Thank you for listening to my talk. If you have any questions, feel free to reach out to me on Twitter as Nate Berkopec. I look forward to seeing you around!

RailsConf 2021