What would open-source software (OSS) contributors have known before they started? I asked and got lots of answers.
In preparation for my upcoming PyGrunn presentation about my journey to becoming a Django contributor, I asked:
Open source contributors, what did you wish you knew when you started contributing? Or is there something that kept you from contributing for too long?
And boy, did I find out. The responses to this thread are enough to fill at least one separate presentation. Knowing there is no stretch in the 20-minute budget, I have instead collated the answers in this blog post using my own words and adding my spin to them.
Thank you to everyone who contributed their insights to this article!
Note: Those interested can check the original thread on Fosstodon.
Disclaimer: Contributing comes in many forms
Before we start, I want to clarify that there are multiple forms of contributing. You might be tempted to think that only pull requests count, but that is just one option.
For example, here are some criteria that the Django Software Foundation has made for individual memberships:
- Contributing code, documentation, or tests to Django or to major third-party packages in the Django ecosystem.
- Reviewing pull requests or triaging tickets on Django or a third-party app.
- Creating learning resources (blogs, videos, etc.) for people to learn Django.
- Contributing to discussions in community areas such as the Django Forum or Discord.
- Being part of the organizing team for a Django community event.
- Serving on a DSF Working Group.
Insights
Open-sourcing insights from the open-source community feels meta, and I am all for it!
Clear documentation makes it easier to start
The presence, quality, and correctness of documentation are significant factors in getting started as an open-source contributor. They can be the difference between independence and requiring someone to introduce you.
We are talking about code documentation and contribution guides, as well as an overview of teams, responsibilities, philosophies, contact details, and more.
There are many different licenses
Each software project has a license, which is not always the same.
I admit I have not fully grasped this one, so thank you to the person who shared this overview of licenses approved by the Open Source Initiative.
The small and unglamorous tasks are worth it
Not every change makes it to the top of the release notes, which is OK. Small or trivial changes might initially feel uninteresting, but these changes keep adding up over time.
Also, do not underestimate the impact of clarifying a vague or incorrect piece of documentation: you will relieve readers' frustration and save time for everyone who had to explain it repeatedly in chat.
Your ideas and code might not make it to production
The project maintainers might disagree with your vision and usually do so for good reasons. Projects differ in long-term strategy, and your ideas could be received differently per project.
Remember: The maintainers are not obligated to accept your tickets, pull requests, and (for the trolls among us) insults.
The role of community
Community is everything in big software projects in both technical and social ways.
Take Django, which is so big that few folks know how everything works (if anyone does). You need the community to help sustain the project, support when there are questions, do quality control, and make people feel welcome.
On the other hand, if a community or maintainer is unhelpful, rude, or otherwise unpleasant, it can deter someone from contributing indefinitely.
Do not abuse the person on the other side of the internet; remember that they are someone with a personal life and feelings.
Gratitude goes a long way
Do not take help for granted; most contributors contribute in their spare time and make no money from their open-source work.
Be kind and thankful, and help where you can, and you will find people more willing to help you in return.
One of the respondents had a lovely suggestion: send thank you messages to maintainers so that their notifications become a happier place.
Separation by language, culture, and timezones
Contributors come from all over the world and have widely different backgrounds. While the software unites us, we all live in unique cultures, with varying timezones, speak many languages (and not always the industry-standard US English), and use other communication styles.
Some cultures clash more than others, not out of malice but because they are different. This does not have to be a problem, but it can lead to unwanted negativity when misunderstood.
Differences also occur within countries, based on region, upbringing, neurotype, and other factors.
And then there is many a developer's beloved subject to hate: timezones. You must be prepared to wait until the next day for a response from someone on the other side of the world.
Here is a related book tip, courtesy of the Django community: The Culture Map by Erin Meyer (not a paid advertisement).
Note: International communities can be fun. You will learn much from people not in your "bubble." Ironically, you will also discover that we have more in common than first meets the eye. Don't be afraid of engaging with people!
Tips
What can you do to make your first strides into OSS easier? Here are a few tips.
Pick a project that is dear to you
Contributing is easier when you know a project, for example, because you use it in your work.
Do not pick a project because it is popular; you will get bored with it more easily. When invested in the project's growth, you will be more motivated to contribute for a long time.
Find the right people
Sometimes, a project you love has maintainers with less than favorable behavior. Whether they are stressed or actual assholes, think hard about whether you want to spend time dealing with them.
Do your due diligence first
Maintainers deal with a large number of tickets that require action from their side, be it a feature request, complaint, or question. Their time is a finite resource, and many people want a piece.
Help people help you: do your research and provide all the relevant knowledge before you create a support question, feature request, or bug report.
Take special care when dealing with potential security issues. There are usually dedicated channels for reporting these.
Set your boundaries
How much time and energy are you willing to spend on open-source? What kind of projects would you support? Can you work within the limits of the organization?
Also, consider what you are trying to achieve by becoming an OSS developer. Is it paying back for free software, clout, exposure, boredom, or something else?
Before you commit to something, consider if it will bring you joy or get you closer to your goals.
Take timely breaks
Take a break when needed; the project will still be there tomorrow.
Again, I want to highlight this excellent presentation: Know Your Limits: On Surviving Open Source by Carlton Gibson (@[email protected]).
Fork it, change it, push it, use it (for yourself)
When your contributions do not work out, or the maintainers disagree with your vision, you can always use a custom fork instead of the official one in your projects.
Bonus: Toot by Mariatta
Do you know when you are writing an article, and the perfect anecdote passes by? May I present this toot by Mariatta (@[email protected]):
We don't say "congratulations" when someone becomes an open source maintainer.
Instead we say, "Congratulations, thank you, and sorry"
Wrap-up
Again, thank everyone who spent some of their free time answering my question. The quality of responses was higher than expected (14 years on the Bird Site lowered my expectations), which is fantastic.
OSS involves a lot of humans and, as such, can be a rollercoaster. Emotional self-control is a perk that you need if you want to become successful as a contributor.
Seeing your feature, bug fix, or improvement go out into the world is incredibly rewarding. The same goes for the first positive feedback on your blog post or a thank you from someone who benefited from your help.
Have fun contributing!