Wednesday, October 31, 2007
Commercial Open Source
Open Source as a product development model offers a number of advantages over traditional proprietary development. One key advantage is in the management of requirements defects. Requirements defects come in a range of flavours - from the mis-prioritisation of a feature, to the complete absence of a feature which proves to be critical. Many projects fail as a direct result of requirements defects (in my opinion is the the major cause of failure in software projects), but avoiding requirements defects requires 3 things:
- A system designer/integrator/analyst who understands the nature of requirements, preferably in the appropriate application domain (in this case, Radiology services).
- Early and considered input and feedback from as many end-users as possible. While an active user community of thousands is a luxury most projects cannot boast, a single (or two, or even even three) end users on an ‘advisory board’ is too much of a skewed opinion.
- A mechanism for communicating opinions and requirements efficiently.
The first of these is a skill many (by no means all) developers learn to some extent through experience. The remaining two are well addressed by open source development methodologies.
But on this project, we are firm believers in the added value offered to an open source project through being underwritten by a commercial entity. Whether it is call “commercial” FOSS, or “professional” FOSS, or any of the other epithets (I personally prefer ‘underwritten’ or even ’sponsored’), the fact remains that there are very few truly community-only FOSS projects that can claim broad success.
Even the ‘Godfather’ of them all - Linux - is very largely based on contributions from developers paid specifically to do so by organisations such as Red Hat and others. One recent estimate puts the contribution made by individuals known to be working in a professional capacity at at least 50%. The figure for contributors known to be working independently is only 9%. I am not aware of similar studies for projects under the Apache or Mozilla umbrella although I suspect the results would be similar. That study also notes, interestingly, that by far the majority of ‘unattached’ contributions is in the driver tree of Linux development – the other trees (/fs, /kernel, /Documentation etc) being in general maintained by commercial sponsorships.
The fact remains that there are many aspects of software systems - particularly at the ‘enterprise’ level, that commercial organisations do significantly better than unattached FOSS communities (there are of course exceptions). These include marketing, support and the aspects of software development that the developers themselves tend to dislike (such as documentation [a generalisation, I know, but valid nonetheless]).
James Dixon of Pentaho has a great vision of commercial FOSS as a beekeeper, carefully encouraging bees (developers) to produce while at the same time encouraging customers (users) to consume (use) and feeding back into the ecosystem. Everybody wins. But some or all of the bees can fly away at any time (at least in theory) and the beekeeper has to compete with factory-bred honey (proprietary software). Ok, maybe the metaphor breaks down a little there but it is a good illustration of how commercial OSS can offer value, and especially in the context of ‘Enterprise’ systems.
What is an ‘Enterprise’ class system? It is possible to define the term in terms of scale, or scalability, or performance, or reliability. I think of it quite simply, hopefully combining those elements and perhaps more. I would define the term as “it does exactly what it says on tin” (credit), and it keeps on doing it regardless”. But the reality is that even in simple software solutions that’s a tough thing to do without some element of hand-holding (support). In underwritten open source software, the revenue stream that funds that support can also supply a consistent source of contribution and progress into the product itself, which can be taken advantage of by all. Everybody wins.
Indeed, in situations where community size may be limited, it is hard to see how ‘Enterprise’ class software can be produced without commercial support. Those successful OSS projects where non-commercial support is in many cases a viable option (e.g. Linux, Apache, PHP et al), have a sizable catchment area to build community from and have been successfull in doing so. Where communities are themselves limited (and I’m trying hard to avoid the word ‘niche’), the work needed to build a quality product should generally be done by full-time staff. How does the win-win cycle finish? Few describe it better than Matt Asay (on this occasion in a pre-Alfresco incarnation).
THAT IS NOT to say that non-sponsored projects do not produce fantastic software. There are many that do and I raise my hat to those. But we do believe that in the case of PACS/RIS, the scope and nature of the ‘problem’ is such that a commercially-sponsored solution can seriously challenge the proprietary vendors.
The key lies in understanding that Open Source is not ‘just’ a different way of developing software. It is a fundamentally different way of structuring the relationship between the providers of a software-based system, and the end-users. Traditionally, in the software world, once a contract is signed, all risk is on the side of the purchaser. The vendor may be good at support and post-sales services, but may not. The risk is in the hands of those who have just handed over wads of money. Even the supposed driver of ‘industry reputation’ isn’t much of a mitigator - who is likely to say “Yeh, we decided to hand over $3M to vendor X and they turned out to be donkeys”.
In commercially-active open source, the dynamics change. With the software open to anyone to change, sell, and support at will, the underwriting company carries the risk. Either they stump up with quality services, or the purchaser has the option of moving elsewhere. Is that good for the purchaser? Obviously. Is that good for the vendor? Yes but only for the vendors that truly offer true added value and only if the true difference between open source and proprietary software can be communicated to the purchasers. Result? Win-win.