10 ways to start contributing to open source

No readers like this yet.
A sprout in a forest

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.

Chris Haddad @cobiacomm
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).

4 Comments

While I feel none of my skills are anywhere near capable of your suggestions, my way of helping has been in other ways. What I'm talking about was 10+ years ago. This was not limited to Linux, but BSD's also.

Giving advice and help on forums and message boards. That was years ago on doing that. It was needed when a lot of the responses where rtfm. Oh the good old days.

Helping with documentation. some contributors are good at the source, but not at the documentation. Help there is appreciated.

Testing patches for hardware you have that a maintainer doesn't. I ask on a mailing list how I could get an external usb hard drive recognized in xxxbsd because it worked on yyybsd. (When they first came out) The maintainer of that code got back to me in minutes and said he hadn't added it because current code worked on the small drives, but the larger capacity ones required testing and he didn't have one. Ask if I would test patches for him. He wrote the patch, I did the testing and within 12 hours it was submitted to the kernel.

You do not need to be a coding guru to lend a hand.

Many open source projects need help that requires little if any coding expertise or experience.
A group of us brainstormed a list of ~100 ways
students could get involved in FOSS:
http://xcitegroup.org/softhum/doku.php?id=f:50ways

Anyone interested in building the best of OSS enterprise business applications? Lets meet at http://www.A1.iO

ridefree: excellent comment describing how to participate.

Clif: http://xcitegroup.org/softhum/doku.php?id=f:50ways is an excellent resource. thank you for sharing!

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.