SoapUI-101-eBook-CTA

14 Ways to Contribute to Open Source without Being a Programming Genius or a Rock Star

Plenty of people want to get involved in open source, but don’t know where to start. Here are several ways to help out even if you lack confidence in your technical chops.

open source ways to contributeOpen source software has changed computing and the world, and many of you would love to contribute. Unfortunately, many people are daunted by what they imagine is a high barrier to entry into a project. I commonly hear people say that they’d love to contribute but can’t because of three reasons:

  • “I’m not a very good programmer.”
  • “I don’t have much time to put into it.”
  • “I don’t know what project to work on.”

There are three core principles to remember as you look for opportunities to contribute:

  • Projects need contributions from everyone of all skills and levels of expertise.
  • The smallest of contributions is still more than none.
  • The best project to start working on is one that you use already.

The most damaging idea that I’ve observed among open source newbies is that to contribute to open source, you have to be some sort of genius programmer. This is not true. Certainly, there are those in the open source world who are seen as rock stars, and they may certainly be genius programmers. However, the vast majority of us are not. We’re just people who get stuff done. Sometimes we do a little, and sometimes we do a lot. Sometimes it’s programming, and sometimes it’s not.

Most of what makes open source work is actual work, time spent making things happen for the project. Most of these things don’t require the brains or vision of a Larry Wall, creator of Perl, or a David Heinemeier Hansson, creator of Rails. Designing a new language or a web framework may take inspiration, but the rest of what makes projects like Perl and Rails successful is perspiration. This work may not get all the glory, but it’s still necessary, and after a while, your contributions will get noticed.

Start listening

Everything in open source involves other people. You’re looking to join a team, and that means understanding the community and how it works. Walking in to a project and saying “Hi, here’s what I think this project should be doing” is usually not taken as a good thing. Some projects may welcome that sort of approach, but if the project has been running a while, the chances of that attitude being embraced are small. Listening is the best way to know what the project needs.

1. Join a mailing list: For many projects, the mailing list is the main conduit of communication about the development of the project. On large projects, there are many mailing lists to choose from. For example, the PostgreSQL project has no fewer than 12 user-oriented lists and six developer lists on its mailing list page. I suggest you follow the main user-oriented list and the core developer list in which to start listening.

2. Follow a blog: Blogs maintained by core developers often give information about what’s coming up in future releases, and what it’s taken to get there. A planet site aggregates news and blog entries from many sources related to the project. If there is a planet site, like planet.gnome.org or planet.mysql.com, start there. Just search Google for “planet <projectname>.”

3. Join an IRC channel: Many open source projects have dedicated Internet relay chat (IRC) channels where developers and users hang out to discuss problems and development. Check the project’s website for the details of what the channel is called and what IRC network it’s found on.

Work with Tickets

Code is the heart of any open source project, but don’t think that writing code is the only way to contribute. Maintenance of code and the systems surrounding the code often are neglected in the rush to create new features and to fix bugs. Look to these areas as an easy way to get your foot into a project.

Most projects have a publicly visible trouble ticket system, linked from the front page of the project’s website and included in the documentation. It’s the primary conduit of communication between the users and the developers. Keeping it current is a great way to help the project. You may need to get special permissions in the ticketing system, which most project leaders will be glad to give you when you say you want to help clean up the tickets.

4. Diagnose a bug: Bugs are often poorly reported. Diagnosing and triaging a bug can help save the developers save time with the legwork of figuring out the specifics of the problem. If a user reported, “The software doesn’t work when I do X,” spend some time to figure out the specifics of what goes into that problem. Is it repeatable? Can you create a set of steps to cause the problem repeatedly? Can you narrow down the problem, such as only happening on one browser but not another, or one distro but not another?

Even if you don’t know what causes the problem, the effort you put into narrowing down the circumstances makes it easier for someone else to fix it. Whatever you discover, add it to the ticket in the bug system for all to see.

5. Close fixed bugs: Often bugs are fixed in the codebase but tickets reported about them don’t get updated in the ticketing system. Cleaning up this cruft can be time-consuming, but it’s valuable to the whole project.

Start by querying the ticket system for tickets older than a year and see if the bug still exists. Check the project’s release change log to see if the bug was fixed and can be closed. If it’s known to be fixed, note the version number in the ticket and close it.

Try to recreate the bug with the latest version of the software. If it can’t be recreated with the latest version, note that in the ticket and close it. If it still exists, note that in the ticket as well and leave it open.

Working with Code

Programmers of all experience levels can help with the code in the project. Don’t think that you have to be a coding genius to make real contributions to your favorite project.

If your work involves modification to the code, investigate the method that the project uses for getting code from contributors. Each project has its own workflow, so ask about how to do it before you set out to submit code.

For example, the PostgreSQL project is very rigorous in its process: Code modifications are sent in patch form to a mailing list where core developers scrutinize every aspect of the change. On the other end is a project like Parrot where it’s easy to get commit privileges to the codebase. If the project uses GitHub, there may be a workflow that uses the pull request feature of GitHub. No two projects are the same.

Whenever you modify code, make sure that you act as a responsible member of the community and keep your code style to match the rest of the codebase. The code you add or modify should look like the rest. You might not like the bracing style or the handling of spaces for indentation, but it’s rude to submit a code change that doesn’t match the existing standards. It’s the same as saying “I don’t like your style, and I think mine is better, so you should do it my way.”

6. Test a beta or release candidate: Any project that’s designed to run on multiple platforms can have all sorts of portability problems. When a release approaches and a beta or release candidate is published, the project leader hopes that it will be tested by many different people on many different platforms. You can be one of those people and help ensure that the package works on your platform.

Typically you only need to download, build, and test the software, but the value to the project can be huge if you’re on an uncommon distribution or hardware. Just reporting back that the build and test works helps the project leaders know that the impending release is solid.

7. Fix a bug: This is usually where contributors wanting to get working on code start. It’s simple: Find an interesting-sounding bug in the ticket system and try to fix it in the code. Document the fix in the code if it’s appropriate.

It’s a good idea to add a test to the test suite to test the spot of code you fixed; some projects require bug fixes to include tests. Keep notes as you poke around this unfamiliar codebase. Even if you aren’t able to fix the bug, document in the ticket what you discovered as part of the fix attempt. What you find helps those who come after you.

8. Write a test: Most projects have a test suite that tests the code, but it’s hard to imagine a test suite that couldn’t have more tests added to it. Use a test coverage tool like gcov for C, or Devel::Cover for Perl to identify areas in the source code that aren’t tested by the test suite. Then, add a test to the suite to cover it.

9. Silence a compiler warning: The build process for many C-based projects often spew the odd compiler warning flag to the screen. These warnings are usually not indicators of a problem, but they can look like it. Having too many warnings can make the compiler sound like it’s crying wolf.

Check to see if the code could actually be hiding a bug. If not, modifying the source to silence helps to hide these false positives.

10. Add a comment: When you’re digging through the code, you may find some spots that are confusing. Chances are if you were confused, others will be  as well. Document them in the code and submit a patch.

Work with Documentation

Documentation is typically the part of a project that gets short shrift. It also can suffer from having been written from the point of view of those who are familiar with the project, rather than through the eyes of someone just getting into it. If you’ve ever read docs for a project where you think, “It’s as though this manual expects that I already know how to use the package,” you know what I’m talking about. Often a set of fresh eyes can point out deficiencies in the documentation that those close to the project don’t notice.

11. Create an example: There is no project that has too many how-to examples. Whether it’s a web API, a library of routines, a GUI app like Gimp or a command line tool, a good example of proper usage can more clearly and quickly explain proper usage of software than pages of documentation.

For an API or library, create an example program that uses the tool. This could even be extracted from code you’ve written, trimmed down to the bare necessities. For a tool, show real-world examples of how you’ve used it in your daily life. If you’re visually oriented, consider creating a screen-capture of an important process, such as how to install the application.

Work with Community

Open source is only partly about code. Community makes open source work. Here are ways you can help build it up.

12. Answer a question: The best way to help build the community is by helping others. Answering a question, especially from someone who is just getting his feet wet, is crucial to helping the project grow and thrive. The time you take to help a n00b, even if he’s asking a question where you could easily throw back a quick “RTFM,” pays off down the road in getting another active member of the community. Everyone starts out somewhere, and projects need a constant inflow of people if they’re to stay vital.

13. Write a blog post: If you’ve got a blog, write about your experiences with the project that you’re using. Tell about a problem you faced using the software and what you did to solve it. You’ll be helping in two ways, both by helping keep the project on the minds of others around you, and by creating a record for anyone else who has your problem in the future  and searches the web for the answer. (A blog of your technical adventures is also an excellent way to show real-world experience with the software in question next time you go hunting for a job using it.)

14. Improve a website: Most programmers are pretty crappy graphic designers, and it’s a rare project website that couldn’t use some help in the design department. If you’ve got skills in web design and can help improve the website, and thus the public-facing image of the project, that’s time well spent. Perhaps the project could use a graphic overhaul, or a logo to identify the project. These may be skills lacking in the community. I know I’d love it if I could get some graphic design help on my projects’ websites.

Most of all, listen to what people around you discuss. See if you can recognize a pressing need. For instance, recently on the Parrot developers’ mailing list, it was decided to use GitHub as the trouble ticket system, abandoning the old Trac installation they had. Some people were against the move because there was no way to convert the tickets to GitHub’s system. After a day of back and forth arguing, I piped up and said “How about if I write a converter?” People were thrilled at the idea. I spent the time to write a conversion program for the 450+ tickets, so we lost none of our ticket history. It was a great success.  I got to pitch in, and the core developers stayed focused on the business of working on Parrot.

There are so many ways to contribute to open source if we look past the obvious steps of writing a new product feature. Everyone who uses open source can bring their skills to the community and help keep open source a vital part of computing.

See also:

Photo credit: opensourceway


subscribe-2

  • Dreamer

    Andy, it is very informative post and it’s been featured on Habrahabr, russian IT crowd blog. 
    People (including me) have been looking for this kind of tutorial, and finally it’s here! Thanks a lot =) 
    (and pardon my english)

    • Will Worthington

      It was very nice of you but I hereby granted you permission to NOT having to apologize for your English anymore. Heck, it’s better than a lot of “native” speakers over here. :)

  • http://sullivanjoni976@yahoo.com Joni White-Sullivan

    Me gusta escuchar muchi~simo todas las lenguas del mundo, y tambien~ la gente. Histo

  • Uma mahesh Varma

    Thank you for the useful information. 
     

  • Federico

    How would I go about if I want to re-design a project’s website?

  • http://java67.blogspot.tw Java Programmer

    how many programmer , who uses open source code or library give back to community ? any figure ?

  • vineeth

    Nice post…Also informative…

  • Anish M

    Good post

  • Shahar Galukman

    Good post. 
    Gave me a first insight of how I can join to open source projects as a rookie developer.

  • http://hackeritalics@null.net Italics

    Nice article! :D The ironic part about this article is that, technically speaking, it doesn’t fit into any of the “contributing to open source projects” categories you listed, but it’s so very powerful and useful to the open source community. 
     
    Kudo’s for using all the many skill set’s you posses to do something that you believe in! (Writing, programming, etc…) ^//~

  • Barton

    One of the easiest, most helpful things that you can do is run a compatibility test suite against your hardware to see if everything works. Ubuntu has a suite called ‘System Testing’. Alternatively, there is the phoronix test suite. These send compatibility reports to Ubuntu Friendly and openbenchmarking.org respectively.

  • Christopher Moura

    Hi Andy! 
     
    This is the most complete and insightful set of advices related to contributing to open source projects.  
     
    It’ll definitely help me start contributing with the projects I use and was trying to figure it out how to help them.  
     
    Thank you very much!

  • http://www.evolutionaryit.com Joseph Guarino

    You are right on target! Open source has supernumerary ways to contribute and I’m glad to see you are bringing them to light. So often people new to FOSS forget about all these wonderful ways to get involved.

  • http://entrellaves.blogspot.com.ar gorlok

    Another great way to collaborate is localization: translating software to another language.

  • http://blog.smartbear.com Prashant Kaw, SmartBear

    @Zhou – Thanks for your sentiments, Mr. T! While we are not averse to the use of criticism on the blog – your comment does not add to the conversation, unless you elaborate on why you feel that way about Open Source. 
     
    How about a rebuttal blog post (or comment) that *explains* your POV? 
     
    Thanks in advance, 
    /Prashant aka @bloggerbear

  • Kishan

    A very useful & motivating Article on contributing to open source projects.  
     
    Thanks a ton ..

  • http://ishaqmalik.posterous.com Ishaq

    Another task which is hugely important for non-english speaking countries is to localize software and it requires virtually no programming skills.

  • Zhou Feng

    Only a fool would want to work with the incompetent people who form the backbone of most open sewer (source) project.

  • http://www.foottapperrecordings.co.uk Matthew Mellor

    Well done everyone for you input and thankyou Andy, for allowing all on-lookers in getting a better insight into ways to contribute. With these packages i am an end user, and often see ways in which they could be bettered from that point of view. Especially if we can push these packages into schools, or areas where government or personal funding is limited. I do not use MS products since testing software in Vilnius on Ubuntu OS in 2011. I use MS OS for music production and internet, and everything else is open source so you have me hooked. I have used all your social media like tabs to help spread the word. If ever you need help with communication, please feel to get in touch. I am going to join the community and see if there are subjects in which i can input. Regards. Mr Matthew J Mellor

  • Eklavya

    Very informative and motivating. Thanks a lot.

  • Eklavya

    Very informative and motivating. Thanks a lot.

  • Chrisco

    Thanks a lot, this is very encouraging. This is the type of “getting started” advice that is lacking in many areas of life. Whether it’s open source software or mountain biking, we all need to start somewhere and it helps to have ideas.

  • Michi

    15. Join the i18n (translation) team.

  • http://www.adwebstudio-bahrain.com/web-development/ bahrain website development

    great work i like your given idea’s, programing very difficult task so programmer should careful during programing.

  • http://reparacionipad.net Reparacion ipad

    Great work, keep it on.

  • http://reparaciondeiphone.es reparacion iphone

    Very informative. Thanks.

  • http://www.akgraner.com akgraner

    Thanks for this great post. You’ve summed up the points so many of us in Open Source tell people daily about how to get involved.  
     
    Bookmarking your article and site to add to my reference list. 
     
    Thanks for encouraging more partication in Open Source! 
     
    Looking forward to reading more of your posts. 

  • http://www.codezy.com Weerayut Teja

    Great informative post, it’s very useful information. 
     
    Thank you for your advice.

  • http://javarevisited.blogspot.com.ar Anubhav

    What a post, this inspires me to contribute more on Open source. I had that intention from long time, but as mentioned, stuck with some of those reasons mentioned. I like the idea about best project is the one you use, because you know quite a lot about that, to contribute and improve.

  • vishu

    for a new comer it is a great blog for knowledge and understanding the basics of a community. 

  • http://reparacionportatiles.net/ Reparación Portátiles

    Great post and very informative.

  • Tanveer Abbas

    dear sir , I m a beginner on this site , can u send me a brief description of so much long briefing. I could not under stand the basic purpose and benefit of testcomplete

  • http://www.dubaiwebdesignagency.com/services-web-development.php Dubai Web Development

    Fantastic coding guide lines, development is a very technology field, its completely depends on tricks. 

  • Pingback: POSSE homework: how to contribute to FOSS without coding | Digifesto

  • Pingback: Contribute to Open Source without Being a Programming Genius | Enjoying The Moment

  • optikfluffel

    If you’re a designer who wants to help the open source community head over to http://open-karma.com ^^

  • Pingback: Coder Read #20131122: CodePair, The best way to conduct a phone interview? | Coders Grid

  • http://www.itoctopus.com/ itoctopus

    2 questions:

    - Is IRC still relevant? I don’t know anyone who’s using it, developer or not.
    - OpenSource projects demand that contributions to the core are done by extremely smart programmers. Do you think sloppy programmers really have a chance to get their changes/bug fixes approved?

    I think the best chance for average programmers to contribute to open source is by developing 3rd party extensions/modules that can be installed on a product. They will most likely get their extensions approved and this will help the product.

    • Baustin213

      Actually, I think the you’ll find both of your answers on the top comment in this thread: https://news.ycombinator.com/item?id=6774311

      • Ryan Scheel

        I didn’t. IRC is still relevant. Mozilla has their own network. And Freenode has a lot of users.

  • Pingback: g33ktalk Weekly, Feb 13 - Open source software engineering developer community and events

  • Lei Ye

    Nice shot! thanks, Andy!

  • Tony Singh

    Hi,
    If any one need help regarding software Testing manual /automation /performance.
    please send me mail at akhurath03@gmail.com

  • Vijay Ram

    excellent post

  • Pingback: கணிணி மாணவர்கள் எப்படி வேலை தேடலாம்? | கணியம்