Is Standardisation Worth the Hassle?
In an area of fast moving technology one must ask the question “Is standardisation too long-winded a process to cope with rapid evolution”. Current standardisation processes typically cause review of a standard about every five years with implementation of the revised and updated standard about five years later. This often spills over to be far longer, so that the cycle can be ten to twelve years – by which time the standard is once more out of date. I am not just thinking about software here, but the whole gamut of standardisation. Of course software is notorious for its language wars and delayed releases.
Is there an alternative? In many cases, not. In some cases processes get hijacked, in many cases it is impossible to get along without the participation – and agreement to the draft – of one or more “majors” who may or may not have their own vested interests. To be fair most majors understand the need for expediency and are as keen to see things move ahead as anyone else. The open source community has long militated for the adoption of de facto standards through the community process in which a very wide range of interested parties come together in order to write, evolve and ultimately give their seal of approval to, a “standard by adoption”. The result is then maintained and evolved by that same community. The evidence shows that, in certain circumstances, this can at least offer an alternative.
Does it offer the only viable alternative? In the last few weeks we have seen initiatives such as OpenCL from the Khronos Group, aimed at accelerating HPC systems and with an impressive list of backers from Apple to Umea University, via Ericsson, Freescale, NVIDIA and IBM to note a not insignificant handful of players (http://www.khronos.org/news/press/releases/khronos_launches_heterogeneous_computing_initiative). However, is this more than a group of companies watching the market? Is such a grouping of sufficient weight that it could actually get together to drive the market forward by declaring a series of de facto standards? This is a similar model to the standards adoption in areas such as mobile telecoms where a group of industrial giants get together in order to put in place a standard approach in an area. Those who doubt that this can be made to work are invited to look at the 3G standards,for example, which together comprise several dozen documents; similar approaches have worked in other areas, for example in definition of security standards.
It is what we might call an “engineering” approach. By way of analogy, think of the Porsche 911. Initially a dynamically unpromising car with a back end that could be made to step out like a pendulum particularly on sharp, wet corners. Yet over a number of years a series of repeated engineering developments have enabled the questionable dynamics to be almost entirely eliminated.
This approach is very much the approach of the present standards system.
Over the next few years the increase of in core-count will have profound implications for software. It will surely change the way that we approach the whole process of applications design and implementation. I have been looking at a proposed language standard, I shan't say which or what; suffice it to say that it has evolved over a period of time to where it is at present – a monolith profoundly rooted in a long, and it must be said, honourable past. That evolution has broadly followed the public consultation process outlined earlier. Because of its history, there is a huge legacy of applications developed using it. In coming to understand it, it strikes me that, at a time when it should be looking forward, it has more regard for its past than in building a flexible structure capable of absorbing the technological change of the next ten years. If it goes forward to acceptance in its present state it may in effect be signalling its own demise. This is the more serious because of the huge prior investment in code.
In reality legacy code is the problem. With the adoption of a modified standard should come tools to enable the migration to the new version. Unfortunately, particularly in its early days, programmers pulled all sorts of “tricks” to make the language do what they wanted it to because at that stage it was immature and they needed to do things that it didn't properly encompass. Today those programmers have long since left/retired/died and the current “owners” of the code dare not go through the whole rigmarole of re-writing and subsequent validation. In theory translation tools have the potential to save much of this effort, but by and large they don't exist. Because they don't exist, the behemoth is in effect frozen.
At this point I would insert a plea for such tools to be built to take software from one standard to the next – as part of the standard – and to permit users, programmers, applications designers and code-managers the flexibility that they need to use the latest technologies.
My reticence in identifying the particular standard is because this piece is not primarily about an individual standard per se; it is about the broader issue of how we standardise, a process that I admit to be necessary in the face of likely,(if not inevitable) rapid, but poorly understood, change. The stability that has persisted in the microprocessor market for the past thirty-odd years has been reflected in the somewhat glacial processes that we have implemented.
To return to the evolutionary analogy: Many believe that evolution is not a smooth, gradual process but proceeds via a series of “punctuated equilibria” a process which allows for rapid changes to adapt to rapidly changing environments. Perhaps we should be looking to a similar sort of process to permit us enough flexibility to adapt to rapidly changes technological situations.
We need an approach which deals with underlying continual change, but at the same time we need greater flexibility too. Perhaps industrial consortia should be allowed to drive the underlying process, since in situations of rapid technological change such as these, industry alone has the knowledge of where the technologies are going, with input from academia etc. to tell it where they might go next, together with some lightweight approach to building software and tools. Might this latter be best managed by an open-source-like approach?
Do I have a detailed structure in mind? No, but unless we are able to find a way forward then it seems unlikely that we will be able to take full advantage of the technology changes that are heading our way.
End of rant? No, I suspect that it is just the beginning.