2. FOSS Leadership

Open Source Needs Your Brain :)
Suggest changes

FOSS brain

Photo credit: Internet Archive Book Images via Visual Hunt / No known copyright restrictions

Words Matter

The Myth of Meritocracy, has further contributed to tendencies of underepresented groups to feel like they need to prove themselves to be considered for leadership roles, like project maintainer.

“Meritocracy” was widely adopted as a best practice among open source projects in the founding days of the movement: it appeared to speak to collaboration amongst peers and across organizational boundaries. 20 years later, we understand that this concept was practiced in a world characterized by both hidden bias and outright abuse. The notion of “meritocracy” can often obscure bias and can help perpetuate a dominant culture. Meritocracy does not consider the reality that tech does not operate on a level playing field. – Mitchell Baker, Mozilla Co-Founder on removing ‘Meritocracy’ from their governance page.

You’ve may have heard the following statistic, but it is worth repeating as being also relevant to open source:

Men apply for a job when they meet only 60% of the qualifications, but women apply, only if they meet 100% of them. - Why Women Don’t Apply for Jobs Unless They’re 100% Qualified, Harvard Business Review

Whether or not these reflect your experiences, there is more than enough research that shows so-called meritocracies have included effective forms of discrimination. This might be hidden bias, where some aspect of identity causes a person’s contributions to be routinely devalued. It might be over discrimination or harassment. t might be threats that minimize the contributions even offered. Whatever the cause, open source “meritocracies” suffer from these problems – open source projects tend to have less diversity than other software organizations.

Tackling Toxicity in Open Source Communities

Something important Mozilla, and other open source communities have adopted are strong Code of Conducts to describe the expected norms for participation. A good Code of Conduct outlines, not only unacceptable behaviors, but also encouraged behaviors. Ultimately a CoC is a tool or community health.

While the trend of open source projects adopting a Code of Conduct is increasing, there are still those who protest, and have gone so far as to adopt alternate agreements in protest. While it’s important to be aware of those individuals, and groups they are isolating themselves, and their projects.

As a project leader, one of the most important ways you can use the CoC, is to lead by example, those behaviours you want to see in your community; and to ensure that your process for reporting, and accepting reports in violation of the Code of Conduct are clear to you, and to the community you serve.

Technical Leadership

techleadership

Pull Requests are important, but what open source really needs is people to review and triage those PRs. Ultimately the quality of the project outcomes depend on 3 or more reviews of a single PR. - Maintainer, Contributing Research Interviews

As a community leader in a maintainer role, or supporting someone in a maintainer role, the two important things you can focus on are:

  1. Reviewing Pull Requests By reviewing, and testing out patches, and commits by contributors you can not only learn the technology, but give meaningful feedback to those contributors, and save engineering time.
  2. Ensuring everyone who turns up to the project is invited to join in, and has their questions answered.

Reading

Technical Maintainer

Optional Reading

Mozilla’s Code of Conduct Enforcement

On Meritocracy

Help us improve content and suggest changes to this page.