🌿The Spore

Brought to you by the team at Organizational Mycology

Attracting and retaining new contributors/maintainers is a perpetual challenge for open source projects. There are, obviously, many reasons for the durability of the challenge: these roles are often unpaid, require a high level of skill and expertise, and run a high risk for burnout. 

The above realities suggest that attracting and retaining key project personnel is largely a problem of immutable qualities of the roles themselves. But one thing we've started to think about is the role of more structural factors in discouraging people from growing into contributor and maintainer positions, one of which revolves around the "bar of quality" that must be met for a successful contribution.

In our discussions and consultations with open source projects, we’ve found that this bar is most often set either too high or too low than what is optimal, thus placing all parties–new contributors, maintainers, and project leadership–in what we are calling “sociotechnical hell.”

*Yes, we are leaving the red squiggly spellcheck line under “sociotechnical” for dramatic effect. It’s a real word, even if the computer disagrees!

As the above image intends to illustrate, problems are equally thorny when the bar is too high or too low. When set too high, contributors feel as if the only way they can usher a contribution across the finish line is to be abnormally persistent, thick-skinned, and socially gifted. That is, contributors must be willing to take initial (often harsh) feedback and work through it to bring the work into alignment with the maintainer’s requests. This scenario puts underrepresented groups at even more of a disadvantage, as subtle or overt acts of racism, misogyny, or other bigotry can play out inside of PR conversations; cultural differences in communication can make conversations difficult to navigate; and the overall confidence to be persistent can be difficult or even reputationally dangerous to muster.

At the same time, even the best-intentioned maintainers do not feel like they have the time or resources to bring contributions up to a too-high level of quality. Maintainers find themselves wishing they had the capacity to coach and collaborate with contributors to bring their contributions up to a successful level, but instead are overburdened and toil away in a vicious cycle in which new contributors never seem to develop into maintainers. The result is an endless shortage of maintenance labor.

When the bar for quality is too low, on the other hand, contributors may overwhelm maintainers with too many pieces of work to review and those pieces of work may feel too difficult to improve. Maintainers feel as if they are in a social and technical bind: They cannot be efficient, welcoming, kind, and productive all at once, and they have less time to work on what they would identify as actual software improvements. As one highly-skilled OSS maintainer we spoke with put it, maintainers can also end up maintaining things they didn't think were a good idea to implement in the first place. These conditions are conducive to burnout.

In both cases, these contributor and maintainer experiences feed back into one another: Cycles begin in which neither side is happy with their experience and/or neither side feels they or the software is benefiting from the PR process. This scenario can lead contributors to withdraw or focus too much on low-level contributions, and maintainers experience an increasing level of burnout due to both social and technical burdens.

An “optimal” bar for quality, as depicted in the image, is perhaps imaginary. It is very possible that two maintainers in the same project hold very different ideas about what the bar of quality should be, an issue that can cause its own problems within a project. In other words, projects seem to have to choose which zone of "sociotechnical hell" they place their contributors and maintainers in by setting the bar for a successful contribution either too high or too low. 

We’re eager to get feedback on this image as well as the description of the problem, and to learn about how projects deal with the problem in productive ways. We’re grateful to our peers who have already provided some thoughts, such as (copied verbatim from our Slack conversations):

"...division of labor can be inherently inefficient due to domain expertise, context-switching, unambiguous communication about the problem and related solution (PR) - see also mythical man month" -Hao Ye in The Turing Way Slack

"...estimating time is fraught even when all the pieces are static, but OSS has the problem that the underlying product can change underneath a contributor's patch-in-progress, a contributor and/or maintainer might be taking on a piece of work to grow their skill, and that element of learning is often not accounted for in time (and has its own associated uncertainties) - see also Task estimation: Conquering Hofstadter's Law" -Hao Ye in The Turing Way Slack

"Its also interesting phrasing that the contributors zones are both kinda good - one is that they go ahead and do lots... but with unknown quality - and the other is that they have to put some effort in (which I don't think is really all that bad!) "Exercise in persistent and social skill" - is maybe the point you're trying to get across here is that we often don't communicate with a new contributor that this IS part of the skill set required to contribute to open source?" -Kirstie Whitaker in The Turing Way Slack

"I think the other point that the image is missing are the number of people who STOP  / leave as a result of the persistence...." -Kirstie Whitaker in The Turing Way Slack

"I wonder if a learning lens can help frame the contributor experience: to be motivated to contribute, you kind of need to a) see the problem is difficult enough that you'd enjoy trying to solve it, b) have the moxie to share your suggestion, c) your manner of communication must be socially acceptable to the maintainer group's availability - ie it's not just social skill on the contributors part, the social interaction must be an exchange. Also, I think you approach a fallacy towards the low quality bar - imagining that potential contributors will be drawn to multiple easy tasks is a content manager's pipe dream. Too easy - what is the point? So I think making room for dignity (belonging?) and paying attention to contributing rituals which are supported and endorsed by the maintainers would be something that can qualify your linear spectrum of quality. I think that if you're using quality as your arbiter, you're not acknowledging the implicit and tacit rules of engagement that shape the different zones of sociotechnical hell." -Liz Stokes, Australian Research Data Commons, in The Turing Way Slack

"There's something about the image that I think isn't quite getting the point across super clearly. It looks like both of the maintainers zones are bad - is that on purpose? What would GOOD look like? It feels like good would be the thing HIGHER than the "I wish I could coach this person"?? Which I suppose is what a lot of maintainers would say 😅" -Kirstie Whitaker in The Turing Way Slack

What do you think? How can we revise this toward a more positive, helpful artifact for projects to use in their discussions about setting bars for quality of contributions? Hit reply and let us know! We'll be working on this further with the great folks who have already shaped these ideas, in hopes of co-authoring something more substantive. Let us know if you'd like to join!

Short updates:

• We facilitated a workshop for JupyterHub leadership in Berkeley in June, hosted by the Berkeley Institute for Data Science (BIDS). We really appreciate the way that folks came together to talk about such an incredibly impactful project, working through uncomfortable challenges and celebrating resounding successes in education and science. Stay tuned for more about our work with JupyterHub – we’ve got a report coming that includes both community introspection and opportunities for organizational development that we hope will be useful to other organizations as well.
• We’ll be attending the Hertz Foundation Summer Workshop in July as evaluators. We have long been fans of the Foundation’s community-building efforts and are excited to experience it firsthand while offering some recommendations for how to improve.
• We’ve been developing some new capabilities, particularly around offering strategic planning and implementation workshops. Our most recent engagement was with the Oregon State University Mid-Columbia Agricultural Research and Extension Center (MCAREC) and the Horticulture Department, and we’re excited to spend some time supporting the Coastal Oregon Marine Experiment Station (COMES) in August. These conversations and the resulting outputs have been really insightful, as they allow all folks in the organization to participate in envisioning next steps and determining the best ways forward in an uncertain time. Please reach out if you are interested in talking about how we can support your team in having these kinds of strategic conversations. 
• 🌿 Beth is continuing her Everyday Flourishing workshops and newsletter, where she applies principles from permaculture as a frame on work and personal life. The next workshop is on Design from Patterns to Details on Monday, July 14th at noon Pacific. All are welcome!