How to Incorporate Open Source Software into a Commercial Product

(Reading time: approx. 4 minutes)

I am an idealist – and it sounds hokey, but the thought of thousands of programmers around the world writing code in their ‘spare’ time because they love to code and share, gives me faith in humanity.  But that’s not why I integrate open source into my commercial products.

I integrate open source into my commercial products because I am pragmatic.

Open source integration saves time and money.  It speeds development and reduces the cost of ownership.  The quality of open source rivals that of commercial shops because it is built and tested by a community of fanatic developers.  Commercial-grade open source is also certified on common production technology stacks to ensure interoperability, performance, reliability and security.

Open source is perfect for start-ups because it’s a cost effective way of leveraging the time and talents of a world-wide developer community.  And there is no shortage of open source.  Over $60 billion worth is freely available, well-documented and actively-supported1.

But enough about the merits of open source  If you’re reading this article – you already know all this.

Here are some lessons that I have learned…


Read the fine-print

Before integrating open source into your project, take a look at the license.  There are over 69 license types recognized by the Open Source Initiative2.  Make sure it is one of these;

Having the wrong license might subject your commercial product to distribution restrictions and limit your rights to ownership of derived works.  In short, you might not be able to sell the end product.


Not all open source is created equal

Open source projects fall into 3 different but related categories.

1.       Highly-experimental projects, incorporate bleeding edge technology and features not widely adopted and at risk of never being widely adopted.  Although the releases for this category are generally stable there is no guarantee that future releases will be backwards compatible.  There is also no guarantee that these releases will be supported at all down the road.  These projects also have smaller developer communities so finding collaborators or support is difficult.

2.       Enterprise or Commercial projects, are the opposite of the first in every way.  The releases are more structured and are backwards compatible.  Patches and bug fixes are regularly released.  There is a large community of developers and users that are actively supporting the product.  The catch is that there is usually a licensing fee.  The fee is generally several orders of magnitude cheaper than a proprietary product.  And you never get the source code of a proprietary product.

3.       End-of-life.  This category of projects has exactly the same problems as the first except there is no possibility of these projects ‘maturing’ into mainstays.  Avoid this category of projects all together.

So how are these categories related?  The projects that survive it’s infancy in the ‘first’ category mature to become mainstays in the second category.  This relationship can be leveraged if you can find a project that has a version in both categories.  You can use the free version (usually called ‘Community’ version) to do your prototyping and proof of concept and maybe even dev and then switch to the fee based commercial version once you’ve proven that it’s the right choice.  This is exactly what we are doing at Hubba with our integration of some jBoss components.

… Community and collaboration is the real power of open source – not the code …

The 50/50 rule of open source

For an open source project to make my short list of contenders there have to be 50 active project team members and the features need to meet 50% of my requirements – 50/50.  Community and collaboration is the real power of open source – not the code.  If there isn’t a large project team and user community look for another project to integrate with.  Take a look at the Apache Software Foundation’s Project Member List3 as an example of a set of projects firmly planted in the ‘contenders’ category.

If you do come across an active project with a good sized community, don’t fret if it doesn’t meet all your requirements.  After all – you’ve got the source code; extend or refactor it to suit.  Even if it meets just 50% of your requirements, it’s still a fast-forward button to getting your product live.  You’re half way there and you haven’t written a line of code!  (Remember to pay it forward by contributing back to the community.  More on this later)


Pick your integration points carefully

Do not get carried away with the fact that you have the source code and can make whatever changes you want.  The authors of the software have designed it to be used a particular way.  Even in the absence of an API you should take your time to learn and adhere to the expected usage as strictly as possible.  If possible, do not change the source at all – just extend it or create plugins.  This way you’ll maximize the benefits of free community support and reduce the cost of plugging in a replacement when the open source module reaches end-of-life.


Pay it forward

Join the community related to the open source you just implemented and contribute any fixes, extensions or enhancements you think will benefit the community.  Ideally, your module becomes part of the open source project which means you will have community support for the module for the life of the project.  Even if your module doesn’t become part of the project, participating at this level will help you develop a network of collaborators and make it easier for you to find knowledgeable support when you need it.  And most importantly, help me keep my faith in humanity : )


Have you been part of any interesting or challenging projects involving open source?  Leave a comment.  I’d love to hear about it.