Do standards hold us back? Its a good question to ask ourselves as
people who work with technology, should we be always looking to
innovate?
First of all are all standards bad and the answer is a big no. Doing
things in a centralized fashion is great for things like the dbus and gstreamer but what about for things
like OOXML
that was made an iso standard even though there is no completely
standard compliment implementation not even from Microsoft themselves.
Standards can be great but it really depends on who makes them.
Application developers who make services for the desktop like Zeitgeist
and Tracker innovate. They dont need to worry about communication
because they use the dbus to pass info and have a well documented way of
formatting the info passed. So innovative projects use standards but the
programs shouldnt push things like how Microsoft pushed OOXML, they
change things release on release and try to keep things stable and well
documented but it doesnt stop the innovation.
So the problem with standardization in software projects is exactly what
happened to OOXML. A bunch of people sat around a table and wrote a
document that was rejected as a standard then they made some changes and
it was accepted (quite ridiculously). While they should have been
already developing it (maybe not releasing it but working on it) because
developing it works out the kinks. There is lots of pages to the
standard but some of it will never see the light of day and why because
it wasnt developed in the correct manner. They should have developed the
standard in house then presented it as a standard.
How can you expect anyone else to develop a standards compliant
application if the developers of the standard cant even do it? How do
you expect to develop a standard without testing it? Whats wrong with
innovation as a means to develop a future standard?
You develop standards through innovation not by committee.
Standards, according with WTO methodology, are created around policy (among others) that states that no standard shall endanger invention. The problem is that we tend to name all sorts of guidelines as “standards” and there lies the problem.
Your missing some vital details in your take on OOXML which render it unsuitable for your analogy. I don’t know if I can do it justice but here’s a short precis:
* Office has a de-facto file format standard (.doc, .xls etc.)
* It’s an ugly, complex, buggy, carbuncled thing with security and privacy issues
* Plus it’s owned by the monopolist that controls the Office suit and the OS market and needs to be reverse-engineered by competitors
* Governments know that kind of lock-in is bad so they want an open standard and multiple vendors competing
* ODF is produced with XML and various buzzwords. It’s not perfect, but it’s a good start on this task
* Microsoft are fearful of being locked out by legislation that requires an open format
* They produce an “open format”, which mostly involves dumping the ugliness of the previous format out to text and throwing in some angle brackets and having it passed by their pet standards org, ECMA, which actually boasts to customers that they will approve the text with minimal interference compared with real standards bodies.
* Their key mantra is “backwards-compatibility” i.e “don’t destroy our lock-in please”
* ODF has now been blessed by ISO, this means governments can just say “we need an ISO standard file format” in their legislation, which means they avoid the tricky political act of saying “no, thank you” to Microsoft.
* Microsoft produce an ISO standard, which involves having all their bugs, workarounds and private formats that have already been passed over in favour of alternative standards, rubber stamped by ISO. As it has already been standardized by ECMA, it is foolishly assumed to be fairly solid and gets “fast-tracked”.
* Microsoft got lots of the details wrong while documenting their own hideous file format, plus various governments demanded that they fix the most egregious bugs (like rounding code should actually round correctly even if that’s not “backwards compatible” etc.)
* Microsoft “fixes” both these problems, not by changing Office itself but by altering the standard in a process designed for typos, changing anything which they find conflicts with Office, and if a fix for an actual bug was demanded by a government, make that fix part of the “strict” standard, and also allow the old behaviour as part of the “transitional” standard.
So yes OOXML is a bad standard, but it’s nothing to do with design-by-commitee or not having running code to check against. Quite the opposite.
OOXML is still decent. In my opinion, standards are excellent and help significantly down the road. The trick is doing things in the correct order.
Review
1) Build your specs
2) Build your expected standards
3) Build something that uses them as thoroughly as possible
4) Revise
5) Test
6) Revise
7) Test
9) Revise
10) Test
11) Review
12) Release
How many revisions do you think Jabber/XMPP went through before being released? There are a lot of excellent open standards out there and there must be a reason they’re successful.
OOXML is an example of somebody releasing an open standard without any clue how to make something open.
Reminds me of how TrueCrypt isn’t even “free” although they claim to be FOSS… Oh well.