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!