Non-Coding Contributors in Open Source

Editor’s Note: This article was written by two members of the Rubinius core team. Stacy Mullins’ writing appears in the first part of the article, and Jesse Cooke’s in the second.

“We cannot become what we need to be by remaining what we are.”

― Max De Pree

Open source communities should be fun, engaging, rewarding and purposeful. Instead, open source has morphed into a bureaucratic, misogynistic machine. I’ve read far too many stories of community members antagonizing women for going against the grain. Death threats, harassment, bullying, etc., are just a few abuses that some women have experienced. For far too long, open source communities have devalued or ignored people with diverse skill sets and backgrounds, while championing those that code or “own the code”.

These abuses ultimately force members to move on and potential ones to never join.

Part of the dysfunction in open source communities is that contributors that don’t participate on more “advanced” levels of a project, e.g., coding, aren’t held in the same regard as developers doing the programming. The idea that programmers are the most valuable is false and regressive. In fact, there is an abundance of contributions and skill sets that are just as valuable to the community. For example, users can’t use software that they don’t know about, and this opens up the door for roles promoting an open source project. Communities that strive to expand could benefit from event organizers. Hosting meetups, annual conferences, and even utilizing social media are just a few avenues where a non-tech member can provide support. Non-coding contributors can also contribute to documentation, product and project management, user studies, data analysis and interface and experience design. These are just some of the skills and specialty areas that could benefit many open source projects.

Photo CC-BY Moyan Brenn, via Flickr. 

To really involve contributors that don’t code – and not in a “cog in a wheel” sort of way, we must change the open source ethos. If open source communities continue to deny the value of contributors that can’t or don’t code, then the culture and its reputation will continue to suffer. Great ideas and perspectives will never be revealed or cultivated; instead, the community will rely on one-dimensional views that represent “the guys in charge”. The growth of the community will remain stagnant; if nothing changes, nothing can grow.

Rubinius Team

I am a new member of an open source team – Rubinius. Rubinius is a Ruby implementation, with the core mission to make Ruby better and improve open source culture. We understand the importance of technology and the effect it has on those not afforded the luxury to engage in open source projects. We embrace diversity and inclusiveness. We don’t place an emphasis on technical skills. The tradition of privileging only technical skills is a convention that triggers imbalance and inequality in the community. In addition to maintaining a healthy balance, we’ve also rejected the “gate-keeper” mentality. Our open-door policy allows community members to contribute and commit work. This level of trust sends a strong message to contributors that we respect and value their efforts.

Photo CC-BY Karen, filtered.

Attracting contributors with little to no technical experience means facilitating an environment of inclusiveness. We try to achieve this in part by adopting a flat management style. Rank and value are decoupled, placing all contributors on a level playing field; thus embracing and celebrating individuals with varying skill sets. Incorporating this style promotes transparency, encourages communication, and fosters a sense of individual ownership.

Individuals that are passionate, enthusiastic or simply interested in learning more about open source can contribute in a number of ways. Users of open source software derive from diverse backgrounds and may need to read documentation in their native language. This is a great opportunity for an open source community member to translate documentation. An asset of this magnitude accomplishes several things: it reaches an untapped population that otherwise wouldn’t have been able to use the software, further expanding the community, and also sends the strong message that we care about and value our users all over the world.

Community member that don’t hold “technical” skills can contribute in many other ways as well. It is important to underscore that although these contributions don’t involve coding, they should not be viewed as menial and devalued positions, but as the glue that holds the open source structure together.

Embracing inclusivity in open source is not about pointing fingers or making existing programmers out to be villains. The move towards inclusivity is more about developing and creating an optimal atmosphere that recognizes and includes those that are passionate and typically marginalized. Open source communities will then be able to thrive on a holistic level.

Part II, by Jesse Cooke

Involvement with open source projects can be emotional and cathartic for some, so it inherently has underpinnings in feelings, not just rational thought. This is often overlooked when building teams for projects, especially core teams, which are usually the most technically proficient members of the community. If you think of a project like a budding company, having only one type of team member would make for an untenable level of imbalance, and would be detrimental to the long-term success. So why do we do that with core open source teams?

Photo CC-BY Steve, filtered.

Rubinius is an implementation of the Ruby programming language that is focused on helping people Solve Hard Problems. Our goal is to help people new to programming have a great experience, help experienced developers run their code in a stable and fast environment, and to help businesses lower the costs to run their applications. We feel that these objectives can only be accomplished by forming a team that is not just one type of person, but a team of people with different backgrounds, skill sets, and areas of interest.

One might ask “Why is this important?” The simple explanation could be because we’re trying to fill some quota, or we’re trying to make noise with this structure. That line of reasoning doesn’t take into account the economics of an open source project: we trade our time to ship free product. Everyone on the team gives up some portion of their day, time in which they could be doing something else, to work on it. Right now, open source contributors are usually white men, largely because they have systemic privileges that make their contributions possible. Along with being more welcomed and valued in open source, they are more likely to possess a technical background and have ample time and resources to contribute. Both of these attributes are considered critical by many open source projects (resulting in even more homogenous teams), but we don’t think they are. We value meaningful contributions. Even those team members with limited time can contribute in meaningful ways. Since these contributions are valuable, we would be remiss to avoid them simply because the contributor can’t devote some prescribed amount of time. We would be hurting ourselves and the consumers of our open source product by devaluing or disallowing any meaningful contribution.

Technical talent makes up only a portion of the skills needed to ship a product, be it open source or not. There are many other factors that go into the work, like design, marketing, community engagement, speaking, etc. When you think of an open source project, especially one like Rubinius where we’re treating it more like a product, you must take into account all aspects, not just technical. Another important benefit of creating a diverse core team is that there is a larger pool of experience from which to draw, and this opens up possibilities that may have been unreachable before.

The breadth of experience increases exponentially with people of different backgrounds working together, not linearly. Other core teams could adopt this approach by having honest and open conversations with current team members on the subject, by setting goals and being held accountable to them, and by working hard to enable non-technical contributions. This means that, initially, technical core team members may need to step out of their comfort zone and expand in ways they never thought necessary. But this way of building core teams will help push open source to the next level.