How to Contribute to Open Source

We previously discussed the power of open source contribution for an aspiring (or experienced) developer’s career. Open source contribution can not only help a developer achieve technical prowess, but it also provides non-coders with opportunities to contribute other skills. And because open source participation can open so many doors, it’s no wonder that people from all walks of life seek out exciting open source communities of like-minded innovators. 

Contributing to Open Source: A Starter’s Guide  

With so many benefits that come from contributing to open source software, it’s no wonder why so many individuals immerse themselves in an open source community. But how exactly does one get started? With millions of open source projects to choose from across so many different technologies and specialities, this may seem like an impossible task. But if you follow these steps, you’ll find that open source project and become a productive contributor sooner rather than later: 

Communicate effectively before you open an issue or pull request by:

1. 1. Reading the project’s code of conduct and contributor’s guide. A code of conduct establishes expectations for behavior among a project’s participants and protects both the maintainer and all other community members. If a project has a CONTRIBUTING file, read that as well—it explains what types of contributions are needed and how the process works.
      1. Complete a Contributor License Agreement (CLA) or Developer Certificate of Origin (DCO) first, if required. The CLA is often used by projects with large institutional backing (either corporate or nonprofit) and can vary from project to project. The DCO is a way of saying, “Yes, I have the right to submit this, and I understand that you will use it.” 
   2. Attending meetups on the project to get a sense of its norms and processes. This allows you to build relationships with other influential members of the community and get a sense of how they operate. 
   3. Giving context to the error you’re experiencing. If you’re running into an error, explain what you’re trying to do and how to reproduce it. If you’re suggesting a new idea, explain why you think it’d be useful to the project. Additionally, give your maintainers a heads up before you issue a pull request and see if they think it’s a good idea. 
   4. Doing your homework. Demonstrate your due diligence by trying to troubleshoot the issue yourself. Be sure to check a project’s README, documentation, issues (open or closed), mailing list, and search online for an answer to the issue you’re experiencing. While you are doing your research, you should also review other pull requests to better understand how they are structured. 
   5. Working on getting your code upstream. Getting your code upstream, or accepted by core project maintainers, helps ensure that any changes you are looking to make will automatically be included in future updates—therefore reducing technical debt. Additionally, there’s the added benefit of others reviewing your code and providing feedback early on. 
   6. Keeping all communication public. By keeping the conversation public, more people can learn and benefit from an exchange between you and a maintainer. Discussions can be contributions in and of themselves. Don’t reach out to maintainers privately unless you need to share sensitive information, such as a security issue or serious conduct violation. 
   7. Asking questions, but remain patient. While you might be itching to get your question answered, keep in mind that even longtime maintainers are not always familiar with every part of the project. And know that their role as project maintainer is likely one of many tasks they are juggling. Give it time and be patient. Show them the same respect that you’d want them to show you as a new contributor. 
   8. Respecting community decisions. The community may decide not to pursue your idea, but that’s okay. While you should discuss and look for compromise, maintainers have to live with your decision longer than you will, so try to understand where they are coming from. 

Gather context:

1. 1. Make sure no one discussed your idea elsewhere. Skim the project’s README, issues (open and closed), mailing list and Stack Overflow. You don’t have to spend hours going through everything, but a quick search for a few key terms goes a long way.
   2. Get to know the community members before beginning work. On GitHub, you can click “Watch” to be notified and monitor conversations within the community before doing work that might not get accepted.
   3. Look for a good first issue or other similarly tagged issues. A good-first issue is a GitHub issue or pull request that is marked by its creator as appropriate for beginners. This is usually a sign that the project is beginner-friendly and has some low-hanging fruit that new developers can work on. 

Open an issue or a pull request: 

1. 1. Open an issue in the following situations. 
      1. You can’t solve an error yourself
      2. You want to discuss a high-level topic or idea (e.g. community, vision or policies) 
      3. You wish to propose a new feature or other project idea 
   2. Keep your pull requests focused. Make it very clear why you want to create this pull request and what it does. That makes it easy for maintainers to a) understand what you are proposing, b) figure out the wider implications of implementing it and c) quickly accept it or explain why it’s not going to work.
   3. Look for a good good-first issues list. For project leaders and maintainers, creating a good first issues list can provide that all-important on-ramp for new contributors. Tern project maintainer Nisha Kumar provides tips on creating a good first issues list in her blog, such as: 
      1. Deconstruct a feature into the smallest possible or practical unit of work. 
      2. Don’t neglect to document your project expectations or coding style so that beginners have immediate access to everything they need to get started. For new contributors, good first issues are just that: an excellent starting point to learn about the project and build your reputation. 

Wait to see if your contribution gets accepted:

If your contribution does get accepted, congratulations! You’re officially an open source contributor. If someone requests changes, be responsive. They’ve clearly taken the time to review your contribution. Opening a pull request and walking away is not good community form. If you don’t know how to make changes, research the problem, then ask for help if you need it. 

If your contribution doesn’t get accepted and you’re unsure why, it’s perfectly reasonable to ask the maintainer for feedback and clarification. But ultimately, you’ll need to respect that this is their decision. If you don’t receive a response within a week after submitting your request, it’s fair to politely respond in that same thread and ask someone for a review. If you know the name of the right person to review your contribution, you can @-mention them. Just remember to keep all communications public. 

As you prepare to make your first contribution as an open source community member, use the steps above to guide your thinking. Taking these factors into consideration will not only show maintainers that you have carefully thought about how you wish to enhance the project, but it will also provide you with a roadmap should you decide to branch out and contribute to other projects as your open source development career progresses. 

For more information on becoming an effective open source contributor and tips on negotiating salary in the industry, stay tuned to the VMware Open Source Blog and follow us on Twitter (@vmwopensource). And if you’re looking for a project to start contributing to, check out VMware’s GitHub account for inspiration.