How (and why) to contribute to open source

Introduction

In the previous post on our blog, Daniela shared her thoughts and experiences on how difficult it can be to contribute to open source. It was hard for me to review this post. 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, we have tech rockstars giving keynotes at conferences, 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 will try to respond to Daniela and all the people who struggle to contribute to open source, and most importantly, I will try to talk about the motivations that should drive our contributions.

Contributing to Open Source

First, definitions! Computer scientists have never been good at definitions. We call “artificial intelligence” something that is not intelligent, and we call “cloud” something that is on the ground and sometimes below sea level. We tried with Free Software and we had to specify what we meant by “free”, and when we realised we needed a more specific definition we created the Open Source Initiative and we had to specify what we meant by “open”.

If we cannot agree on what open source means, we cannot agree on what it means to contribute to open source.

If we stick to the OSI definition, which is derived from Debian’s definition of Free Software, we are 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, or at least I thought we were. We are 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, easier to use, then it is clear that we are not just talking about writing code.

It would be pointless to list all the non-coding 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, 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.

Once we agree on the definition of open source and what it means to contribute, we can move on to the second point in this reflection.

Why contribute

When I started university in Bologna in the early 2000s, the first community I came into contact with was a kind of Linux user group that organized, in a very informal way, so-called “installation parties”, i.e. days when some more experienced users would guide us newbies through the first install of a Linux distribution.

In addition to guiding us through the process of installing Gentoo, which was not a random choice, they would suggest what to do when we encountered a problem or noticed something that could be improved. As you may have 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. I never made a commit to the Gentoo codebase, but I felt useful to the community when I answered a colleague’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, still one of the largest and most beautiful free software projects, and interacting with other users on issue trackers, suggesting patches, 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 was merged I felt like I could talk to Dennis Ritchie as an equal, and so I am 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 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 my context that might help them understand how to reproduce the bug.

It was therefore, and still is, a business motivation. “Don’t reinvent the wheel” has been a mantra, building on what others have already introduced and perfected and then making it better, participating in advocacy groups that shape the future of a technology, 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 did not find the same conditions in the academic environment that I did, and later that she did not find 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 pressures 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 is 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.
(This also removes Drupal from the list of trendy projects…)

Gamification, badges, likes, they’re nice things and we all 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.

How to contribute - for real

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

There are amazing programmers out there who have 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 colleague use a technology, 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 advice on how to contribute.

• Start with what you use: You 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 is 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 the 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.
• There is more than just 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.

Conclusion

Open Source is not just code. It’s a way of thinking about software, and contributing means making it better.
You don’t have 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.

Thank you for reading this far, and if you have any questions or comments, please feel free to contact me at Mastodon or LinkedIn.