And when they are, they take so long to ratify that the industry has moved on. (HTML5 isn't due to be specified until 2014, even though it's been in browsers in some form or other since 2008. And Microsoft will misimplement it anyway, because they always do.)

But all of this is a stupid way to do software. There are smarter ways, and even self-organising smarter ways, with some nominal assured quality. But we're a couple of decades at least from seeing them in general use.

First, people need to get past the geek job hand-coding idea first, get over all the drama associated with project managament, and get past the idea of creating de facto standards for commercial advantage or 'official' standards as an academic exercise.

Another drag on development is Unix/Linux culture's 'Slap it together until it sort-of works, make it public, then go do something else.'

Infrastructure has to be robust, and making software robust is currently too boring for many developers.

Why should the OS that runs on the majority of PC systems be created and controlled by a private profit seeking entity with no meaningful regulation when it can clearly be seen as a critical part of the national infrastructure?

I'm not really thinking of a set of standards, like ASCII, but rather a national institute whose job it is to write a solid, up to date, secure and reliable OS.  Private vendors could make add ons and flavors for the OS, provided they pass some sort of quality inspection.  Perhaps identify a couple of applications that are also critical aspects of the national infrastructure, like email and web interface, and write those as well.  Further, it would make sense to regulate and secure the software that runs the actual physical infrastructure, to make sure it is properly robust and secure from attack.

The mandate of the institute would be to continually update and manage the software infrastructure to keep it reasonable up to date, functional, and secure, in the short and medium and long term.  THis would be backed up by long-term basic research.

The idea would be to take up the various aspects of software development that the private sector does not want to bother with, and put them in the hands of an institution with the mandate and funding to do them properly.  Let the private sector share the benefits, but keep the control and ownership and management in public hands.

Not only would a technology and reliability focused development process benefit consumers, who would no longer be screwed over by private companies seeking their own short term profits, but it would also be possible to start protecting the entire national digital infrastructure from the increasing threat of destructive cyber attacks.  

As you mentioned earlier, most existing software is built on years of legacy code and compatibility, much of which was never intended to be secure from malicious attack.  This is where primary research would come into play - figure out a way to make things inherently secure, so that malicious outside attacks are simply impossible.  Maybe that's a pie in the sky dream, but moving in that direction would seem to be a worthwhile endeavour.

Furthermore, this is the sort of labor and time intensive project that government spending in the future economy really should pick up and focus on.  In the end, all you're really spending money on are a few buildings and a lot of people.

Sepa is supposed to save billions every year but the way forward has been difficult. Every country has its own cavalcade of systems or no real electronic payment system at all. E.g. in Germani there is something called DTAUS to initiate direct debits, which works reasonably well. You send a file to the bank and they pull the money for you as soon they can. Sepa direct debits are another animal entirely. You need a creditor id, issued by the good folks of the Bundesbank, every debitor needs a unique mandate id. Every debitor needs to be prenotified at least x days before any transaction. The changeover to Sepa itself requires notification to the debitor. At first an entirely new agreement (with signature) was required but because of some legal changes the old ones are still valid. Then, depending on whether it's the first or a recurring transaction for that debitor, the file needs to be sent 5 or 2 TARGET/bank days before the actual transaction. If you mess up, the transaction can be rolled back by the debitor for more than a year not just the usual six or eight weeks.

This is painful and potentially disastrous stuff because come February the old system is verboten. Currently, less than 0.2 percent of direct debits are issued using Sepa [in Germany]. Insolvency looms for a lot of people. After a lot of haggling a new intra-German "local instrument type" called COR1 will be introduced in November. Which basically means trying to do something similar to DTAUS in the confines of Sepa: you only need to send the file one TARGET day before the transaction.

Meanwhile, Sepa also introduces the common citizen to the pleasures of the International Bank Account Number (IBAN). It consists of 16 to 30 characters, in most countries it's more than 20 (why do the Palestinians need 29?). Problem: there has only recently been movement towards a somewhat reliable conversion of old account numbers to IBANs. Because some banks have their own special subaccount numbers. And of course every bank has its own implementation of the 'standard' of which there are numerous official versions. This goes on and on and reminds me of the ETCS chaos.

So a lot of blabla. In total: data integration is hard. Standardization is anything but. Standards go one way and reality goes another way. If a standard finally becomes workable it's also close to irrelevance.

This is the kind of infrastructure that necessarily involves government because a lot of law making is involved. But government should not be counted upon to deliver the technical side of it. It is unsafe to regard yourself as the only reliable player.

_{Schengen is toast!}