The history of open source has already been written and rewritten a couple of times, so there’s no need to go back to Genesis chapter one and revisit Linus Torvalds’ “just a hobby, won’t be big” comments too often.
But open source became more than the sum of its parts and the hobbyists grew successful in domains that traditionally belonged to their proprietary relatives.
HISTORICAL NOTE: If you do still want the history of open source, then the YouTube hosted Revolution OS is about 100 minutes of the best open development commentary you will find.
So open source grew up, we know that part.
With a rich pedigree of success in the server room, open platforms eventually moved upwards through the commercial sector and across to government in many developed nations.
What open source in these (and other mission-critical implementations) demands is not only the strong active developer community that typifies any open code base — it also very often needs a level of expert support and maintenance that works at a more formalised level than that which is available for free through the community. This especially applies to teams that are trying to solve ‘hairy’ problems for which skills are in short supply, like blending and analyzing diverse, ‘big’ data sets.
Support and maintenance are important, but there’s another factor here.
Locked down, demarcated openness
More specifically (and more technically), open code is built with inherently dynamic libraries that are subject to change and community contribution at any time. However, commercial versions of open source software are always locked down and demarcated at the point of sale and therefore not subject to these dynamic changes.
This means that when organisations like NASA and the Met Office (arguably ‘mission critical’), which use commercial open source software, they are able to define the exact static form and function of applications at the point of installation.
This effectively eliminates the risk factors inherent with open code dynamism.
Other ‘COSS benefits’
A good commercial open source software (COSS) project works with lead developers that are professional and paid competitive salaries.
A good COSS model works with a high quality assurance (QA) cycle for the open source project, and a full set of services.
A good COSS model works with professional support offerings that must be available so clients can depend on timely and accurate assistance.
COSS is has proven in many situations to be more secure than proprietary because of its larger development base. This is why the US Department of Homeland Security, which has incredibly high standards, promotes its use [http://en.wikipedia.org/wiki/Homeland_Open_Security_Technology].
According to Pentaho, we will see that ultimately, commercial open source helps drive open source adoption.
The theory is that many more organisations will use open source software if they have access to support and services. Beyond that, a company behind an open source project helps assure potential users that the project has consistent vision, discipline, and longevity.
So what can a full-blown open source project with sound commercial routes ultimately achieve?
Sun Microsoft’s famously took the Java platform forward to be one of the most high-profile open (with commercial options) projects. Fast forward to today and the equally open Pentaho BI Project has worked to develop a comprehensive analytics platform that includes reporting, analysis, dashboards, data mining and ETL for true production deployment.
According to the company, “Many other projects that exist address a specific function like reporting, but not the entire BI spectrum. Most also lack the necessary infrastructure like security, administration, auditing, fail-over, scalability features, portal, and other key framework functionality. Beyond that, some projects offer open source reporting, but require an upgrade to an expensive, closed-source offering for web-based deployment or other BI platform functionality.”
Looking forward to (commercial) open source futures
If Torvalds’ view of open source was 1.0 and the commercially supported iteration of open source was 2.0, then might we naturally expect version 3.0 to come forward at some point now?
This post for Bloor Group Inside Analysis is written in association with Pentaho. The firm has exerted zero editorial influence over the content presented here and simply seeks to fuel dialogue and discussion based around its mission to provide a cost-effective business analytics platform that fuels growth and innovation.