Getting Started in Open Source Software

by Gordon Haff

You see open source software everywhere these days. That’s the case, in part, because the open source development model has proven to be such an effective means to create innovative new software. Maybe you want to get in on the action.

There are plenty of good reasons to do so. It’s a great way to build your professional resume, expand your skills, network and collaborate with industry peers, and showcase your expertise. Or you may just enjoy working within an open source community. But how do you get started?

Working in open source can be as simple as starting some personal project that scratches an itch and sharing it with the world. But let’s assume you’re interested in an existing project with an established upstream community. Perhaps you’re an enthusiastic user of some software and want to give back or work on some new capability.

Communities vary. They have differing formal and de facto governance structures. Some are heavily populated and influenced by developers who are being paid to work on open source by their employer. Others are passion projects of a group of volunteers. However, here are four generalizations to get you started.

Pick an Appropriate Project: The communities around upstream projects have wildly differing characters and the reality is that some are just going to be generally more welcoming to “newbies” than others. Jono Bacon argues that “A sense of belonging is what keeps people in communities. This belonging is the goal of community building. The hallmark of a strong community is when its members feel that they belong.” However, even some long-standing (and successful) open source communities—while mostly familiar and comfortable to existing members—make it harder for newcomers to adapt to the established culture and workflows.

• Part Two: Some code bases and associated tool chains are easier to dive into than others. For example, Simon Phipps has discussed the difficulties that led to refactoring LibreOffice. “The clean-up also involved a great deal of refactoring of old approaches into more modern ones and the elimination of unused code left over from defunct platforms—this is 20-year-old code, after all,” Phipps wrote. By contrast, Greg DeKoenigsberg and Michael DeHaan talk about how modularity and “option value” have helped make the Ansible project successful, quoting from a 2005 paper by Carliss Baldwin and Kim Clark of Harvard Business School entitled, "The Architecture of Participation: Does Code Architecture Mitigate Free Riding in the Open Source Development Model?"

Get Help: If you are a first-time contributor to a project, you might consider finding a mentor or an experienced project member who can review your work and provide you with some feedback as you prepare your first couple of contributions. Common feedback includes questions about how something works or why you chose a particular approach along with suggestions for improvements or requests for changes. This feedback can be tough sometimes, so it helps to assume that the feedback is in the spirit of making your contribution better and avoid getting defensive.

Communities are More Than Code: My Red Hat colleague Josh Berkus notes that “documentation is one area where most open source projects need a lot more contributions and where acceptance of imperfect submissions carries relatively low risk.” But communities are not even solely about contributing tangible things that are an inherent part of the project like documentation, a web site, or logos. The broad involvement by many types of software users in setting the direction of open source projects and working cooperatively on software that’s relevant to entire industries is a big part of what has made open source so successful. As with open source development carried out cooperatively by otherwise competing vendors, legal and other barriers to cooperation among users of the software is also lowered by open source.

About the Author

Gordon Haff is Red Hat technology evangelist, is a frequent and highly acclaimed speaker at customer and industry events, and helps develop strategy across Red Hat’s full portfolio of cloud solutions. He is the co-author of Pots and Vats to Computers and Apps: How Software Learned to Package Itself in addition to numerous other publications. Prior to Red Hat, Gordon wrote hundreds of research notes, was frequently quoted in publications like The New York Times on a wide range of IT topics, and advised clients on product and marketing strategies. Earlier in his career, he was responsible for bringing a wide range of computer systems, from minicomputers to large UNIX servers, to market while at Data General. Gordon has engineering degrees from MIT and Dartmouth and an MBA from Cornell’s Johnson School. Follow him on Twitter @ghaff.

This article was contributed by Gordon Haff, author of How Open Source Ate Software.