By Nithya A. Ruff:
Nithya is the Head of Comcast’s Open Source Program Office. She is responsible for Open Source strategy and growing open source culture inside of Comcast and engagement with external communities. Nithya has been director-at-large on the Linux Foundation Board for the last 3 years and was recently elected to be Chair of the Linux Foundation Board. She looks forward to advancing the mission of the Linux Foundation around building sustainable ecosystems built on open collaboration. She has been a passionate advocate and a speaker for opening doors to new people in Open Source for many years. Nithya graduated with an MS in Computer Science from NDSU and an MBA from the University of Rochester, Simon Business School. You can follow her on twitter @nithyaruff and you can find her on https://www.linkedin.com/in/nithyaruff/
Earlier this year, I was asked by my open source colleagues in the film and entertainment segment to tackle a complex topic: What is preventing women from getting involved or more involved with open source software projects? It’s a question, of course, aimed at removing those obstacles, to attract even more diversity and activity to the open source scene.
It’s especially topical now, in March — the month that celebrates women. So many of us have served, for so long, as the only women in a room full of technologists! My aim in this blog is to share what I see as the bright spots: The truth, the changes that are making a difference, and the reasons for optimism, when it comes to building a diverse and thriving open source community.
With my experience as a woman working in open source software since 1998, and being reasonably active on social media, I opted to widen the query. This was my tweet: “To my #opensource friends, what are some of the myths that stop women & new entrants from getting involved in opensource projects?”
As you might imagine, I got a wide range of feedback. Starting with the word “myth,” actually, which kind of surprised me. It’s one of those words that carries multiple potential interpretations, but the big one is that a myth is a falsehood that gets passed down in time so many times, it seems true. Like the myth about Georgia producing the most peaches in the U.S. (sorry, Georgia: California does), or white eggs being less healthy than brown eggs (they’re equally nutritious.) It follows that for many women who responded to my tweet, the diversity issue is very real. And to them, it’s anything but a myth.
In other words, we tend to view myths as falsehoods that need to be set straight – “myth busting” being a popular variation, and my original intent for this blog. However, and as I discovered as I started writing, what we’re really battling are stereotypes about open source communities. And the good news is, I see lots of practical and tactical examples of stereotypes being “busted.” Here’s the short list:
- Truth: You do not have to be a computer programmer to participate in open source. It’s certainly true that most open source efforts start out as technical projects, and a lot of the contributions needed are in the form of code. Code was and is highly valued and rewarded by the institutions of open source. For instance, for years, it was coding and technical contributions that qualified someone “member status” at organizations like the Apache Software Foundation.
That’s changing. Just ask women like Sharan Foga, Danese Cooper and Sally Khudairi, who brought other (and fundamental) skill sets to the table that matter: Governance. Strategy. Advocacy. Marketing. Self-help, documentation and overall “digestibility” is a big one. There is a real hunger for these skills! For many years, I’ve been pointing out that open source projects and foundations need all kinds of contributions – and it’s happening. Projects like Kubernetes, for instance, reward participants for “fetching water and chopping wood” – a euphemism for doing the essential work that keeps projects going. Bottom line: Just as you don’t need to be a technologist to work in technology, you don’t need to be a developer to work in open source.
- Truth: Navigating open source communities is getting less daunting. Plenty of feedback centered on the fact that the cultures and norms of some open source communities are difficult to navigate. Terms like “tribal knowledge” tend to arise, or laments that you have to get the pull request right the first time. Newcomers routinely feel that they only hear from someone in the community when they make a mistake and get scolded. Here’s a great example:
It’s true that some projects are hard to navigate, with lots of long-time contributors who all seem to know each other. Oftentimes, norms aren’t documented, new contributors aren’t welcomed, and maintainer feedback can be unwelcoming. That makes it stressful to know what to do and how to do it.
The bright spot here is that more and more projects are putting inclusive practices in place. Knowledge about how to build a community and make it inclusive is now widely available, thanks to tools like GitHub and GitLab, which prompt and guide you to do the right thing when setting up a project. Lots of talks, books and articles exist to help define what a good project looks like and how to get started. Vicky Brasseur’s book “Forge Your Future with Open Source” is one of the best books for new people wanting to build their open source skills.
In addition, more and more projects are being released by companies and housed at foundations that exist to set standards and governance around how projects are run. Further, mentorship projects make it much easier to be mentored about how to be a good contributor. (I’ve added some resources I’ve found helpful at the end of this blog.)
Today’s projects need to compete with millions of other projects, and maintainers are increasingly aware that the best way to keep their projects fresh is to welcome contributors by actively pursuing inclusivity. A project just won’t do as well if it builds walls that make it hard to welcome people and their potential contributions.
- Truth: Not all open source maintainers are unwelcoming! This one goes wide and deep, in terms of open source stereotypes – that maintainers might as well hammer a “KEEP OUT” sign on what often feels like a private clubhouse door. The stories of tough and harsh maintainers tend to spread like wildfire. Worse, this study showed that code submitted by people using traditionally female names was rejected more than code submitted under male names.
What gives me optimism is that the OS community is increasingly demanding code of conduct frameworks, often including a neutral party to escalate to and experts to advise projects on how to handle issues. I like this, and welcome it. Every project should include upfront a code of conduct and basic articulation of its tenets. More is definitely needed on this front, specifically targeted at maintainer education, and backup/support for technical maintainers who lack the time and experience to handle what are essentially “people issues.”
- Truth: “Short-time” contributors can be challenging, but it doesn’t mean you need to join an open source community of interest “for life.” The stereotype for this one is along the lines of, if you join a project, you’re there for life; that you cannot do casual contributions or those you need for your product or use only.
It is true that it takes time to get to know a project, which means that you tend to stay involved longer. On the front end of any new community (whether it’s open source, or just moving to a new neighborhood), it takes time to get to know the people, and to build trust, before your contributions are accepted smoothly. It’s also true that people get involved and end up enjoying it so much, they stay for a long while.
The reality is that if you’re contributing for your company, it may be totally true for you that you only need to make one or two contributions, for a specific deliverable, and then move on. Ideally, however, having consistent contact with a project reduces disruption and builds trust.
Pro tip: When and if you need to switch, make sure you close out your work (documentation etc.) and make yourself or a designate available for questions, or to continue to maintain your code. This is common courtesy. The reason projects get concerned with casual contributors is because volunteer time was spent to onboard you. When you “contribute and run,” it feels like a waste of time. So: Make the effort to “leave well.”
In closing, more and more open source institutions recognize the need to welcome new contributors of all genders. Check out this comment, for instance, and a big nod to Africa for its work to build a diverse opensource world:
There remains a huge shortage of open source and technology people, even amid a clear and growing recognition of the value of diversity. And in the world of media and entertainment, we need people with creative talents as well. This is leading to more of these issues to be challenged and addressed. The Chaoss project, for instance, is issuing diversity badges to projects and events that practice inclusive practices. When widely adopted, this will allow us to select which projects to get involved in.
There are many benefits to getting involved in open source, from career benefits to finding a community that is collaborative and sharing. Institutions in open source are doing more to welcome new recipients — like the mentorship and scholarship program at the Linux Foundation. The Outreachy mentorship program is a great example of practical mentorship for becoming a contributor. For beginners, a good starting point (albeit later this year) is Hacktoberfest.
The truth is that there is space and opportunity for everyone in open source – not “just” software developers (and don’t get me wrong, developers, of course you are loved and valued, too.) Everyone has their own strengths – and those strengths are both needed and welcomed.
It’s my belief that the open source community is moving in the right direction. I hope this deeper look at some of these stereotypes and myths has encouraged you to give it another look. We need you. Thanks!
Here’s some resources I’ve found helpful:
To get involved:
https://github.blog/2020-01-22-how-we-built-good-first-issues/
https://opensourcediversity.org/
https://hacktoberfest.digitalocean.com/
https://www.firsttimersonly.com/
Mentorship Programs:
https://summerofcode.withgoogle.com/
Creating Inclusive Projects:
https://chaoss.community/diversity-and-inclusion-badging/
Additional Reading:
Balali, S., Steinmacher, I., Annamalai, U., Sarma, A., & Gerosa, M. A. (2018). Newcomers’ Barriers. . . Is That All? An Analysis of Mentors’ and Newcomers’ Barriers in OSS Projects. Computer Supported Cooperative Work (CSCW), 27(3–6), 679–714. https://doi.org/10.1007/s10606-018-9310-8
Mendez, C., Pedala, H. S., Steine-Hanson, Z., Hilderbrand, C., Horvath, A., Hill, C., Simpson, L., Patil, N., Sarma, A., & Burnett, M. (2018). Open Source barriers to entry, revisited: A tools perspective. 12.
Nafus, D. (2012). ‘Patches don’t have gender’: What is not open in open source software. New Media & Society, 14(4), 669–683. https://doi.org/10.1177/1461444811422887
NCWIT National Council of Women in Information Technology https://www.ncwit.org/sites/default/files/resources/btn_03092016_web.pdf.(2016)
Robles, G., Reina, L. A., González-Barahona, J. M., & Domínguez, S. D. (2016). Women in Free/Libre/Open Source Software: The Situation in the 2010s. In K. Crowston, I. Hammouda, B. Lundell, G. Robles, J. Gamalielsson, & J. Lindman (Eds.), Open Source Systems: Integrating Communities (Vol. 472, pp. 163–173). Springer International Publishing. https://doi.org/10.1007/978-3-319-39225-7_13
Singh, V. (2019). Women-only spaces of open source. In Proceedings of the 2nd International Workshop on Gender Equality in Software Engineering (GE ’19). IEEE Press, Piscataway, NJ, USA, 17-20. DOI: https://doi.org/10.1109/GE.2019.00010
Singh, V., and Brandon W. (2019) Open Source Software Community Inclusion Initiatives to Support Women Participation. In: Bordeleau F., Sillitti A., Meirelles P., Lenarduzzi V. (eds) Open Source Systems. OSS 2019. IFIP Advances in Information and Communication Technology, vol 556. Springer, Cham. Nominated for Best Paper. https://link.springer.com/chapter/10.1007/978-3-030-20883-7_7
Terrell J, Kofink A, Middleton J, Rainear C, Murphy-Hill E, Parnin C, Stallings J. 2017. Gender differences and bias in open source: pull request acceptance of women versus men. PeerJ Computer Science 3:e111 https://doi.org/10.7717/peerj-cs.111
Vasilescu, B., Filkov, V., & Serebrenik, A. (2015). Perceptions of Diversity on Git Hub: A User Survey. 2015 IEEE/ACM 8th International Workshop on Cooperative and Human Aspects of Software Engineering, 50–56. https://doi.org/10.1109/CHASE.2015.14
