Originally published on OpenSource.com.
Contribute to open source! It’ll look great on your resume! It’s gratifying work!
You may have heard people make these statements, or ones similar to them, numerous times throughout your career. They’re not wrong—contributing to open source is a rewarding endeavor in multiple dimensions—but, when software engineers advise other software engineers to contribute to open source they usually mean code contributions. This is a fair assumption to make, but the reality is that there are numerous opportunities to contribute to open source without writing a single line of code.
How? Let’s run through some of the non-code opportunities to contribute to open source.
Evangelize
Non-code contributions to open source often involve evangelizing on behalf of the project. If you’re in love with the latest JavaScript plotting library and use it for all your data visualization needs, consider sharing that expertise in a technical talk. This is a great way to develop your own reputation and to attract more users to the project.
Report bugs
More users means more bug reports. More bug reports means more bug fixes. More bug fixes means better software. That’s right! You’ve now indirectly, but meaningfully, contributed to the improvement of the software without writing a single line of code.
Mentor
Sometimes those bug reports can be a little….well, sparse on the relevant information. It can take a long time for the core developers of a project to work with the author of the bug report to fully understand the scope of the problem. This valuable time can instead be dedicated towards the development of the project. That’s where you come in! Guiding first time bug report authors through the process of writing a good bug report is a valuable and nuanced process that can save the core team of any open source project many headaches. This might involve that you write a little bit of code but ideally you would be mentoring another developer through the process.
Write
Now if you are not fond of public speaking and don’t fancy bugs (and I can’t blame you), you can write words, not code, in the name of open source. Informative blog posts about the particular project are useful and once again attract more users to the project (and all the goodness that comes with). If blog posts are too extensive an effort for you, consider answering questions about the technology on mailing lists, StackOverflow, or Twitter. This is a great way to not only develop your own knowledge about the technology, it contributes back to the collective pool of information available about it.
Host a meetup
If you’re an outgoing and obsessive project manager like me, you might consider hosting workshops or starting a Meetup in your town around the specific open-source tool. This gives you a chance to build non-digital communities around the project. These communities can be valuable for individuals who can’t afford to be online all the time (yes, they exist and yes, they matter) and for individuals who prefer to put a face to an avatar when interacting with other users about software.
Improve security
Finally, something that is often overlooked in some open-source projects is security. If you have experience with cybersecurity or security testing, consider donating your skills for the improvement of the project. Finding and providing fixes for security holes is a direct way to improve the software and the user experience around the project.
Conclusion
I never liked the term open source because it forces developers to think within the narrow confines of bytes, bits, and 80-character wide lines. Open source is so much more than that. It’s about open knowledge, open sharing, open growth, open learning, open debate, and a constant push forward. Most great software wasn’t created in front of a computer and there is no reason you should limit your ability to contribute to open source by a text editor and a keyboard.
Top comments (0)