The Open Source Chronicles…

Open Source at The United Nations

July 13, 2024

It is important to share a brief history of open source and why this moment of the #OSPOForGood Conference at the United Nations or UN is so significant for the millions who have contributed to #open source software. The power of open source is because of the contributions and collaboration of people around the world towards a common need.

The 1980s paved the way for a different way of looking at software licensing and development. It was the idea expressed through license that software should be open and free for users to examine, modify, distribute and use for any purpose. This license combined with a global, collaborative community that develops the software, made it a powerful and fast way to innovate in real time.

The 1990s saw Linux using this license and collaboration to grow rapidly, replacing other operating systems across a wide variety of hardware.  It also saw technology companies overcoming their fear and adopting Linux in their product strategies by  learning to embrace a different way to collaborate across the world. The Open Source Program Office, or #OSPO as we know it now, was thus created as a center inside organizations to guide this nascent strategy.

The 2000s shows the widespread use of Open Source to build the scaffolding for the cloud and the internet.  We would not have the scale and scope of digital infrastructure across the world without open source innovation, speed, and problem solving. These building blocks of open-source software combined with a community working across the world and around the clock made it the right enabler of scale and functionality. We also see the spread of well-structured OSPOs in cloud and internet companies to organize open source strategy and
work inside companies.

The power of an OSPO is in creating a more organized and structured way to tackle the very unstructured world of open source. Setting up an OSPO signals to the world that companies are taking open source seriously and are ready to openly collaborate with others. Oftentimes, OSPOs are the first step into an organization for open source communities and collaborators. OSPOs  guide the company and help to build bridges with external collaborators. It has been a unique and important organization that I am proud to lead inside Amazon today.  For more on OSPOs check out https://todogroup.org/

The Truth about Women and Open Source

March 24, 2021

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:

  1. 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. 

  1. 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.

  1. 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.”

  1. 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:

Mentorship Programs: 

Creating Inclusive Projects: