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 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 forum: 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.