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.
