The Feedback Loop: Growing healthy open source projects

Sustainability

Yehuda Katz

#developer-experience

The Feedback Loop: Growing healthy open source projects

by Yehuda Katz and Dave Herman

The video titled 'The Feedback Loop: Growing healthy open source projects' features speakers Yehuda Katz and Dave Herman and was presented at the Keep Ruby Weird 2017 event. The primary focus is on the complexities and dynamics of open source projects, aiming to bridge the gap between initial expectations of open source collaboration and the often conflicting realities faced by maintainers and the community.

Key Points Discussed:

Conclusions:
The talk emphasizes the significance of open communication and flexible governance within open source projects. Key takeaways include:

Bridging the gap between maintainers and users requires empathy and constructive dialogue.
Viewing new contributors as vital community members can alleviate burdens on maintainers.
A collaborative governance approach fosters a healthier environment and engagement.
Companies should facilitate their engineers' participation in open source to enhance community relationships.

Overall, the video advocates for nurturing a vibrant open-source ecosystem through constructive collaboration and shared governance principles.

00:00:11.030 So, I haven't spoken in like a year since I became a dad. I also became a dad more like five years ago, but I haven't spoken very much since then either.

00:00:23.430 We want to talk about open source today. Sometimes when people get started with open source, they think, 'Oh, this is fun! I'm going to do some cool tech, and maybe some people will come by, and we'll have a good time and collaborate. It'll be great! Fun times will be had by all.' Lia Silver calls this the 'open source pixie dust theory'. The problem is that the reality, the lived experience, sometimes comes away a little less ideal than the theory. That's what we're here to talk about today.

00:01:02.550 There is often a conflict between what people expect the world to look like and what it actually looks like in practice. Today, we want to unpack this a little. When we talk about the feedback loop in this talk, we are saying that in the real world, communities and projects evolve. They grow into things that are different from where they were when they started.

00:01:27.930 As they evolve, there are tensions between the people who started out— the first users and use cases that something was designed for— and the newer users and use cases. When you experience a tension, it's very tempting to say, 'We're just going to pick a winner; the first users win, and this use case is out of scope.' Sometimes that's a good idea, but mostly, what you should try to do is find a way to synthesize the conflicting use cases into one solution. That's how we grow as individuals and communities; it's true for open source as well.

00:02:23.240 Actually, the story of how Dave and I met has some conflict in it. This is a picture of the physical room where we met for the first time, called the Grove in San Francisco. I went over to the Grove to meet Dave, and I was met by this ivory tower academic who worked on TC39. I was involved in TC39, and I was working on the module system for ECMAScript. I had these goals of getting a static module system into a dynamic language, and I knew it was going to be controversial.

00:03:02.360 I didn't know Yehuda too personally, but I had this image of him as a kind of scary dynamic language person, you know, like Ruby; I heard it's kind of weird, and he's sort of an agitator. He's known for mixing things up on the Internet. So, we both went into this with some reservations about whether we could collaborate on our respective perspectives. However, the conflict between our two perspectives turned out to be reconciled and led to a long-standing collaboration and friendship that continues today.

00:03:39.230 In the rest of this talk, we're going to discuss common tensions in the open source world that people grapple with and some tools we personally have used to help resolve those tensions. Often, when you encounter a conflict for the first time, people say, 'Don't spend too much time thinking about that conflict or resolving the tension; they're just irreconcilable.' They imply there are two sides, and one side has to win, and the other has to lose. This perspective is generally unproductive.

00:04:00.560 Many people who have been working on open source for a while find themselves feeling disconnected from their community. Maintainership can often feel separate from the community at large. A common way people experience this tension, particularly from the maintainer's perspective versus the community perspective, is through a sensation known as open source burnout. This topic has been frequently discussed on platforms like Hacker News. Open source burnout often manifests when you deal with users expressing frustration.

00:05:00.240 Just imagine if you worked on Webpack and got a tweet expressing frustration about your project; you probably wouldn’t be very happy. A lot of the advice given to handle these situations is to 'grow a thick skin.' This is terrible advice for two reasons. Firstly, how are you supposed to magically will yourself to feel differently? Secondly, when people say 'grow a thick skin', they often mean to ignore the feelings of those frustrated users.

00:05:25.490 It's essentially a pain avoidance strategy that leads to chronic pain instead of resolving the issue. So, what’s a better way? One of the best people in open source that I know for dealing with frustrated users is Shawn Larkin, who works on Webpack. Many people's first reactions to angry tweets involve feeling under attack, and they go into a defensive mode. Instead, let's look at how a master like Shawn processes these situations when he encounters them.

00:06:25.360 He first feels attacked but then thinks, 'No, it’s not about me.' He realizes the tweet reflects the frustration of a customer experiencing pain and crying out for help. Instead of responding angrily or ignoring/blocking that person, Shawn uses positive, de-escalating language. Many times, angry comments are simply cries for help. When individuals see another human being on the other side, things can improve.

00:07:15.520 This situation isn't uncommon; often, one positive de-escalating tweet can turn the tide completely. You might wonder how Shawn maintains his calm; it’s not that it’s easy, but when you change a tense interaction into a satisfying collaboration, it feels rewarding. Once you realize you can achieve that, dealing with these situations can feel positive. Recently, I experienced a similar situation where someone tweeted feeling abandoned by the Ember core team.

00:08:03.940 They expressed that we only cared about Glimmer and that we no longer cared about them. Their aggressive tweet arose during a separate conversation. In line with Shawn's response, I viewed their anger as a cry for help; they felt helpless and powerless. Instead of becoming defensive, I tried to understand their frustration, and within minutes, they reached out to apologize.

00:08:33.800 I was able to resolve their frustrations quickly, and since then, I've been in contact with them regularly. They even mentioned that talking with me rekindled their interest in Ember, which is a sentiment I've seen multiple times over the years. Transforming disgruntled users into fans is an amazing feeling, and it has become a highlight of my weeks.

00:09:10.620 While dealing with frustrated users is part of burnout, another aspect is recognizing the influx of new users and their needs. The sense of 'open source guilt' can emerge as maintainers feel overwhelmed by the increasing number of demands on their time and attention, making the process no longer enjoyable.

00:09:49.920 Michael Rogers wrote a compelling blog post called 'Maintainer vs. Community' that touches on this theme. He stated that trying to tackle sustainability from a maintainer-centric view is akin to paddling against the current. We’re witnessing the barriers to adoption and participation fall away, enabling new contributors to get involved, but this requires viewing them as part of the solution rather than the problem.

00:10:30.360 Before unpacking this further, let’s explore some game theory concepts. The first concept is the difference between zero-sum and positive-sum solutions to problems. How many people have heard of this concept? Zero-sum solutions define a conflict where one side wins and the other loses, creating a balance of zero. In contrast, positive-sum outcomes focus on resolving apparent conflicts and finding solutions that satisfy everyone, ensuring everyone gets approximately what they want.

00:11:24.880 The zero-sum approach perpetuates conflicts, particularly around the inflow of new users. Each new user adds work for maintainers, who already have limited time. This creates an ongoing conflict, with attempts to handle the inflow often proving ineffective. Instead, we must find ways to empower users to manage their own input into projects. This recognition turns users from perceived burdens into essential members of the community.

00:12:11.720 For example, users who start by making small contributions often grow into full contributors or maintainers, which alleviates some of the work pressure on maintainers. A prime example of this is Trek Milwaukee, a vocal critic of Ember, who transitioned from being a detractor to a core team member and documentation contributor.

00:12:55.080 The tension between maintainer and community perspectives isn't the only one we experience; another core issue revolves around the relationship between community and companies. I have firsthand experience managing these relationships from my time leading the Mozilla research group, particularly concerning the Rust programming language.

00:13:37.360 Rust began as a company-driven project, despite limited resources. Our core value at Mozilla is to support open source, but we soon faced conflicts between those who worked at Mozilla and those in the broader Rust community. As Rust leadership deliberated about the community's future, we learned how to navigate these relationships.

00:14:21.510 We identified two potential governance models: one OSS or two OSS. The first suggests a unified community where everyone participates on equal footing, while the latter implies tiered divisions based on company affiliation. We found that the two OSS model was less empowering of community collaboration than we had hoped.

00:15:04.090 In the one OSS model, all voices are valued equally, and no institution holds special governance over the community. Leadership comes from diverse companies, actively involving multiple stakeholders in decision-making. We established that decisions should stem from community input rather than company-centric control.

00:15:53.500 For example, individuals with varied company affiliations could be part of the Rust core team, leading towards a decentralized process. Transparency in decision-making enhances trust. While some employees from Mozilla contributed heavily, the governance of Rust evolved to a diverse set of leaders.

00:16:32.170 From a company’s perspective, the idea of relinquishing control to a broader community can feel intimidating. It might spark fears about whether the company would benefit. However, for many types of projects, particularly infrastructure technologies, a thriving external ecosystem is essential for survival.

00:17:14.530 If a single company controls an open-source project, there are often organizational pressures that prioritize short-term solutions over the long-term health of the project or ecosystem. Promoting a diversified community encourages varied input and counters internal biases.

00:18:00.840 Communities should consider the roles of companies and individuals within them. Individual contributors form the backbone of many projects, using their skills to address common issues in their day jobs. Many engineers who use open source in their daily work eventually become contributors, bridging the gap between professional work and community contributions.

00:18:40.210 By allowing engineers to contribute within their work contexts, companies can help individuals elevate their efforts into larger contributions. This supportive approach fosters growth in individual representatives who are also proponents for their company’s commitment to open source.

00:19:23.880 Through these dynamic interactions, companies can build a more robust relationship with open-source communities, empowering their developers to contribute in a structured way. This progression—from casual usage to meaningful contribution—enables larger intentions, opening pathways for companies to engage effectively with open source off their own accord.

00:20:06.080 This is a practical matter, as demonstrated by various contributors who’ve transitioned from minimal engagement to significant commitments in their respective projects. Contributions from individuals at companies are crucial for the vitality of open-source ecosystems, and we should celebrate these breakthroughs that can arise from collaboration.

00:20:44.390 At the same time, it’s essential to acknowledge that not every engagement might elevate to the same level; however, every contribution adds up. Some contributors go from small changes to becoming instrumental forces. The community must celebrate individual achievements that arise from open source, motivating others to join the endeavor.

00:21:28.930 The dialogue around open-source funding has raised valid concerns about how companies interact with open-source projects. While some argue that there is a lack of reciprocity, it’s crucial to view adoption as the springboard for individual contributions. As users engage with a project, it generates pathways for broader company involvement.

00:22:15.640 As we consider ways to bolster sustainability in the open-source space, we shouldn’t overlook pathways allowing individual contributors to enter the fray. Companies that are engaged in open-source projects can help their representatives to forge meaningful community interactions.

00:23:02.420 Furthermore, navigating these partnerships carefully is crucial to prevent cutting off valuable opportunities for engagement and contribution. The path is there; we must ensure it leads towards solidarity rather than division, allowing a unified relationship among all participants.

00:23:41.620 Casting a wide net is vital as we cannot predict who will contribute meaningfully down the road. Many contributors initially join open-source communities by tackling simple tasks, such as fixing typos, before advancing to significant feature implementations.

00:24:20.570 Nurturing a healthy open-source ecosystem involves finding a harmonious balance between coordination and decentralization. It’s important to avoid over-managing, as too much coordination can inhibit progress and participation.

00:25:03.000 Yehuda and I have collaborated on several projects throughout the years, developing an evolving understanding of how open source should work. The one OSS model, emphasizing unified community engagement, represents a successful approach to nurturing a constructive open-source environment.

00:25:48.050 As we share insights through our blog, 'The Feedback Loop', we aim to connect with individuals from various perspectives, sharing our experiences. For those starting in open source, finding a small project to contribute to or creating one of your own can provide invaluable experiences.

00:26:33.880 For existing project maintainers who may be feeling overwhelmed, it’s beneficial to assess how decisions are made and consider modifying processes for broader input. Additionally, if you have resources, encourage your team members to participate in open-source contributions, promoting a culture of support and engagement.

00:27:15.350 Whether you’re a leader in your organization or an engineer, fostering participation creates an empowering environment that enhances relationships within the community. Thank you for your time.

Keep Ruby Weird 2017