It is clear that, where there is sufficient common interest, an Open Source philosophy is capable of providing high quality solutions. There are many examples where the high number, and depth of expertise, of reviewers has clearly demonstrated development of high reliability solutions.

The problem is however that these solutions are then entwined with licencing conditions which aim to maintain that ‘freedom’ of information (and sources) such that opportunities for developing commercial product that contains components that are open source are essentially denied because the additional developments have then to be disclosed, rendering no commercial advantage in such endeavours.

It is however possible to make a commercial business out of value-added activities around Open Source (e.g. Linux packagers like RedHat).

From a sourcing point-of-view then, what are the conditions under which you should consider the use of Open Source? If you can collect no revenue from your bespoke developments once including, or a development of, Open Source components, then what other rationale might suggest you join in such endeavours?

In Eric S Raymond’s book “The Cathedral and the Bazaar” he alludes to a number of business opportunities, some of these are paraphrased here:

• You could build an open-source tool (a ‘loss-leader’ approach) that enables people to easily access your paid-for service.
• You can bundle in software that provides the user access to the functionality of your platform, when you are in the business of selling platforms (e.g. microcontrollers, or even Silicon IP) but not developing software. This becomes significant for commodity platforms who wish to separate their customers from the concerns of component obsolescence.
• You can contribute to solutions that may be imposed as standards and are therefore not product differentiators, such as communication protocol stacks, and in doing so reduce your risk.
• You can offer a transition from closed-source to open source as an ESCROW policy where the customer requires long-term accessibility, including potentially through the derogation of functionality on which he depends, derogation of the product, or supplier business collapse.
• You can influence open-source tooling to provide features that would only otherwise be available in expensive commercial solutions e.g. Configuration Management, Version Management and Change Control, thus obviating the need for large capital investments.

Raymond identifies the major criteria for going (and by implication using – as this forces you to “go”) Open Source as where:

a)       Reliability, Stability and Scalability are critical

b)       Correctness of Design or Implementation are not readily verified other than by independent peer review

c)       When the software becomes a business-critical capital good (i.e. control of the business for customer)

d)       Establishes or enables a common computing or communication infrastructure

e)       Key methods (or their functional equivalents) are part of common engineering knowledge

“Open-source makes least sense for companies who have unique possession of a value-generating software technology, which is insensitive to failure, can readily be verified by means other than independent review, is not business-critical and which would not have its value substantially increased by network effects or ubiquity.”

Although with open source an individual, other than the product champion (‘owner’ in as much as he caretakes the development), has little direct authority on the product and its evolution, he may significantly influence development by offering suggestions for change. Depending on the capability and acceptability of the individual (or group) contributor, this could range from suggestions on potential features, to ‘patch’ proposals that offer an easy route to adding functionality to the implementation and its documentation.

The tooling, rather than delivered product, model offers many more freedoms to use open sources as seed material for bespoke non-commercial tool or method developments, but has as many pitfalls, as once ‘branched’ from the root-stock and its development community, so forfeits the maintenance, support and evolution.

___________________________________________________________________________

Let us help you maximise the business potential of your product and its software

Email me on stuart.jobbins@sofintsys.com

Visit our website, or follow us on your preferred Social Media for our latest views.     ___________________________________________________________________________