Open source: The new front

Opinion: The future is all about interoperability
Written by Simon Moores, Contributor

Opinion: The future is all about interoperability

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."

Editorial standards