Software Testing Blog

How to work better with the open-source community

Coverity Chief Scientist and Co-Founder Andy Chou recently started a fantastic discussion on EBN Online on the topic of ‘How to Work Better with the Open-Source Community’. The comments on the blog clearly indicate that it is a subject that everyone who uses open source, i.e. every group that does software development, cares about. As users of open source code, development teams are increasingly becoming the first ones to find bugs either when they deploy their own software to a large number of users, or through their own testing methods. Broadly, there are two options when using open source code within your development projects to get fixes for specific issues that affect you:

1)     Fix the bug yourself, submit the patch upstream to the project, and then maintain it going forward. This approach has two benefits:

  1. You are not dependent on the original contributor(s) and might be able to get your own release out quicker
  2. You have given back to the open source community

2)     File a bug, and get the original contributor(s) of the code to fix it. Unfortunately, you and your project are now dependent on someone else’s schedule and priorities, and there is certain amount of time before the fix finds its way downstream back to you. The advantage is that you don’t have to tie up resources on this going forward.

Whatever option is chosen, what helps speed up the process is providing as much information as possible, either with test cases and documentation when submitting a patch, or providing test scripts and precise information on events that trigger the bug when filing a report. Also, as Andy pointed out, it is best to collaborate in bite-sized chunks. Working on one or two issues at a time results in closer collaboration, a common understanding of the goals of the requested change, and a clear understanding of the technical issues to consider along the way.

On a related note, I read an interesting post recently on one of the challenges for Android. It describes the non-trivial process of getting a software update on an Android phone. With all the players involved in an Android software update -mobile carriers, handset manufacturers, Google, and Linux kernel developers – it takes time and considerable effort to push a new release out. Consider a defect in the Android operating system that exists in the original Linux kernel that Android is based off of.  The fix has to find its way from the Linux kernel, to the Android kernel, to the specific branch that the handset manufacturer is using for a particular version of the phone, and then to a distribution network of the mobile carrier that pushes it out. By now, the Google developers working on Android are probably the experts on the topic of ‘How to Work Better with the Open-Source Community’.

Leave a Reply

Your email address will not be published. Required fields are marked *