Why to Encourage Software Developers to Debug and Extend Open Source

Posted by Nicholas DiPiazza on February 8th, 2012 in Support

So let’s say your company Acme Inc. hosts several software applications that are based on open source technologies. Your development team seems to be pretty skilled at writing code, and for the most part utilize these open source libraries effectively.

For example, you have a Jboss Application Server hosting your web application (an open source application server), use Maven to manage your dependencies, JMeter to test your software, and so on. All sorts of open source software elements are scattered about.

At this point (whether you realize it or not) – you utilize open source technology heavily and rely on it for your company’s success.

But then during the testing of a production release, you encounter a software bug in your open source library that is a blocker (a “blocker” is a term used to describe a bug that prevents key functionality in your application). In a panic, every one of your developers struggles to find a way to get your release to come out on time.

Thankfully, one of your rock star developers pulls down the source code for the open source library from the internet, gets a build working on this development environment, identifies the issue in the code, fixes the problem, repackages the library, and the updated version of the library is used. Problem solved, disaster prevented, release is on time!

Two important points to note about this whole thing:

First point: Unfortunately for many software companies, there is no rock star to save the day. Most developers do not dare check out the source code and attempt a fix. It is an daunting task, especially for developers who are already stretched thin on their own projects.

Second point: After you have made a change in the source code, now what do you do? You end up maintaining a branch from the original version of the product. Now when you upgrade to a new version of the software, you are stuck spending lots of time trying to re-incorporate your fix into the latest branch (if that is even necessary, it might already be fixed).

What is the solution? Promote open source software collaboration in your organization! Allow individuals in the organization to spend some of their time throughout the day becoming contributors to the open source software packages you use and you will both have the in-house expertise you need, have connections to other contributors in case you hit a nasty issue, and your fixes will be incorporated in the actual versions of the project you are using.

You might feel that your organization simply doesn’t have the resources available to do any open source contributions. Especially in a slow economy, developer time is expensive and needs to be properly allocated.

In this case you will probably not make changes to your open source software unless you are experiencing a major issue that you need to solve. And if you have already made the changes, have tested it and the issue is resolved… it really doesn’t take that much more effort to release the fix to the community. And remember, releasing the fix to the community helps you in the long run – as the fix will then likely make it into the later releases.

And it is definitely worth mentioning that getting your in-house programmers to do bug fixes is not your only option. Another option is to purchase short term open source support from a company like OpenLogic. You can rely on third party support to make the changes to the open source project, and rely on them to submit the fix to the community. This is a great option when you need one of those urgent fixes but you do not have the in-house knowledge or resources to put forth.