A guide to participating in an open source project

10 ways to start contributing to open source

redwoods
Image by : 

opensource.com

I wonder why more open source users do not actively participate in the open source community and become committers or contributors.

After understanding a project's capabilities and roadmap, anyone is able to start directly hacking the source code and contributing useful extensions. Because open source is a distributed, participatory meritocracy, the upside benefit is high and the barrier to entry is low—you don't have to move, be employed by a Valley startup, give up your day job, or wait to obtain a 4 years for a degree.

The benefits

My open source participation led to a cost efficient and adaptable infrastructure for my business, and useful trade experience skills on my resume. After giving back to the community, my open source contributions established a professional network of mentors and improved my understanding of the project.

Overall, participating and becoming an open source committer enhanced my personal brand, increased business opportunities, and filled important open source project gaps.

So, how can you begin participating in open source communities?

Daniel Doubrovkine compiled this list (below) for how anyone can become an amazing contributor; plus my additional comments and tips.

10 ways to start participating in an open source project

1. Have a real problem to solve, business need, or some type of commercially-driven motivation.

Dedicating time and effort to your open source participation requires raising the value beyond theory and hobby. The truism, Necessity is the mother of invention, drives open source participation. 

2. Understand the goals of the project and make sure your contribution is in line with them.

Work in parallel with the main trunk codebase, and in concert with the project roadmap. Open source projects are fueled by community participation, and the current community has committed to the existing project goals and architecture. While creativity and innovation are important, start by 'coloring between the lines' and working within the existing direction. If you feel the architecture requires re-factoring, considering adding plug-points to graft on your extensions. 

3. Submit complete patches that implement full features. Include any test information and documentation.

Because open source contributions are vetted and maintained by others, automated test cases and documentation are mandatory patch components.

4. Play by the rules of the project that you're contributing to.

Open source is all about community building and crowd sourcing. Project rule violations fractures trust and diminishes collaboration.

5. Be humble. Never add your name to the list of contributors yourself. The project leader should do so, if she or he values your work.

It takes awhile to gain street creds and be granted the keys. Take time to understand the view of others, and do not attempt to scale project meritocracy by diminishing others.

6. Have low expectations. Learn to accept rejection.

While open source provides a solid foundation, budget enough time and effort to integrate the project into your solution. If an early commit stomps on your work, re-factor your and move on. 

7. Persevere. Improve upon comments and keep sending updates.

Committers are busy gate-keepers, and may place low priority on your contribution. Keep enhancing the contribution and politely pointing out the contribution's value to the wider community. 

8. Be honest and vocal about your available time and skills.

While contributing source code can be daunting, other less code-intensive contribution opportunities exist. You may be more comfortable contributing documentation, blog posts, and presentations. Barbara Shuarette shares how to contribute to an open source project no matter your experience level.

9. Be a doer, not a talker or a troll.

Open source project momentum is based on source code, test cases, samples, and documentation. If you are contributing more to email discussion lists rather than the code repository, consider re-prioritizing your effort.

10. Finish what you started, don't give up.

If you correctly identified a real problem to solve, business need, or some type of commercially-driven motivation, then failure and walking away is not an option.

About the author

Chris Haddad @cobiacomm
Chris Haddad - Chris Haddad (aka cobiacomm) helps reshape IT delivery by introducing disruptive open source projects, refreshing technology platforms (think Cloud-Native), rebuild team interactions (think DevOps), and re-invent opportunity (think APIs).