I created my first GitHub account in college, then didn’t touch it for three years. While I constantly heard about open source and the benefits of getting involved in the ecosystem, I had a real fear of starting because I thought open source was only for experienced developers, not newbies like me. 

After I graduated from University of Portland, I worked as an embedded Linuxintegration software engineer at IBM for five years. While the role didn’t explicitly contribute features or bug fixes to open source communities, we interacted with lots of open source code. As a result, I got a small taste of a few elements of open source: browsing open bugs, looking for patches, and cherry picking bug fixes. While this new world of open source was extremely interesting, I wasn’t actually contributing back to these communities. After benefiting from the open source ecosystem and community knowledge for so long at IBM, I was ready to start giving back. 

In my current role, I work at VMware as an open source maintainer for Tern, a container inspection tool that generates Software Bill of Materials (SBOMs) for container images. I enjoy having the freedom to propose features and get feedback from other maintainers and community members. Interacting with others by exploring what is useful and what our users want keeps my maintainer brain wondering: What is feasible? What makes sense? What is technically possible? As is true when developing any software product, what users want is not always what’s possible—but you still want the community to find your software useful. There’s definitely a balance to strike between what makes sense and what users will actually use. 

I didn’t always think it was possible for me to be a regular contributor to open source, but because my entry was through my job, it’s been rewarding to show newcomers that open source is more accessible than they might think. That’s something we pride ourselves on as maintainers of Tern: We want to make the project approachable for everyone, even if you aren’t a Python or container expert (as I wasn’t). Before I got started, the message I heard was that you have to be super skilled to contribute to open source. I like to change that perception when I can.

We’re still fallible even when we’re experts

I was drawn to the role at VMware because it involves working with containers, which was (and still is) a ubiquitous technology central to the way we build and deploy modern software. Given my background in Linux and the fact that containers are nothing more than a process that runs on Linux, I figured I had enough baseline knowledge to be successful in the role while also leaving lots of room for growth. When I’m looking for new opportunities, I like to take on challenges that intimidate or scare me a little bit because there’s satisfaction in proving to yourself that you can do hard things. 

That being said, I still did not feel totally qualified to apply for the role because, as far as I knew, it was better suited for someone with more open source experience. We often tell ourselves that we should only apply to jobs if we’re 100% qualified, but there’s no growth there. So I told myself to apply anyway and if I got the opportunity, I could do 50% of the job on day one and pick up the other 50% along the way.

We used a different version control software at IBM, so I wasn’t as familiar with GitHub workflows when I started contributing to Tern. As a relatively new open source contributor, working with GitHub was a little intimidating. While I understood that making mistakes was an inevitable part of the job, the mistakes you commit to GitHub are in the public domain forever. In my first few months as an open source maintainer, I got a chance to put this theory to the test when I accidentally rewrote the Git commit history for 80 commits on Tern’s main branch. Talk about traumatizing! I felt extremely stupid. 

When you make a mistake, especially one that negatively impacts or inconveniences others, there’s that initial period of panic and doubt (i.e. “I am NOT qualified to be doing this!”). But as we know, the show must go on. That means coming to terms with your mistake and asking yourself what you’re going to do to move forward. The best way I’ve found to move forward after a big mistake is to put safeguards in place that prevent it from happening again.

In this specific example, I put safeguards in place by learning about Git Hooks and how they can prevent you from pushing to certain branches so that it was impossible for me to make those same mistakes again. Then, I gave a talk about it at a local tech meetup hoping someone else might learn from my mistake, or at the very least, find comfort in the fact that even a supposed open source maintainer makes silly mistakes, too. That’s the human side of open source: Mistakes can happen to anyone.

Cultivating confidence and finding the right fit

I’ve always been an extremely competitive person. I played sports in high school, had straight As, and graduated third in my class in college. Whenever I would doubt myself in the face of challenge, my competitive nature propelled me to keep moving towards success. This is not to say that I never failed or doubted myself, but the competitive voice in my head continues to push me. I still doubt myself often. I’ll look at the accolades of someone I went to college with or a random stranger on the internet and convince myself I’m super behind in my career and should be spending more of my free time coding. I think doubting your abilities is just part of being an engineer. When you’re constantly trying to solve problems that don’t have an answer yet and work with such smart and talented people, it’s easy to convince yourself you’re there by accident. 

I studied electrical engineering in college. Despite the fact that there was a (relatively) good amount of women in our class, I would constantly get comments to the effect of, “It must be hard to be in that major when it’s so male-dominated!” Comments like this would always register as a challenge for me to be just as good or better than my male peers. Even when my male classmates didn’t know the answer, they were always confident in their abilities. I learned a lot from watching them and tried to project the same confidence in my studies, even when I was convinced I was going to fail. “Fake it ’till you make it” is very cliché, but it’s very applicable in situations where you might not yet have confidence in yourself. 

I had to apply this “fake it ‘till you make it” mantra for my VMware interview. I knew I was only qualified for certain parts of the job. Telling an interviewer I didn’t have any experience with containers wasn’t going to contribute to a positive outcome from my interview. Instead, I explained how I could leverage my past experience to be successful in this new role, and gave examples of situations when I didn’t know something and had to teach myself the subject. I ended up getting the job, and as a result, became an open source maintainer.

In school, I thought it was important to know everything off the top of my head. Entering the working world, you quickly see that’s not going to get you very far. You can’t memorize everything and even if you could, technology is changing too fast to keep up. Knowing how to find the answer is more important than immediately knowing the answer. 

When I first started interviewing for jobs out of college I was warned of the dreaded “coding interview.” To prepare, I would try to memorize every possible optimized solution to common coding problems. When I realized this was impossible for me, it completely shattered my confidence. However, as I’ve grown as an engineer, I realize that interviewing is just as much about finding a match for me as it is for the company. If a company needs an engineer that can solve any coding problem in 20 minutes, I probably wouldn’t be very successful in that role. 

Removing barriers to entry for others

I’ve always found an interest in studying people and their behaviors in different scenarios. On a personal level, it started when I was a kid. My parents went through an unfortunate divorce and I learned so much watching their interactions and behaviors. If one parent said “no” to something I’d get the other to say “yes”; it was fascinating for me to understand their behavioral motivations. Little did I know, this experience navigating competing interests at a young age was preparing me for my future job working in open source communities.

Human behaviors and patterns of communication are put under a magnifying glass in open source. Communication is especially unique because you typically communicate through written mediums via GitHub/Slack/email. Because of this, I always try to be aware of how different people might interpret the same text. How do people’s personal experiences play into it? What level of consideration do I need to give to this when I give feedback? 

One pattern of communication I commonly notice in myself is worrying that I’m going to hurt someone’s feelings, especially with feedback. I’m almost apologetic when I have to ask for changes on a pull request even though it’s my job as a maintainer. I don’t think communicating with empathy or compassion is a problem necessarily, but there’s definitely situations when being “too nice” can be interpreted as incompetence, especially as a woman. 

When I first created my GitHub account, I purposely chose a unisex handle and didn’t upload a picture to see if my experience would be different. Not surprisingly, I felt like I got a lot less pushback when requesting changes if people assumed I was male. Communicating as an assumed-male account made me feel less pressure to be overly accommodating or nice.

Responsibility might not be the right word, but I am compelled to help those new to open source because I can remember what it’s like. If there’s a Tern contributor who wants to get started on an issue and I see they’re in school, or part of an underrepresented demographic in open source, I’m more eager to provide guidance and assistance. Getting started in open source is less about the specific project and more about understanding GitHub workflows and expectations. Sometimes the most useful advice I can give a new contributor is just explaining to them how to update their pull request.  

Everyone’s been there, and a lot of them want to help

There’s this misconception in open source that you need to know every technical detail about a project to get involved—but it’s not true! You can learn a lot about a project’s community dynamics and communication style just by observing from afar. Once you find a project and community that feels like a good fit, look at their documentation. Improving documentation is a good way to get started because you can practice getting familiar with all of the workflows and reviewers before merging actual code. 

The next step is to find a mentor in the project. A lot of people in open source want to help, want to get others excited about the project, and were in your shoes at one point. By observing the community, you can find those people. They may not have time to mentor you in the traditional sense, but they might have 10 minutes here and there to walk you through something. While asking questions in a new community can feel intimidating, think of it as flexing a muscle. The more you practice seeking clarification, even when it feels vulnerable, the more you build the strength of your confidence. 

I don’t have any “official” mentors. Nisha is the other maintainer at Tern, and I’ve always considered her a mentor even though we don’t strictly call each other mentor/mentee. Besides our regular dialogue about the project, we have lots of discussions about what we want our careers to look like and give each other feedback on actions we need to take to make that happen. I also learn a lot just by watching the way she words emails, answers questions, deals with confrontation, and makes decisions about where the project should go. In my experience, formal mentor/mentee conversations can sometimes feel stiff and center around unrealistic expectations, versus relationships that just naturally evolve.

The right thing morally, and for business

There can sometimes be a perception in open source that if you’re paid to work on it, it’s less “open source-y.” And more generally in our culture, there’s a false narrative that says if you do things the hard way, it counts for more than doing things the easy way. I’m not saying there’s always an “easy way” of doing things but, especially as a mom, I know suffering does not make anything more worthwhile or rewarding. 

People should be paid. If a company is using an open source project, they should be paying or contributing back in some way. It’s important from the perspective of doing the right thing, but also from a risk perspective. Do you want to rely on a project with no insight into their development cycle, how they address security fixes, or how they decide what they’re working on next? It’s just not a smart business strategy. I think there’s a real reckoning right now in this space as we see more supply chain attacks like Log4j. We do see some attempts to stake resources into open source dependencies for big projects like Kubernetes but my hope is that we will eventually see this with smaller open source dependencies as well.

Open source can be a good gateway to gain experience for your resume but it also limits who can participate if we only expect people to contribute for free in their spare time. I’m not somebody who wants to code in all my spare time, especially when I have a family I want to spend time with, and especially not for free. Diversity of experiences and thoughts are important, and I don’t believe strictly unpaid open source promotes that setting. It’s like saying, we only want people who have all of their needs met; who can afford to do work for free; who may not need balance in their life; who don’t have family to tend to; aren’t a single parent or someone taking care of their elderly parents or sick kids. If the expectation is that you have significant free time to invest in unpaid work, it limits who can participate.

It’s not a secret that open source participation is dominated by men. I can’t help but feel that this is a general side effect of decades of societal expectation that women, and moms in particular, take care of the family and housework. I like to think that this mindset is slowly changing. In the meantime, if I find myself in a frustrating position I try to ask myself, “What can I own about this particular situation?” This may mean acknowledging uncomfortable truths, like “I didn’t stand up for myself” or “I’ve been agreeable to the point that it has affected me negatively.” Of course, not every unfortunate situation is a result of your own actions, but trying to find learning experiences amidst the difficult times is part of growth as a human being and professional. You deserve it!