I attended a round table to discuss the use of open source software in government, with Red Hat, Ingres, Alfresco, and on the government side representatives from the Office of National Statistics and Islington Council.
It is a fascinating topic on several levels - and not just for government. The two big questions: first, what is the rationale for prefering open source; and second, if you are convinced of its desirability how on earth do you get a huge, diversified entity like the UK government to increase its adoption?
There is clearly some kind of disconnect. The government already has a policy which stops short of mandating open source, but does say:
Where there is no significant overall cost difference between open and non-open source products, open source will be selected on the basis of its additional inherent flexibility.
In other words, given two otherwise equal proposals, open source is favoured - yet in practice we were told that 95% of software in use in the UK government remains proprietary.
So why is that? There are dozens of reasons. It's the available skills, with armies of experts in Microsoft, Oracle, IBM, and so on, compared with only a few willing to specify open source technologies. It's the culture, with countless existing supplier relationships and a well-trodden procurement path with the usual suspects. It's the existing envirnonment: if you start from a point where the servers are Windows, say, and the desktops all have Microsoft Office, it feels more comfortable to continue down that path. It's the lock-in, especially when it comes to things like proprietay SQL extensions and stored procedure languages, that simply do not port easily to new database managers. And it's canny vendors, who go for site licences with the widest possible scope, so that if a small group decides to break the mould and use something different, it looks more like a cost than a saving - because they are already licenced for the proprietary stuff.
These are tough obstacles to overcome. Put another way, the rationale for adoption has to be exceptionally strong to overcome the inertia; and it was here that I found the round table unconvincing. The open source companies gave diverse reasons for the benefits. Lower cost was mentioned frequently. By contrast, John Powell, President and CEO of Alfresco, talked intensely about how the UK was somehow handing over its soul to silicon valley, by not building up local skills in open source software. Someone else said how nice it was that open source software was free so that everyone in an organization could use it; another gently observed that since most open source companies make their money from support agreements that are per user, this is often not the case.
The most persuasive rationale is that open source software tends to support open standards and therefore avoids lock-in. This lowers long-term costs, by ensuring that the customer always has freedom to switch.
The snag with all these arguments is that the proprietary companies can counter them easily. They will reel off all the open standards they support. They will draw graphs showing how much money you save by using their stuff. They will point out that those with skills in their technology can easily market them worldwide. The outcome is that nothing changes.
I don't doubt that leading vendors make excessive profits on software that should be commoditised and cheap, or that vendors follow strategies designed as much to keep us hooked on their stuff, as to advance technology for our benefit. It's a cycle that needs to change.
At the same time, the open source vendors have to recognize - and to be fair, I reckon they often do - that most of us will not switch for ideological reasons. We want to get our work done. The best open source projects, things like the Apache web server (if there is anything like it) succeed on sheer quality and reliability, not merely through being open source.
The tough question: does the open source ecosystem have sufficient resources to deliver that quality, against proprietary vendors with huge profits to pour into research and development? There are plenty of decent open source products; the number that are truly best of breed is more limited. Currently it is the big proprietary vendors that have the advantage.
I left the table with more questions than answers. Should governments introduce more draconian legislation, to counterbalance the industry bias towards the status quo? Will the move towards cloud computing break the pattern? Should legislation be focused on mandating standards support, or even that applications should be proven to work on two different platforms, rather than the matter of open versus closed source? If today's MySQL is tomorrow's Oracle, is there really any difference? Isn't there too much to worry about already, solving problems and delivering successful projects?
If pressed, I would always incline towards the best technical solution, rather than one which ticks boxes, even open source boxes. That said, we are all susceptible to being bamboozled, not even looking at open source alternatives if we already know a proprietary tool or component or platform that will do the job. Even for individual developers, it makes sense to choose the open source solution in cases where other things are equal; and to think twice before building vendor lock-in into the applications we create.
I've been mulling over the implications of the news that Sun's JRuby team leaders, Charles Nutter and Thomas Enebo, are leaving Sun because of uncertainty about the future of their project after the Oracle acquisition. They will be joining Rails specialist Engine Yard. This is the key quote from Nutter:
To be honest, we had no evidence that Oracle wouldn't support JRuby, but we also didn't have any evidence that they would.
JRuby is by all accounts excellent - I'm aware that developers at ThoughtWorks use it, and Ruby advocate Martin Fowler (who works there) told me that it works very well for them, observing that some enterprises who would be reluctant to deploy the native Ruby runtime are more comfortable with running Ruby applications on the JVM (Java Virtual Machine). It is foolish of Oracle to let the JRuby guys slip away, particularly bearing in mind the trend towards dynamic languages (like Ruby) rather than static-typed languages (like Java).
What does this suggest about the future of Java itself under Oracle's stewardship? If Oracle could have done more to reassure Nutter of its continuing commitment to JRuby, so too it could do more to reassure the rest of us that investment in Java and its community will continue as strongly under Oracle as it did under Sun. Maybe it will, maybe it won't; though culturally I suspect the new company will be averse to Sun's habit of investing heavily in projects with little obvious potential for direct revenue. The failure to monetize Java fully, along with the failure of its bold experiment in open source, is one reason for the acquisition itself.
That does not imply that Java will go away - Oracle itself is a heavy user, and defending its future was likely a factor in its willingness to purchase Sun. Still, it would not be surprising if the community is a little less warm, and Oracle's investments more focused on its own needs rather than those of the wider platform.
Despite Oracle, there is no reason to be gloomy about Java's future. There is another way to look at the move of the JRuby team, which is that they've found a way to continue working on the project with or without Oracle's support. Java is bigger than Oracle, just as it was bigger than Sun.
IBM worked tirelessly to free Java as far as possible from Sun's control, developing its own JVM and creating the Eclipse tools project to foster alternative tools and frameworks. Those efforts will have a new context and relevance.
Maybe Oracle will do great things for the Java platform. Maybe it will do little, and momentum will shift to those outside the home company. Either way, investment in Java development is as safe as anything can be in our uncertain industry.