The situation surrounding open source is getting increasingly complex; partly because of the legal issues that SCO's apparently doomed case against IBM has raised and partly because open source products are seeing extensive use. There is no point in pretending that open source is not a major software trend that is changing the industry - it surely is. However, it also difficult idea for commercial organizations to get their minds around and this is limiting its take-up to some degree.
To begin with, it is important to distinguish between Linux and open source. Linux may be an open source product but it occupies a particularly key position in the software world now, which transcends the open source idea.
The open source nature of Linux is important to some of its users - particularly companies that use Linux as an embedded component in mobile devices and network appliances. They need the ability to get at and tailor the source code. However, the vast majority of Linux users do not have any intention of changing the code. They just want a standard Linux to run.
The likelihood is that Linux will become a standard platform for a wide variety of contexts - indeed it has already achieved this to some degree. What holds it up most, at the moment, is its low level market share on the desktop. It is beginning to see extensive use on thin clients and this may lead it into wider desktop usage, but there is still the problem of having two GUIs (Gnome and KDE) and that's one too many - if it is to have a big piece of the desktop market.
In thinking about open source, we should set Linux aside. Linux is well supported, not only by SuSE and Red Hat, but by IBM, Hewlett-Packard and many other vendors - and this is primarily because it is a widely used server platform, not because it is open source.
There are issues with open source per se that need to be squared away for it to move forward and it is worth listing some of them for consideration:
- Open source quality is not guaranteed. The reality has been that some open source products have delivered exceptional quality in terms of design, robustness and ease of use. Apache and Zope are good examples. Open source has proven to be a viable approach to developing software but there is no guarantee that it will deliver a specific quality of product - that depends on the core team and the organization behind it. And this is, of course, quite variable.
- There is no standard open source license. Actually there is wide variety of open source licenses, just as there are a wide variety of proprietary licenses. Small companies may not care too much about this, as they probably have never even read a license, but large organizations do care because they have to. No large organization can afford the risk of not knowing the license terms for the use of key software products. The Open Source license is not a commercial contract and this may mean that the user is exposed to some legal risks.
- Open source does present some legal risks. The risk is not so much from source code being copied from proprietary products - because the source is open, there is a strong incentive for open source developers to be completely honest and (the SCO v IBM case notwithstanding) it is highly unlikely that open source products contain proprietary code. Actually it is much more likely that proprietary products do - but as no-one gets to see the code, the legal challenges are few. However open source products can, unwittingly, violate patents and the owner of the patent can legitimately sue the user of the open source. The lawyers go after the money rather than the source of the violation, which means targeting users, as SCO has. The legal risk is probably much higher in the US than elsewhere, as the US is more of a litigious society.
- Legal Indemnification. This brings us to the fact that many open source users have a genuine requirement for legal indemnification. The need for this depends upon the level of risk. The level of risk of IPR violation with some open source products is close to zero, because they are simply imitating and extending commercial products in areas where no patents are filed. Many business applications are of this ilk, but some applications are not. An open source product like GIMP, which is an Adobe Photoshop competitor, could easily infringe one of the many photo retouching patents that exist. Thus the risk varies. So far no-one has fallen foul of this, so the risk may be negligible, but it is too early to say.
- Vendor support. This brings us to vendor support. The strong support among commercial vendors for some products - notably Linux and Apache, is not the general case for open source. There are, roughly 70,000 open source projects and only a handful have what one could describe as strong support from commercial vendors. Computer Associates is standing behind Zope and Plone (as well as its own Ingres). Eclipse has strong support in IBM and elsewhere. Novell owns Ximian and Sun Microsystems and has a clear interest in Open Office. These are however exceptional situations rather than the rule.
- It's only the license that is free. Even in the above examples where a large commercial vendor has a deep interest in an open source product, the actual support you can get varies widely. Perhaps the major attraction of open source is that the license can cost nothing, but from then on, all other software costs apply to some degree: maintenance, software distribution, upgrade costs and patching, security, performance management, integration, training and so on. We could classify all of this with the word "support". The extra costs here vary and may be trivial for some products, but for others they are not.
- The talented techie factor. Some organizations have built up small teams of technicians that can exploit open source products. In doing this they cover the support risk internally and can make good use of the support networks that exist for open source products, so they address the support issue. But this is probably not an option for small organizations and very large organizations. The smaller organization will not be able to assemble the talent required and will rarely have any desire to develop such expertise anyway. The much larger organizations could invest in such a strategy but there is a need to co-ordinate support at the corporate level and the policy is more likely to be to outsource such activity - in which case they need a good support organization to outsource this to. The dilemma for such organizations is that IT support itself is a very complex issue and they already are likely to have too many agreements with too many suppliers. Open source can be seen as a needless complication to an already over-complex situation.
- The "compliance" factor. Different organizations in different industries have "compliance" standards that they need to adhere to. We're not talking here simply about data protection or Sarbanes-Oxley, but industry best practices that are very different between, say, the pharmaceuticals industry and manufacturing. IT is already a part of this in many areas and its importance will only increase. There is also the factor of local liability laws which are different between Germany, the UK and the US. The challenge for open source is to fit well within such "best practice" schemes and this normally means providing an acceptable support structure. Commercial software vendors are normally well aware of such issues but open source organizations are less so.
With open source, we are looking at a relatively new, and increasingly successful way of introducing new software which, at the moment, is rarely driven by commercial considerations that are important to many organizations. It's a new model and it is still evolving. In contrast. Commercial vendors have for many years evolved ways of doing business that address most of these issues adequately for the customer.
Until major vendors began to endorse and promote open source products, it didn't matter too much because the majority of open source products only had niche usage. Now it matters, not just because open source usage is clearly increasing, but because the technology trends - towards integration at all levels - is creating integrated software stacks and the big IT users need dependable support for these stacks. (think Veritas plus Oracle plus BEA plus SAP etc. Now throw in a few open source products.) The era of SOAs is upon us and software support, even from large commercial vendors, has become a complex area for vendor/customer agreement. When you introduce significant elements of open source into the mix, it gets more complicated still.
For open source to see wider use, the support issue needs to be addressed far better than is currently happening. Our expectation is that some major vendors (Computer Associates, Novell, IBM, HP and several others look like good candidates) will step forward to offer support for specific software stacks in a way that deals with most of the problems that are outlined above. Naturally there will be a cost for this, but that's the whole point. In the end, opting for open source products needs to be a considered activity.
Open source can provide exceptional value to corporate computing and can certainly bring down software costs, but it's not a cakewalk.
Copyright © 2004, IT-Analysis.com