Justifying the commercial license for open source

It was the late summer of 2008 that I found myself sat listening to Sun Microsystem’s then CEO Jonathan Schwartz explain how the open source model would work for customers in practice. Sat as I was at the last JavaOne conference before Oracle’s acquisition of the Java innovators, Schwartz said something like:

“Hey, the software is free. When you want the services that go with it, we’ll be there to provide them for you.” For ‘provide’ you can obviously take it that he meant ‘sell’ of course.

So how do companies now continue to justify the open source model and validate their option to sell a commercially provided service, support and maintenance package in this space?

Of course proprietary software does have the TCO (total cost of ownership) factor over and above the single initial outlay; and this will always include the cost of upgrades, training, support and other incremental charges. So in many ways the two models are not so dissimilar, as ongoing costs in a commercially deployed scenario are only to be expected.

But does commercially supported open source still have the edge?

David Richards is president & CEO of WANdisco Inc, a company that works at both the commercial and the open code contribution level on the Subversion source code version management product. Richards insists that open source has much more to offer than just being the ‘cheap’ option.

“Open source projects are typically a collaborative effort from a distributed team, which encourages transparent, archived communication in the form of mailing lists and forums, which are a valuable source of information for the user. This collaborative environment also means that potentially thousands of developers can contribute to a single project, which encourages innovation and shorter release cycles,” he said.

So how does the company substantiate the need for professional support?

“While forums and mailing lists can be an invaluable source of information, they are typically places to share information on bug workarounds and common mistakes; they aren’t the ideal place to reach out to when disaster strikes your organisation! You can file a ticket requesting a fix, but just because the bug is causing your organisation headaches, doesn’t mean it’s a high priority for the rest of the community. It’s likely you will have to wait in the queue for your problem to be addressed and, for mission-critical issues, this isn’t really an option,” said Richards.

This subject doesn’t end at support it seems. There is also the issue of indemnification coverage with regard to intellectual property claims made in relation to open source software deployments. Indemnification against legal action resulting from the use of open source software should form part of any commercial open source support package.

WANdisco’s Richards also suggests that looking for an open source software support option should also involve selecting a) a company with global reach for follow-the-sun support and b) a company that dogfoods and has a good number of employees that are

full ‘committers’ (key open source developers) on the project selected.


When dogfooding is important…

Richards underlines this by saying, “Without this it is virtually impossible to really support the product. How do you even debug a basic problem without good, hands-on access to the source code for example?”

Finally (although this subject is far bigger than we have had room for here) there is also the issue of stringent license terms for any piece of open source software. Reading what it says on the tin is of paramount importance.

Steve Ballmer’s comments may be somewhat overstated here, “Linux is a cancer that attaches itself in an intellectual property sense to everything it touches,” said the Microsoft CEO. But there is an issue to be addressed here for sure.

This entire subject is still open, in every way…