What happened? Between 1989 and 2003, someone at Microsoft decided that it was not worthwhile to support the 1989 file format. After all, there are costs to supporting multiple platforms, or operating systems, or web browsers. For every previous version of an application, browser, or operating system that you support, you increase the planning time, coding time, testing time, and several other costly times.
But what if you just freeze the format?
Some of you are laughing now. So we'd use a web browser that doesn't support modern security strategies? Or use synth sounds that date from 1991?
Well, when Dave Winer shared Peter N. M. Hansteen's post, he offered a comment on compatibility:
We still get a lot of interop with the OPML format, designed in 2000, 17 years ago. And RSS 2.0 was frozen in 2002, 15 years go. Still going strong. So if interop is a priority and you are a hardass about it, as I am, you can have it for a long time.
So it looks like you have two choices - either evolve your offering and break things, or keep your offering static with no innovation.
Let me propose a third ground - controlled obsolescence, for lack of a better term.
I have frequently talked about the ANSI/NIST-ITL standard for exchanging biometric data. This standard has been around in one form or another for a very long time - in fact, the first version (1986) came out before the National Institute of Standards and Technology even existed. (It was the National Bureau of Standards in those days.) Since that time, new versions have come out every few years. As I write this, the current version of the standard is ANSI/ NIST-ITL 1-2011:Update 2015.
There have been a lot of changes between 1986 and 2015.
A lot.
Most of these changes have been additions of functionality. Back in 1986, the standard had no way to support irises or DNA; today those types of data can be exchanged. Other additions have been in format; back in 1986, there was no way to change data via the use of XML; now you can.
But some of these changes have been SUBTRACTIONS of functionality. If you look at Table 3 in the aforementioned 2015 update of the 2011 standard, you'll see a listing of all of the record "types" that are supported by the 2015 update...and some that aren't.
Yup, that's right. If you have some software that generates a NIST record in accordance with the 1993 version of the standard, and that NIST record has Type 3 data, or Type 5 data, or Type 6 data...and if you then send that NIST record to some software that supports the 2015 update to the 2011 standard...THE NEW SOFTWARE WON'T BE ABLE TO READ IT.
So why doesn't the Peter N. M. Hansteen of the biometric world complain about the time that he found a low-resolution binary grayscale record, or a low-resolution or high-resolution (500 pixels per inch!) binary image record, and his new software wasn't able to read it?
Because the Peter N. M. Hansteens of the biometric world actually had a say in deprecating Type-3, Type-5, and Type-6 records.
When someone at Microsoft decided that the 2003 version of Microsoft Word didn't need to open 1989 files, that was that. Microsoft didn't poll all of its customers to see if they were OK with removing 1989 compatibility.
The evolution of the biometric standards is a bit different. If you look at any of the ANSI/NIST-ITL standards, you can see a list of people who were consulted regarding changes to the standard, and the organizations that they represented.
For the 2015 update, dozens of people were contacted - not just in NIST, and not just with the biometric vendors, but with a number of agencies that depended upon the standard. Jeffrey Carlyle of the FBI was consulted. Charles Schaeffer of the Florida Department of Law Enforcement (FDLE) was consulted. Mark Labonte of the Royal Canadian Mounted Police was consulted. So all of these people, including vendor representatives such as Peter Lo and John Dowden, were all very aware of what was in the standard, and what had been taken out.
In fact, some of these same people were around in 2011 when Types 3, 5, and 6 were yanked from the standard. I have no idea what the internal discussions were like, but my guess is that all of these people were in agreement that these three types were not needed any more. I'd be willing to bet that absolutely nobody was sending Type-5 records to FDLE in 2011.
So here's the question - how often can people execute this balancing act between keeping standard compatibility while still advancing the standard? And how often can the stakeholders reach agreement on controlled obsolescence?
