Lose the ego
Be humble. If you are serious about contributing to an open source project that is not yours, then focus on the project, not yourself. It's unlikely you will be successful in a healthy community if you come off as arrogant / lecturing everybody, or with a personal branding agenda.
Avoid toxic projects
Take a quick look at existing discussions / issues / mailing lists / community forums. If the tone is abrasive, threatening, disrespectful, this is not a good project to start with for a newcomer. It takes a thick skin and quite a lot of experience to be able to deal with and contribute to such projects. Aim for a project where newcomers are welcomed and helped. It’s usually a good sign.
Avoid "ghost town" projects
Getting involved in a project where maintainers are no longer active takes some serious motivation and experience. You can evaluate the health of a project by asking questions like:
- are pull requests being actively reviewed?
- are issues answered?
- when was the last commit merged?
Pick a project that interests you
Contributing to an open source project represents a (possibly significant) investment of time, energy, and patience. If your interest in a project is casual, and you are unlikely to use the product yourself regularly, it's probably not a good place to start contributing.
Take time to learn before engaging
Maintainers of open source are rarely paid for what they do, and have a lot on their hands already. The more you are willing to take the required time to read documentation first, familiarize yourself with the tools, workflows and processes of that project, and genuinely try to understand the project itself on your own, the more likely maintainers are to help you out when you will really need guidance.
Help others
You are not the only newcomer. Many issues filed on open source projects are actually questions asked by new users. Gaining enough knowledge about the project to be able to answer these questions and help offset the burden for maintainers is a fantastic way to get started in a community.
File quality bug reports
There is nothing more disheartening for maintainers than dealing with duplicate reports, "not a bug" reports, and unreproducible / lacking information issues. The better your bug report is the more likely it is it will get addressed.
Help triage bugs
Another great way to learn and get started. Help flag duplicates. Identify actual bugs. Provide missing information to reproduce issues if you manage to.
Start small and easy
Take a simple bug, fix it, get it merged, learn more, rinse, repeat, before you move to a "10k patch bomb for crazy new feature". Not only will it help you familiarize yourself with the project, it will help the community get to know you and nurture relationships with maintainers.
Discuss first, implement later
Be sure to get buy-in from project maintainers before sending in actual work. Verify the team is interested in your proposed contribution and agrees that it aligns with their vision for the project. High-level design discussions can also be helpful to avoid potential pitfalls during implementation. Good communication prior to implementation maximizes the chances your contribution will be merged. It will also save you a lot of time.
Follow-up
Whether you are submitting bugs, asking questions, or sending PRs, be responsive when others ask for a follow-up. Responsiveness is an underrated quality of a contributor.
Listen to advice
Every open source community has different rules, expectations, and ways of working. If you are not willing to learn and adapt you will probably not be successful. Getting involved in open source is a learning experience. Before you can make contributions that are aligned with the project’s goals, it’s truly important that you are ready to take feedback and listen to advice from the maintainers running that project.
Cultural differences are tough
Open source communities naturally tend to be multicultural. You will meet and interact with people coming from wildly different backgrounds, some of them probably not native english speakers (I'm not ;-)). The ability to be open, understand behaviors and cultures that are not yours, are a requirement for success.
Written communication is hard
Communication in open source projects is mostly in writing. The very nature of written communication makes it hard to interpret intent. It's very easy for things to escalate from a simple misunderstanding to an intense conflict. Always keep that in mind - and learn to manage your emotions. Remember that the stakes are not that high and this is a project diverse people decide to work on together for free / fun. If you start feeling a discussion is going the wrong way and feel you can't answer without making it worse, step away from the keyboard and do not get back to it before a good night of sleep, and a cold-head re-reading of the entire discussion. And do apologize too. Sometimes you are the one sending the wrong vibe.
Quality matters
Open source doesn't mean any contributions is welcome regardless of its quality. On the contrary. When you submit code, be sure to try the best you can (and no, tests and documentation are not "nice to have" ;-)). The better the quality of your contribution will be, the more likely it is it will get accepted by maintainers and build your reputation as a solid contributors. Quick and dirty is usually not welcome (and you can always do that on your own in a fork, FWIW).
Learn to take "no" for an answer
Sometimes, a contribution will get ultimately rejected by the project maintainer. Maybe they have a different vision of what the project should be, and your work does not align with that. Rejection is still hard to process for everybody. Learning to deal with it is paramount. Remember that open source does not mean every contribution will be accepted. It doesn't even mean every contribution will be reviewed. It is of course your absolute right to voice your opinion calmly and clearly express what you think - but in the end, maintainers have last word on what gets in or not.
Don't take it too seriously
An open source project is software. This is probably not even important software. And even if it was, it's still less important than a number of actually important things in life. You will have a better time if you treat this as a pleasant hobby that you would practice with love, genuinely trying to work on it with others, and in the process creating friendly connections.
Originally posted on devflight.com by Olivier
Top comments (1)
Great post. Happy to contribute for Open Source #hacktoberfest