Open source is a set of principles and a philosophy for software development that has been growing since the 1970s. It is a very effective model at producing high quality software. As the number of open source projects grew, along with the scope of what could be done with it, it attracted the attention of IT organizations, systems integrators, software vendors and other commercial consumers. These organizations identified a number of barriers that make it hard, and in many cases impossible, for them to adopt open source. As presented by Ray Lane at an Open Source
Business Conference a few years ago the primary barriers are:
- Lack of formal support and services.
- Velocity of change.
- Lack of roadmap.
- Functional gaps.
- License types.
- Lack of endorsements by independent software vendors (ISVs).
These barriers are real, rational, and with the exception of ‘Functional Gaps’, they are all risk-related.
It is interesting to consider these barriers in the context of Geoffrey Moore’s ‘whole product’ concept from his ‘Crossing the Chasm’ work. In essence the whole product is everything needed by the customer in order to have a compelling reason to buy make a purchase. Apple’s iPod provides a good example: the iPod music player is the core product but the whole product includes accessories, the iTunes music store (backed by agreements with the music
industry) and a lifestyle-oriented marketing campaign. It is the combination of all of these that has made the iPod the dominant player in the market (it was certainly not the first).
In the context of enterprise software the whole product includes such things as documentation, training, customer references, support agreements, website content, knowledge-base, partner program, reseller program, hosted demos, a brand name, evaluation software, and production software. For the rest of this document, it is these kinds of things that are referred to as whole product.
Proprietary software companies have a process or program that creates the whole product. This progress or program has a variety of names such as ‘Productization’, ‘Go To Market’ or ‘Release Management’. For the rest of this document I will refer to this process as ‘productization’, and the act of executing the process as ‘productize’.
Most open source projects do not have anything that equates to productization. The barriers to the adoption of open source exist because open source projects do not have have a productization process. This is the biggest difference between an open source project and a commercial open source company: an open source project does not productize the software, a commercial open source company does.
Commercial Open Source Models
There are a number of different business models that can be described as ‘commercial open source’. These models vary in pricing, structure, offerings, and start-up costs. The 451 Group has done a good job of describing the many different models that are currently being tried: http://www.the451group.com/caos/caos_detail.php?icid=694