Why contributing to open source is scary and how to contribute anyway
authentik is an open source Identity Provider that unifies your identity needs into a single platform, replacing Okta, Active Directory, and auth0. Authentik Security is a public benefit company building on top of the open source project.
In January of 2024, a well-known open-source maintainer wrote the following message to a contributor: “You copied that function without understanding why it does what it does, and as a result your code IS GARBAGE. AGAIN.”
If you’ve been in open source long enough, you might recognize the tone of Linus Torvalds, creator and lead developer of the Linux kernel. Torvalds’ sometimes cruel messages aren’t rare (there’s a whole subreddit for these rants, after all). But in this case, the target – Google engineer Steven Rostedtstands – stands out.
If we put aside the substance of the disagreement, we can acknowledge that the tone can be intimidating – not so much to Rostedtstands, who can likely handle himself, but to onlookers who are curious about contributing. Not all of open source is like this, of course, but enough of it is like this (or close to this) that exchanges like these can make contributing to open source scarier than it needs to be.
How can a brand new contributor, much less a Google engineer, feel brave enough to contribute?
The initial temptation, for me and probably many open-source fans, is to tell new contributors it’ll all be fine. There are bad parts, we might say, but there are good parts, too. But this approach risks invalidating their fears.
In this article, I’m going to lay out five real reasons why contributing to open source can be scary for new contributors. Alongside those reasons, though, I’m going to provide five practical ways to face the fears and contribute anyway.
1. Contributions can stress already overwhelmed maintainers
One of the founding ideas of open source is known as Linus’s law, which states, “Given enough eyeballs, all bugs are shallow.” The idea is that because open source allows for many more developers to review and contribute than is possible in closed source, all bugs (and really, all problems) are more solvable.
At its broadest, the law extends to energy and effort: Theoretically, the workload should split among many contributors and maintainers, meaning no one should burn out.
Well, that part isn’t true, is it? Burnout has been the hot topic in open source in recent years. Especially after Nadia Eghbal’s research in her book Working In Public, which showed contributors often take more energy from maintainers than they give, many new contributors might be hesitant to join the fray. Contributing can feel more burdensome than helpful.
Why it’s scary
Open-source maintainers are often overwhelmed because there are many more contributors than they can realistically manage. Maintainers can start a project due to passion and when it takes off, lose their passion as a growth in users creates greater demands and a growth in contributors creates more work. You can end up suffering from success.
This issue was bubbling in open source for decades, but Nadia Eghbal’s research really brought it to the forefront. In her book, she writes, “The problem facing maintainers today is not how to get more contributors but how to manage a high volume of frequent, low-touch interactions.”
Many people think of open source as a giant community and each project as a mini-community within it. But in reality, many open-source projects are more like federations or stadiums (in Eghbal’s terminology). Maintainers appreciate contributions, but most of the work ends up falling on the maintainers. As Eghbal writes, “These developers aren’t building communities; they’re directing air traffic.”
When new contributors learn this, it’s no wonder they might feel hesitant about adding contributions to the pile. Eghbal interviewed Nolan Lawson, a major contributor to PouchDB, for example, and he said that open source popularity creates “a perverse effect where, the more successful you are, the more you get ‘punished’ with GitHub notifications.”
Who wants to punish the maintainers we respect so much?
How to contribute anyway
The key takeaway from Eghbal’s research, for new contributors, is that the most burdensome contributors were high-volume and low-touch. You can contribute better by turning those dials and contributing more effectively and respectfully.
Patience is the key. Don’t contribute right away; instead, watch the project and figure out the etiquette.
James Turnbull, VP of Engineering at Timber and maintainer of the open-source observability platform Vector, has a three-step process for learning the rules.
- Research: Many projects have backlogs, and Turnbull recommends reading through these to get ideas for your work and to see how people tend to interact.
- Review: Look through any available contribution guidelines, such as a README file or CONTRIBUTING file. These instructions, Turnbull says, will help you “ensure that your contributions are in line with community standards.”
- Ask: Talk to the community and the maintainers directly and ask them what they need. Turnbull warns that some people can be wary but that “most maintainers are super excited to get new people involved in a project.”
At first glance, this doesn’t sound like a lot of work – and it’s not! – but because so many contributors don’t do this work, it ends up being really meaningful for maintainers.
2. Open-source culture can be cold and critical
As shown in the intro, open-source culture can often be critical and sometimes downright mean. Linus is obviously an extreme example, but there are many pockets in the open-source community that are similarly cold. As a new contributor, it can be hard to face that criticism, especially if you’re feeling vulnerable about your still-developing skills.
Why it’s scary
To state the obvious: Open source is open, and that can make new contributors feel vulnerable and exposed.
Turnbull, who we referenced in the previous section, has also written about this discomfort. He writes, “One of the scariest moments of any engineer’s life is the moment before sharing their code with the world [...] You’re about to open yourself up to feedback, debate, and sometimes even criticism.”
This applies to all development, but Turnbull emphasizes a difference between working in open source vs. private companies: “In a professional environment, you can (hopefully!) assume a limited and supportive audience for your contribution. In an open-source project, however, this might be your first interaction with the community.”
That means new contributors have to worry about the usefulness and quality of their code, of course, but they also have to worry about standards, norms, and often unique rituals and house styles.
These concerns are more about anxiety and feeling welcomed, but it’s also true that some maintainers can be hostile and unfair. For example, a contributor to UglifyJS recommended a changelog for future updates, and a maintainer closed the issue with a sarcastic comment.
In this case, the upvotes and downvotes indicate people were in favor of the original question, but the experience was likely still negative. Examples like these are, unfortunately, not remarkable.
How to contribute anyway
As a new contributor, this is a classic case of choosing your battles. You might be rightfully offended by bad behavior, but you have little chance of fixing things from the outside in.
Later, when you’ve built a reputation and an expertise area, you might be able to have a positive influence. But when you’re starting out, focus on finding projects that work for you first.
Karl Fogel, author of Producing Open Source, recommends a few things to look at, including:
- Bug tracker activity.
- Commit diversity, not commit rate.
- Organizational diversity.
- Discussion forums.
- News, announcements, and releases.
The goal is to choose a project carefully and avoid ones with bad cultures. The benefit to doing this is that you’re also more likely to find a project that’s generally healthy. And once you do find a good project, the fears of a cold and critical culture can feel surprisingly distance.
When we celebrated our one year anniversary, for example, we celebrated our community first and foremost. “While there are only 7 employees at Authentik Security,” we wrote in November, “We know that our flagship product, authentik, has a much bigger team... you all!” These are not empty words nor are they rare. When you find the right project, you’ll feel welcomed as part of the team – no matter how small your initial contributions might be.
3. You might not feel skilled enough to contribute
Many open-source projects are years, if not decades, into development. Over those years, people with deep expertise have come and gone and made many major and minor contributions.
As a new contributor, making changes can feel like a real test of your programming skills. This dynamic is even scarier because many new contributors are also new developers. People often tell prospective developers to contribute to open source as a way to learn how to program, exacerbating this fear.
Why it’s scary
Let’s put aside, for the moment, whether the advice to learn programming via open source is good or not. Either way, the reality is that many developers feel lost and overwhelmed trying to figure out an entry point.
Open source is extremely diverse and sometimes extremely narrow. An expert in Python might struggle to contribute to PyTorch, for example, so a new contributor will almost certainly struggle to figure out where their nascent skills are most useful.
Some people might recommend well-maintained projects, which are the easiest to find, but there might be less low-hanging fruit available. Others might recommend newer or less popular projects, which might have issues that are easier to solve, but figuring out how to contribute to these projects can be hard.
How to contribute anyway
Start by making non-technical contributions, and as you learn more about the project (and get comfortable with open source in general), begin making small contributions to build confidence and momentum.
Non-technical contributions can be very useful and are sometimes more useful than technical contributions. As you read over issues and documents recommended in the first tip, look for non-technical opportunities to help, including in marketing, design, documentation, FAQs, and bug reports.
For example, back in 2015, Sebastian McKenzie made a big call for contributors to Babel, a JavaScript compiler. McKenzie listed a bunch of ways to contribute, but documentation topped the list. “Seriously,” McKenzie wrote, “This is mega-important [...] even the addition of a paragraph here or there is extremely appreciated.”
At Authentik Security, we provide non-technical contribution opportunities in a few ways. We have a #beta-testers channel in our Discord server, for example, where users can test out now features. We’ve also asked for broader feedback there, too. Last year, for example, we asked the community about their preference for release cycles and we lengthened the release window based on their feedback.
The latter instance is a good example of how a relatively small contribution on your part can help the project in a big way. Voting isn’t difficult but the collective effort of the community meant a lot.
4. Reputation can boost your success
There’s money in open source – not enough if you ask some burned-out maintainers – but the primary currency is reputation. Your reputation as a skilled programmer and as a valuable contributor to the open-source ecosystem can boost or limit your success. From the outside in, it can be intimidating to contribute to projects run by big names and scary to know your mistakes might follow you.
Why it’s scary
Open source, according to Eric Raymond, author of The Cathedral and the Bazaar, runs on a “gift economy.” According to Raymond, who made this point in the late 1990s, reputation is more important than anything else to earning acceptance and influence in open source.
Raymond’s argument revolves around the idea that in open source, abundance – not scarcity – is the rule. “Within it,” Raymond writes, “There is no serious shortage of the ‘survival necessities’—disk space, network bandwidth, computing power. Software is freely shared. This abundance creates a situation in which the only available measure of competitive success is reputation among one's peers.”
The scary part of this, as Raymond writes elsewhere, is that “status is delicately dependent on the critical judgment of peers.” If you’re already anxious about your skills, knowing your status depends on the judgment of people you don’t know well can make your anxiety even worse.
How to contribute anyway
Similar to the strategy in tip four, the trick is to look for multiple ways to build your reputation.
At first glance, the way to build your status is to make impressive code contributions. But for a new contributor, this is likely difficult. Instead, focus on demonstrating your energy as you learn. You can provide a lot of value by being reliable and consistent. Over time, being the person everyone can depend on can form a real reputation. Similarly, if your energy is positive, your reputation can benefit, too. You’re contributing to a community as well as a project.
Remember, too, that open source is a long game. As Raymond writes, “Past bugs are not automatically held against a developer; the fact that a bug has been fixed is generally considered more important than the fact that one used to be there.” Over time, your contributions will build your reputation more than your mistakes might hurt it.
5. Too many projects to choose from
Like an author sitting down to write a novel, one of the most intimidating parts of open source can be the blank page: how do you choose which project to start with?
Why it’s scary
According to GitHub’s Octoverse survey, “In 2022 alone, developers started 52 million new open source projects on GitHub—and developers across GitHub made more than 413 million contributions to open source projects.”
For open source veterans, the vast amount of projects, contributors, and maintainers can be exciting. For new contributors, it can be intimidating – not only because of the sheer numbers involved but because each project can have different expectations, cultures, and standards.
How to contribute anyway
New contributors often feel a lot of pressure to pick the “right” project or issue. That pressure creates a lot of fear. Instead, treat your natural interest as your North Star. Look for projects that you’ve used before and look for projects you’ve heard good things about.
Some new contributor resources can also come in handy, including Code Triage and Good First Issues.
- With Code Triage, you can monitor a project to see what kinds of issues they have and how you might contribute.
- If you’re less interested in particular projects but more interested in the best issues to start with, you can use Good First Issues to find starting points.
You can also look for projects you’d like to be a user of, as well as a contributor to. At Authentik, for example, we offer a free open source product, and our users benefit from the product while we benefit from the feedback and code contributions. Choosing projects that you’re interested in as a user allows you to contribute in multiple ways.
Everyone starts small, and you should, too
Everyone starts small. Don’t believe me? Check out First Pull Request, a tool that lets you enter a GitHub username and see the person’s first PR.
The author of PyTorch, for example, Adam Paske, didn’t start big. His first open-source contribution (on GitHub, at least) was merely adding the “possibility to fill the box with text” in cli-box, a library for generating ASCII boxes via NodeJS. And then there’s me – 10 years ago, I got started with a simple contribution to three.js, a JavaScript 3D library.
As you start looking for projects and getting involved in the community, do a little snooping and see how they got started. Even the biggest and best open-source developers started small, and you should, too. The trick is starting: Once you start, you have momentum, and once you have momentum, you can go further than you could ever predict.
Nick Moore contributed to this post.