On Wed, 8 Jun 2005 06:48:24 -0700, Shel Belinkoff wrote: > Do closely held and "undocumented" proprietary formats constrain > creativity and innovation, or is that just a smoke screen?
<RANT> It's usually a smoke screen. It's only constraining in that it makes them do something they are loathe to do for reasons that are usually shortsighted. One example would be that they'd have to plan ahead more than a couple of financial reporting cycles, and invest a (comparatively small) amount in building decent generalized processes and tools up front. Instead, their three- to six-month "future of interest" makes them think it's cheaper and faster to hack together something specific to the product du jour. Ironically, this often ends up requiring more resources over the long run than doing it "right" up front and adapting those up-front work products would have required. Take the TIFF standard as a counter example to the current myriad RAW formats. TIFF did a pretty good job of anticipating future needs directly (check out the PhotometricInterpretation and related tags), and a better than usual job of being extensible in ways that wouldn't break older systems. But it requires a lot of up front thought, the effort to build a generic toolkit, and everyone sticking to the standard. Those are all things that many technology companies are loathe to do, or incapable or uninterested in doing, or something. It don't get done very often, and when it does, it's often due to pushing from the user base. Sometimes, they think they're going to lock you into their stuff by making things proprietary. The open source 'dcraw' and Samba, and the multitude of malware (viruses, trojans, worms, etc.) out there, are perfect counter examples: none would exist if developers couldn't reverse engineer those closed, proprietary systems. Sometimes they're just being stupidly short sighted. </RANT> Sometimes, though, they never expected the stupid Thing (whatever it is) to carry on this long. So they didn't see any return in making an investment in doing it the right way for a product line or family. So they did it as a one off, throwaway effort. That can come back to haunt you in very difficult to manage ways. How many large-craniumed computer engineers of 1980 would have foreseen that 25 years later we'd still be maintaining instruction- and register-level compatibility with the microprocessors they were developing then? TTYL, DougF KG4LMZ
