If you haven’t yet contributed to an open source software project, you may be eager to get going. Contributing to open source is a great way to learn, teach, and build your technical expertise. And it feels good to be part of a community. Yet your first time contributing can be intimidating. Here are five things you need to know to get up and running on open source:
-
Contributing isn’t just about writing code. Open source projects need help on a variety of things, starting with coding, but also things like designing navigation and menus, writing documentation, managing timelines, organizing open issues, moderating message boards and answering questions. Other ways to get started/ File a bug and suggest a patch for it or suggest a feature. In short, there are many ways to contribute, in line with your interests and expertise. And no matter what you give, you’ll meet people and become an appreciated member of the group – sometimes contributing on ancillary things will earn you more points than coding.
-
Confusion is ok. If you’re bewildered at first, it’s not just because you’re a newbie. Each open source project has its own culture, including terms of art, behavior norms, accepted practices, etc. So, even if you work for years on one project and are completely up to speed on what life is like there, it’s more than likely your next project will be totally different. There are some things that are usually present, such as the roles of people on the project, including author, owner, maintainer, contributor and committer. But the fact is, it will take time, observation and interacting with project members to understand how things are done within a project – and whether or not you are a good fit. If the vibe is not right, go elsewhere. There are so many projects that could use your support.
-
If there is a code of conduct, you need to get familiar with it. Not all open source projects will have a code of conduct. When you’re interested in a project, be sure to see if there is a code of conduct and, if so, what it says. That way, you won’t make a gaffe without realizing it (and having to hear about it from everyone else). At a high level, respect the other participants (see number 5, below). If there is no explicit code of conduct, there are core values and norms that are recognized in the open source community. Chief among these are kindness and worldwide collaboration.
-
Open Source Projects often have community governance models. There are three types of org structures generally associated with open source projects: BDFL (Benevolent Dictator for Life; Pythonis one example, meritocracy (this exact term may not be used but it’s about the relative “merit” of contributions; Apache projects follow this model) or liberal contribution (under which the people who contribute the most have the most say; Node.js and Rustare examples). In recent years, the BDFL model has fallen out of favor in some circles as it leaves the project vulnerable if a leader steps away. As Jason Baker wrote on OpenSource.com, “How an open source project is governed can have very real consequences on the long-term sustainability of its user and developer communities alike.” Just something to keep in mind.
-
When in doubt, ask away, there are no dumb questions. As with any group you might belong to, you and the other members will be happier if the tone is welcoming and kind. Essentially, you’re there to collaborate so respect is important. Open source participants tend to be diverse in every possible way, stay open and considerate. Women traditionally are underrepresented in open source, so be encouraging. Try not to waste people’s time and provide as much context as needed in issues and conversations. Most projects will set the expectation that participants should respect each other and be civil in their interactions.
The rules are a lot like the ones you may have learned in your childhood: Observe before you jump in, share your knowledge generously, always thank people who help you, and play well with others. Don’t be tempted to add to threads just to see your name. Try to find answers to questions within the community before you ask. Read the README file. Read the documentation. If you do ask a question or send a pull request, be patient. Don't expect an immediate reply and don’t keep posting the same question. People have different priorities and might have been caught up with work and life. Make sure you have buy-in from project implementers before you send in actual code. This shows you want to contribute and you respect the work that has gone on before you.
Ready to get started? Here are some success stories from our community to inspire you:
