There is a right way to contribute to Open Source

There’s been a lot of noise recently about contributing to Open Source. Many developers contribute to Open Source projects for various reasons, including building their commit history for recruiters or gaining visibility through badges. However, experienced Open Source contributors have observed a troubling trend: contributing is seen as an obligation and a badge of honor, leading to frustration when it’s not straightforward.

A coworker of mine, Daniela, recently shared her thoughts and experiences on how difficult it can be to contribute to Open Source. I admit: It was hard for me to read. I felt like I had failed as a senior developer, as a mentor, and as a long-time member of the Open Source community. Then I started thinking about the current state of Open Source and what Daniela wrote made sense: To a newcomer, everything seems to be driven by the hype, the star count, the likes, the followers. We have tech influencers, tech rock stars giving keynotes at conferences and we have recruiters scanning GitHub profiles.

Contributing today is about being visible, not about being helpful. And I think my generation of developers is to blame.

In this post, I’d like to summarize Daniela’s story and further articulate my response to it.

For first-timers, the struggle is real

Daniela followed all the usual best practices. She began her journey by asking coworkers for advice, the most common response was to look for issues tagged ‘for beginners’ or ‘help wanted,’ perhaps in project repositories she’d already used at work. Unfortunately, after digging into many GitHub repositories, she found that they either had no “good first issue” tagged items, or they were already assigned.

Then she searched for lesser-known libraries, but found only what she recalls as “complicated tasks, even when marked for beginners, as in you had to know the codebase exceptionally well to fix even small things.” At this point, she gave up.

A few months later, she tried again with Hacktoberfest, starting gain with the beginner’s list. Guess what? Again, every single item had already been taken. She made further attempts at basic CSS fixes and documentation but they also failed.

Eventually, she met a contributor to Qwik, a popular JavaScript framework, and maintainer of a Qwik library. Thanks to his help, she managed to work on an issue, draft a pull request and get it merged. At last, she got what she wanted, but wondered if it was worth it. After all, she spent a lot of time looking for something to work on and then had to ask for help to get it done. In the end, she realized that contributing “for the sake of contributing” or because of fear of missing out just wasn’t worth her time.

Her conclusion? She would advise newcomers to do what they really want, not to feel pressured to do something for the sake of it and to do something that benefits others, not just themselves.

What contributing really means

You may have noticed a pattern in her words. The driving force seems to be the need to have something “demonstrable,” like a commit on GitHub, and so any other Open Source activity is completely out of the picture. I’d like to shift the focus to what I think it means to contribute to Open Source.

If we stick to the Open Source Initiative (OSI) definition, derived from Debian’s definition of Free Software, we’re only talking about how the source code can be accessed and how the license that governs the distribution of the software should be written.

But when we talk about Open Source, we’re not just talking about code. We’re talking about a way of approaching software, of designing it, developing it, distributing it, spreading it, making it something that benefits everyone. So being a developer in this context means thinking of software as a common good and then contributing means making it better and if by better we mean more useful, more accessible, more secure, more powerful, more stable and easier to use, then it’s clear that we are not just talking about writing code.

It would be pointless to list all the non-code contributions, I just want to point out participation in groups that create guidelines, documentation and translations, those that try to spread best practices, or all the working groups that deal with standardization. But think about how much valuable discussion is generated in GitHub issues, a discussion that leads to better software. None of these activities generate a green square in the contribution grid on your GitHub profile, but each one helps improve the entire ecosystem.

Why you should contribute

When I started university in Bologna in the early 2000s, the first community I came into contact with was an informal Linux user group that organized install fests, i.e. days when more experienced users guided newbies through getting an installation up and running.

In addition to walking us through the process of installing Gentoo (not a random choice), they made suggestions about what to do when we ran into a problem or noticed something that could be improved. As you probably guessed, this included posting to our newsgroup, starting a discussion on the official Gentoo Forums, and even using the mailing list. This approach made it natural for me and my fellow travelers to think about communicating with senior members of the community whenever the opportunity arose, at first just as generators of trivial questions, then more refined and finally as proposers of solutions or improvements.

The result? I may have never made a commit to the Gentoo codebase, but I felt useful to the community when I answered a coworker’s question about how to fix a compile error by creating a symlink to a library that was in the wrong path.

A few years later I started working with Drupal, one of the largest, and, for me, most beautiful free software projects. Interacting with other users on issue trackers, suggesting patches and reporting bugs felt natural to me. Of course, getting the green light from automated tests on an uploaded patch was a good feeling and when it merged I felt like I could talk to Dennis Ritchie as an equal — so I’m no stranger to this reward mechanism.

What drove me to contribute, however, was not the reward. It became a necessity, as I was often a few bugs away from delivering a job to a client and then I felt I had to at least give back to others what I had received, so I found myself responding to those who encountered problems I knew how to overcome, or sometimes simply helping by providing context that might help them understand how to reproduce the bug.

For me, it was, and still is, a business motivation. “Don’t reinvent the wheel” is my mantra, building on what others have already introduced and perfected and then making it better, participating in advocacy groups that shape the future of tech and many other aspects of the Open Source world codified and regulated by organizations such as the OSI, but also the Linux Foundation or the Drupal Association, are all aspects that directly impact our work and thus our business.

Reading Daniela’s post presented me with a completely different experience. Talking to her, I realized first of all that she didn’t find the same forgiving and welcoming conditions that I did in the university environment and later that she didn’t benefit from finding the communities that I did.

So the social, utilitarian, and belonging motivation that drove me, and I think many others around me, was missing, and what was left was rewards. Of course, recognition had always helped to distinguish an active member of a community from others, but it had never generated such strong pressure as to drive someone to contribute for the sole purpose of being visible. I seem to see this problem in the desperate search for a project to contribute to, any project, as long as it’s popular and publicly acknowledges contributions, and especially if it is on GitHub, which here becomes the social network where a developer’s popularity is measured.

Gamification, badges, likes, are all nice things and we love them (let’s not be hypocritical) but if they’re the main reason people contribute today, then we have a problem, and we probably created it ourselves. We’ve created an environment where it’s more important to be visible than to be helpful, and we’ve given that message to the new generation of developers, but we’re telling them today that those motivations are wrong.

So I think it’s important to reiterate what it means to do open source.
Let’s start from that foundation and try to adjust the focus.

Let’s start with a basic concept: You don’t have to contribute!

There are amazing programmers with zero commits to public GitHub repos, yet they work with Open Source projects every day. Sometimes focusing on work or perhaps a busy personal life makes it difficult to find time to contribute and that’s not a problem, it shouldn’t make us feel guilty.
Helping a coworker use a technology and making it more accessible by spreading it among your peers are examples of activities that truly benefit the entire ecosystem but do not entitle you to a badge.

But if, after making all these points, the desire to appear in a project’s CHANGELOG remains, because it makes us more desirable in the eyes of a recruiter, or because it makes us feel more important in our community, which are all things I completely understand, then I can try to give some further advice on how to contribute.

• Start with what you use. You probably work with libraries or frameworks every day, and by now you know them well; these are the perfect projects to start with. If you need to customize a certain feature to make it more useful for your project, or you find a bug, or you see that some of the documentation could be improved, that’s your chance.
  
• There’s no such thing as a “stupid contribution.” If you think you have a solution to a problem or an idea for improving something, don’t be afraid to share it. If you’re not sure, ask for feedback, but know that every contribution is valuable and the worst thing that can happen is that it’s rejected.
  
• Don’t be afraid to ask. If you don’t understand something or aren’t sure what to do, ask. There are many channels available, from the official documentation, to the issue tracker, to the community forum, to the chat, to the mailing list. Most (hopefully all) communities are welcoming and eager to help.
  
• Don’t overlook non-code contributions. You can help with translations, documentation, testing (which by the way IS coding…), or even just by spreading the word about a project.
  
• Go beyond GitHub. Many Open Source projects are not on GitHub, but they still need love. Just ask Drupal.
  
• Join Discussions. Issues and Discussions on GitHub are the most popular, but not the only, way to get started. You can learn a lot about a project from these discussions, commenting increases your visibility and participation in the community, and code contributions can often result.

The upshot

Open Source is not just code. It’s a way of thinking about software and contributing means making it better.
You’re not obliged to contribute and I hope that in the future we can create a more welcoming environment for new contributors and that the reward mechanism will change to reflect effort and dedication, rather than just commits.

Thanks for reading and if you have any questions or comments, please contact me at Mastodon or LinkedIn.