I’m going to tell you a long hidden secret about open source projects. It’s something no one think about when watching the glorious list of any a major project contributor. It’s something so critical but so simple you’ll probably stop reading here saying: « good teasing job Captain Obvious ».
There is no little contribution.
Fixing typos in the documentation is as important as fixing a critical bug: both of them prevents the users from running the project and affect its overall credibility.
Adding small UX improvement is as important as adding major feature because details are the difference between a good project and a great one.
Maintaining translation is as important as anything else, because it allows to broaden the users base, makes the project easier to use, and lowers the technological barrier.
Consequence: anyone can contribute to the « big » open source projects, because there’s always something to do.
I’ve done 4 Python scripts in my life. Three of them were patches for Ansible EC2 modules, and they’re all in stable 1.8. That’s something I’m proud of. At 36, after 18 years of open source contributions, Ansible is the biggest project I’ve ever pushed code to.
For years, I have watched many projects, thinking how I could contribute, to conclude « I’m not good enough ». I was wrong, you don’t need to be a Jedi to contribute to a major open source project, but it’s better to need it.
Having a problem is the most common way to start a company. It’s also the best way to start contributing to an open source project. It’s usually a bug, or a missing or unfinished feature.
Before sending code or any contribution, there’s a few steps to take.
The first one is to look for a contributing to XXX document. It’s usually in the project
doc directory, and it give the various guidelines you need to know.
Most of them are more or less the same:
- If you want to fix a bug, check if there’s an issue, if not, open one (makes release management easier, really).
- If you want to add an important feature, join a mailing list to see how it fits the roadmap.
- Provide tests when appropriate, ensure the build won’t break.
- Document what you do, ensure your commits atomicity.
When no one knows you, it’s often easier to provide targeted pieces of code, like bugs, small planned feature or refactoring. Introduce yourself to the community, even more if it’s a big one. The community is a great place to get help on contributing, having your pull requests reviewed or get advice on improving your patches (yeah even in the documentation effort).
So join us, RTFM and share the software under BSD or MIT license indeed, they got cookies*.
* It’s Friday and Friday is also called Trollday.