Open-source code is ubiquitous these days, and it is hard to find a better deal than a high-quality, free implementation of a component with a thriving and innovative community surrounding it.
It’s no wonder that by 2012 more than 80 percent of commercial software development projects will include open-source components, according to Gartner. We think even that is conservative — most of the other 20 percent are probably using open-source without realizing it.
But incorporating open-source components isn’t as free or as effortless as it might seem. It’s easy enough to download, build, and integrate most open-source software. Only later does it become apparent that working with open-source requires a different way of working in order to manage risks and efficiently incorporate ongoing changes, a process that I discussed in my previous post, Liabilities of the Expanding Software Supply Chain. We’ve been working with more than 260 open-source projects since 2006 to help them find and fix software defects through our Coverity Scan initiative. Here are some of the lessons we’ve learned:
1. Build individual relationships with developers on critical projects. Successful open-source projects rely on a network of developers bound by a common passion. If an open-source component plays a critical role in your infrastructure, it pays to have developers on your team play the role of ambassadors to the open-source community. This helps build sustained relationships, which can be helpful in getting faster assistance and a higher level of support. Relationships with de facto project leads and active contributors can result in added influence over the direction of a project. But beware: These relationships take time and effort to build, and expecting too much can lead to problems.
2. Contribute back to the community and take responsibility for a neglected area that you need. Open-source projects are usually very welcoming of contributions, whether they are defect patches, improved documentation, tests and testing infrastructure, or contributed code for new features. If an open-source component does almost all of what you need, consider adding to it to make it do what you want. The costs are likely to be much lower than starting from scratch, and the community will be grateful if you take the time to package the contribution cleanly and test and document it. Contributing back is the best way to build relationships.
3. Collaborate in bite-sized chunks. Back when we first started contributing defect reports to the Linux kernel community, we expected that they would be more impressed with more defects. But soon we found the opposite was true. If we sent out a large list of 100 defect reports, they were largely ignored. But if we sent out three to five at a time, we got instantaneous responses, and usually the defects were fixed within a day or two. We’ve found that regular, smaller contributions are easier for many open-source projects to digest. It results in closer collaboration and a common understanding of the goals of a change and the technical issues encountered along the way. Often, involving the community in the intermediate steps along a path results in less opposition when you arrive at the destination.
These are just three of the basic lessons we’ve learned, and there are many more. What has worked well for you in collaborating with the open-source community?