COMMENT
The open source debate is moving on, says Simon Moores. No more is it just about being cheaper and more reliable and secure than proprietary software - now it's about everyone working together.
Often tired and over-discussed, the debate of open source vs proprietary software has over the summer, opened a second front: interoperability. This is injecting more life into an argument of increasingly strategic importance.
For a while now, the discussion about the introduction of open source solutions has surrounded fundamental questions of reliability, security and total cost of ownership (TCO).
A search for the 'silver bullet' argument in the analyst reports on any one of the vendor websites remains elusive. What one finds mostly surrounds the question of why one side's TCO benefit is greater than another's.
After all, TCO and return on investment (ROI) are less factors of the underlying operating system than the applications and services that support the server platform. Furthermore it's argued that TCO doesn't examine the underlying flexibility of a technology and, with it, any potential savings that accompany its implementation.
If the TCO argument isn't conclusive, then we have to start looking elsewhere if we're going to have a better opportunity to 'get the facts' - the name of Microsoft's campaign comparing Windows vs Linux in cost terms. Just as importantly, we need to judge how apparently opposing technologies can cost-effectively and productively co-exist if and when peace finally breaks out.
With the three main arguments of the OS/Linux offensive bogged-down in the detail, where do we go next for some decisive action? In my view it's towards the promise of interoperability and being clear about the true cost of acquisition - and, even more importantly, understanding why these are important questions that shouldn't be neglected.
By interoperability, I simply mean the ability of different IT networks, applications or components to exchange and use information, i.e. to 'talk' to each other.
This goal can be achieved by four means - through the development of software that is 'interoperable by design' (e.g., inclusion of XML technology in software to facilitate the easy exchange of data across different applications); through licensing and cross-licensing proprietary technologies and essential intellectual property; through collaboration with partners, competitors and customers; and through the implementation of industry standards (including open standards and broadly accessible proprietary standards) in products and services.
Whether you happen to be Microsoft or even IBM or Novell, interoperability makes sense, as you may have read in a recent silicon.com story which mentioned the interoperability benefits of JBoss working with Windows. After all, in a future dominated by web and software services, a liberal 'multicultural' approach to software interoperability offers considerable benefits to all the players involved.
Where it all may go badly wrong, however, is when the interoperability that business and the public sector desires is poorly engineered, because one solution or licensing model is mandated to the exclusion of another which may offer much greater flexibility and lower costs.
This is the main substance of the interoperability argument which is likely to occupy a great deal of editorial space over the next 12 months. Has business and in particular the public sector started along a path which, though recognising the benefits of interoperability, pays only lip-service to flexibility by electing a narrow, 'single-source' route?
A catalogue of high-profile public sector project failures over the last 12 months may encourage everyone involved in planning large IT projects to think more pragmatically on how software and services interoperate.
In looking to a future that argues for greater co-existence between both Microsoft and open source, we might be advised to explore the intrinsic flexibility and value-for-money of different solutions.
The alternative is to continue along a narrow path which increasingly specifies 'open solutions' that in principal deliver the opposite of what 'open' should mean in the first place, through simply imposing one set of standards and technologies - whether proprietary or open - over another.
To quote Winston Churchill: "If we open a quarrel between past and present, we shall find that we have lost the future."
Comments
There are 2 comments. Join the discussion
1. Richard Barrington
...and if we focus on the standards that surround the life blood of IT i.e. Data then Interoperability is the norm because the information that is being accessed can be...
Open Document Format is a case in point.
Since a number of countries have demanded that they own and will need to access the data they hold in perpetuity, there are several initiatives underway to create ODF plug-ins for Microsoft so it will be able to create/save documents just like Open Office can..
Power to the people!
2. Simon
"Where it all may go badly wrong, however, is when the interoperability that business and the public sector desires is poorly engineered, because one solution or licensing model is mandated to the exclusion of another which may offer much greater flexibility and lower costs."
Sounds like a hint at the Open Document debate.
On the one hand we now have several large users mandating an OPEN standard for their documents - effectively saying that "it's OUR data and we want it in a format we have some expectation of not tying us to a single vendor".
On the other hand there are 'certain vested interests' slagging off Open Document because "our format is richer". And of course, a certain vendor refusing to support the open standard because it thinks it has enough market share to force the issue. Just to muddy the issue, the very same vendor is using it's usual tactics of claiming to be 'open' because it uses XML - even though the XML schema is no less proprietry than it's previous non-XML formats.
The choice here is simple, go standard, or go proprietry lock in. Thanksfully people are now realising what the lock-in option means and are demanding the standards based route.
OK, so Open Document might not be the bees-knees - if so then we can discuss that and come up with a revised, improved version. But it allows us, as the article sort of hints at, to determine what software we will use in a few years time - rather than using what a single vendors tells us we are going to use.