One of Angela Byron’s first pieces of code, typed on a VIC-20, was a BASIC program that turned a red box blue. From that color-changing square, she would go onto to become a Google–O’Reilly Open Source Award recipient, the first woman ever featured on the cover of Linux Journal, a core contributor to Drupal, and the co-author of an O’Reilly book. She would not, however, get there via the most traditional path.
As a teenager, Byron wasn’t taking college CS courses or studying math textbooks for fun. She was hanging out on a message board run by Chainsaw Records, a Queercore record label from Portland. Byron taught herself Perl, PHP, and MySQL hacking together new features for the community. After graduating high school, she forewent pursuing a CS degree to move to Canada with her girlfriend, where Byron worked a series of jobs, including a stint running IT for multiple Canadian provincial governments.
In Byron’s words, she was being paid so little that she “didn’t qualify for a worker’s visa,” and so she enrolled in a community college to retain a visa. It was at community college that she, after more than five years in Canada, was accepted into Google’s Summer of Code in 2005. It was there she got to contribute to an open source CMS called Drupal — the project she’d spend the rest of her career working on.
Since 2005, she has become one of the most prolific contributors to open source software, helping guide Drupal through its dozens of iterations. Along the way, she helped build one of the most diverse, welcoming communities in open source that exists today. While Byron is the first to admit “we are not perfect,” Drupal is a project that puts diversity front-and-center in its mission.
With the open source community’s well-documented diversity problem, her advice is particularly important. Below, we’ve broken down three of Byron’s key recommendations for building a diverse community — whether your running an open source project or not.
Part of fostering an inclusive environment, Byron says, is being explicit about your standards for communication — in all forms. “We adopted a code of conduct, both for our online interactions as well as our in-person events, which helps a lot,” she says. “It makes everyone clear on what type of behavior is ok and which is not.”
For example, Byron instituted a policy of using gender-neutral pronouns in the Drupal documentation and — more broadly — the codebase itself.
It’s also important for a code of conduct, she says, to include clear guidelines for conflict resolution. Drupal dedicates a team of four to this initiative. “We introduced something called the Community Working Group, which is a body of people who are there in case things get too heated, or someone is being a jerk,” Byron says. “You can escalate to someone who has mediation experience who can try to calm that person down and get things back on track.”
The Community Working Group’s documentation includes guidelines for:
By making sure prospective and existing community members know they will be treated with respect — and that in the event that they are not, they have real power to address the problem — Drupal strives to be a welcoming community for a diverse group of contributors.
If you want to attract a diverse group of contributors, you have to first show there is a path for a diverse group of people to become project leaders. Promoting diverse contributors is the approach Drupal found to be most effective for doing this.
As Byron points out, this mindset is crucial not just for attracting a group of contributors with diverse identities, but with diverse skillsets and backgrounds, as well. Attracting designers, writers, and other non-engineer contributors to open source projects is hard, but by promoting people of all identities and backgrounds, Byron says Drupal has been able to attract designers, writers, and other creatives with harder-to-find, for open source projects at least, skillsets.
We’ve done a lot (by) elevating people who are doing great work. For example, someone who’s really passionate about accessibility or usability, finding those people and shouting from the rooftops what they’re doing and, often, promoting them to an actual leadership position in the project. So for example, promoting them to a subsystem maintainer, which has some sign-off on (developments), or promoting them to a product manager on the core committer team. That sort of thing.
Within the Drupal community, there is also an independent Diversity and Inclusion board that champions a number of initiatives promoting diversity and inclusion, from a career initiative focused on helping underrepresented people find jobs in tech, to a D&I Contribution Team that helps underrepresented people contribute to the Drupal codebase. As it says in Drupal’s statement of values, “We believe that the Drupal project benefits from a diverse contribution pool, and we strive to foster a welcoming and inclusive culture everywhere Drupal exists — at events, online, and in our workplaces”
If you want a diverse contributor base, Byron says, you need to do more than superficially embrace diversity. You need show the world that your team takes diversity and inclusion into consideration in all decisions, especially on a product-level.
We’re not just saying, ‘Oh, diversity in contributions is great.’ We actually put that into our development practice. We have a set of Core Gates, which are checks that need to pass before a patch can be committed to the project. In addition to some standard ones like automated testing, performance, and more tech-y things like that, there are also gates around the usability of a new feature, the accessibility of a new feature, to ensure that we’re not letting those things kind of fall through the cracks.
The Gate also includes instructions for how a contributor can test any of these requirements independently, making sure each patch is usable by as many users as possible. With any open source project, contributors typically begin as users, and so it logically follows that by having a diverse group of users, you will endear yourself to a diverse group of contributors.
Byron admits that for most engineers, open source work is a luxury, and one that is not afforded to underrepresented people. Currently, Byron works at Acquia, a company launched by Drupal’s creator, in a role that allows her to work on Drupal more or less full-time, but this was not always the case.
In fact, Byron describes her early, pre-Acquia career by saying, “I would say that I completely, unsustainably ran two full-time jobs… I had my full time job that was doing…implementation work. It was consulting with companies on Drupal-based solutions. It was doing architecture, leading teams of other developers, all that kind of stuff. And then I had my other full-time job, which was my volunteer, community management stuff — reviewing patches, coding stuff for core. I was basically running two full-time jobs, which is not recommended. It cost me a marriage.”
This arrangement is not uncommon for engineers interested in contributing to open source projects, and in Byron’s experience, limits the ability of many underrepresented people to contribute. “Most women in traditional relationships don’t have the kind of free time…to even chisel out time for open source,” she says. In her experience, companies — particularly ones that profit from open source technology — can solve this problem by giving employees time to contribute to the projects the company uses.
For “companies to build that time in, especially if they’re making a significant amount of money off of open source, it’s just a morally right thing to do,” Byron says. “It equals the playing the field so that we can get more underrepresented groups contributing to these projects.”
Originally published at angel.co.
Create your free account to unlock your custom reading experience.