Submitted by California has introduced a bill to make open document format a mandatory requirement for agencies when acquiring software, turning up the heat on Microsoft. The bill follows similar legislation in Texas and Minnesota and adds further to the pressure on Microsoft which is pushing its own proprietary Office Open XML document format in the recently released Office 2007.
Yes, this is how must be, the software must acomplish the standars required by the goverment who isn’t pushing MS Office away is just telling them what they need to do and letting the user pick the option they need.
…that Microsoft begins receiving pressure to stop trying to set the standard that we’re to live by – it’s own standard, that is. It’s enough that we’re charged high dollar an operating system(s) that we never really come to owning completely, selling an office suite that releases documents in formats of its own that don’t play well with others. Large corporations, government entities, and end-users alike should be able to create, openly use and edit, and transfer documents amongst themselves in a synergystic manner that will only come from cross-compatibility between like programs developed by whomever. I’m happy to see this.
This is much like cell phones that we never truly ‘own’. We can’t transfer them to another carrier – we have to buy another phone. They don’t build “time counters” into them to afford us easy visual access to how many minutes we’ve used – though this is something easily afforded, nor are we allowed blue tooth connection to other devices like computers, printers, or other things that would allow for better compatibility and ease the transfer of the large amounts of information that these portable, and increasingly, important devices we purchase for personal and business use.
Eis.
About the phones has to be only in the US. Here (Finland) it is easy to change carrier and have the “time counters” working. But otherwise right on about the documents.
Because as we all know, governments always know what is best for computer users. Legislators are well known for their impeccable understanding of rapidly-changing computer technologies, and their laws never have negative consequences.
Your point would be valid if it wasn’t completely wrong. This legislation is the government dictating to itself what software it should use. It’s no different* from all the legislation passed in the 1990s that dictated MS Word should be the standard for government agencies.
Such dictates tend to have a ripple effect, in that big agencies standardizing on a piece of software causes all the contractors for that agency to standardize on it, and all the companies that do business with those contractors, etc, but basically they’re internal IT policy.
*) Actually, it’s better, since this time they’re dictating an open format instead of a proprietary one.
**) I’ve always wondered how much money Microsoft paid out to get voted the standard instead of WordPerfect or Lotus. When the switch-over happened in the early-mid 1990s, WordPerfect still probably had a larger market share.
Edited 2007-03-05 17:27
Meh, I doubt that the move to Office alone was due to a little briby-briby, cash under table; when you look at what was on offer, a consistant integrated office suite vs. 4 seperate applications that couldn’t even talk let alone integrate with each other, it was a simple decision.
What they did do wrong was mandating that Word alone should be the software of choice; they should have mandated that an open file format was created and that all those companies going for contracts with the US government must support those said formats out of the box, natively and by default.
I’m not implying cash under the table. To my knowledge, Microsoft hasn’t bribed anybody. What I’m implying is campaign contributions, and its well known that Microsoft (along with everyone else) contributes heavily to politicians and their organizations.
The interesting thing is that the standardization, at the time, wasn’t around “Office”, but around Word specifically. The government generates, and exchanges, an enormous number of word-processed documents. The number of spreadsheets exchanged is insignificant in comparison. At the time, I’m pretty sure WordPerfect had the bigger installed base, and it surely had the biggest stock of existing documents (like Word does now). Even today, the standardization of Word is the one that keeps Office locked in the government. Without it, Office’s lock-in wouldn’t exist at all.
Now, it could’ve just been some extremely keen and prescient decision making on the part of the government (hah!), or, more likely, Microsoft contributed to the proper campaigns and offered sweet-heart pricing. The latter certainly better-fits the behavior that characterized Microsoft’s dealings through the 1990s…
Edited 2007-03-05 23:37
I’m not implying cash under the table. To my knowledge, Microsoft hasn’t bribed anybody. What I’m implying is campaign contributions, and its well known that Microsoft (along with everyone else) contributes heavily to politicians and their organizations.
I never said that you said it, but for me, campaign contributions are equal to bribery; no one contributes to a party out of the goodness of their own heart and wanting to ‘help the democratic process’ – people contribute money because they want to get something out of it.
That sort of ‘bribery’ is no different to, for example, a state who offers tax breaks for companies to setup in their area; all sides win, the state wins with more jobs which stimulates the economy, the business benefits through lower costs and the policians benefit because they remain in power off the back of ‘good economic management’.
The interesting thing is that the standardization, at the time, wasn’t around “Office”, but around Word specifically. The government generates, and exchanges, an enormous number of word-processed documents. The number of spreadsheets exchanged is insignificant in comparison. At the time, I’m pretty sure WordPerfect had the bigger installed base, and it surely had the biggest stock of existing documents (like Word does now). Even today, the standardization of Word is the one that keeps Office locked in the government. Without it, Office’s lock-in wouldn’t exist at all.
I remember when the New Zealand government had a combination of WordStar 2000 and Wordperfect Suite, but standardised the whole public sector on Microsoft Word – the simple fact is, by the time they made the decision, Wordstar and Wordperfect were still DOS based applications – it was completely unacceptable to expect customers to remain with DOS when IT had already moved along to graphical interfaces.
Add to the fact that non of the UNIX vendors were willing to step up and actually offer an alternative to Windows – what choice did the government have at the time?
Now, it could’ve just been some extremely keen and prescient decision making on the part of the government (hah!), or, more likely, Microsoft contributed to the proper campaigns and offered sweet-heart pricing. The latter certainly better-fits the behavior that characterized Microsoft’s dealings through the 1990s…
Nothing ever stopped the UNIX vendors from offering sweet heart deals – the UNIX vendor simply sat back, fought with each other and laid claim that people will be willing to pay the exorbinant premium over Windows simply for the privilage of running UNIX – going by their dramatic drop in marketshare, they learned the hard way.
Edited 2007-03-06 00:20
I wasn’t talking about UNIX, but rather WordPerfect. Even at that point, DOS had long been the dominant desktop platform, and Windows was starting to gain traction. UNIX was more or less not even under consideration by then.
And yes, nothing stopped WordPerfect from offering sweet-heart deals to government IT, but I’m opposed to the whole idea of sweet-heart deals. It’s an insidious form of bribery when applied to the government, because for the relatively small cost of giving a discount to a few customers, you can have a huge impact on a large number of other customers. Put another way, if I’m a contractor for the government, I don’t want to have to use a product just because the government IT folks got a good deal on it, especially considering I’m not getting any such deal!
I wasn’t talking about UNIX, but rather WordPerfect. Even at that point, DOS had long been the dominant desktop platform, and Windows was starting to gain traction. UNIX was more or less not even under consideration by then.
The primary reason for Word was because it ran on Windows, Wordperfect didn’t. People wanted a graphical word processor, they saw that since Word was graphical it was there fore superior to Wordperfect running in DOS.
Why did I bring up UNIX? because Wordperfect was already graphical on UNIX via Motif – nothing ever stopped the big name vendors like Sun offering deep discounts on their SPARC based workstations, coupled it with a free copy of Solaris with all the trimmings, and worked with Wordperfect on a sweet heart deal to win over the people in the public sector.
And yes, nothing stopped WordPerfect from offering sweet-heart deals to government IT, but I’m opposed to the whole idea of sweet-heart deals. It’s an insidious form of bribery when applied to the government, because for the relatively small cost of giving a discount to a few customers, you can have a huge impact on a large number of other customers. Put another way, if I’m a contractor for the government, I don’t want to have to use a product just because the government IT folks got a good deal on it, especially considering I’m not getting any such deal!
And what is wrong with sweet heart deals? its good old fashioned business; you win customers, and if it means deeply cutting costs, then so be it.
If you’re not getting a discount, could be because you’re not negotiating hard enough? that you’re only a small player, so there fore, Microsoft or what ever company isn’t exactly going to bend over backwards for you?
Sorry, its the big bad world of dog eat dog – too bad businesses like Sun fail to grasp at details like that, and as a result, never get their office suite beyond the ‘demo’ when pitching to clients willing to migrate off Microsoft.
Your comment is laughable, since with MS Office file formats, there is no *choice* – i.e. it’s MS that is dictating what’s best for computer users.
The only thing the CA, Texas, Minnesota, and Mass. govs are trying to do is establish a standard that is non-proprietary, not completely controlled by a single entity, and based completely on an open standard that is defined by both the community and vendors alike.
This ensures *choice*, so that computer users can choose what is best for them, not MS, not the government, not anybody. It also ensures that government documents are always accessible via a variety of both commercial and open source programs – introducing true, *cough*, competition, and will never be at the mercy of (or paid licensing to) a single corporation.
Standardizing on ODF has zero downside (unless you’re an ignorant MS shill), and has all upside.
Viva open standards and true competition!
And down with lock-in and forced upgrades.
No downsides?? How about that it is not completely specified in any product on the market? Application behaviors are not completely defined in the spec and Formulae for spreadsheets will not be finished until later this year. Also, so much of the spec’s worth relies on the fact that you can look at teh source code of a reference implementation. Unfortunately OO.o and KOffice both seem to be GPLish applications, so you can’t actually legally immplement a closed source app by looking at that code (you could be accused of copyright infringement).
ODT is a reinvention of the wheel and it may not even be entirely ready for primetime. The trick that the ODF folks have pulled is that they’ve standardized the OO.o internal format and now want to mandate it as the only official way to make documents. This would make sense if it were a situation where one standard actually interferes with the other one (i.e. if having a docx version of your file with an odt on the same drive somehow causes one to become corrupted), but in the case of docfile formats, this is rather ludicrous so both standards should be allowed.
Almafeta is being sarcastic, or at least I hope he is.
It’s not like they’re trying to stop people from using MS Office, it’s only a matter of Microsoft adding a *working* implementation of ODF in the Office product and then we’ll have an even field for all the players and the market will decide the winner not on its file format monopoly factor but on other merits. Microsoft just doesn’t want to compete fairly.
It’s not like they’re trying to stop people from using MS Office, it’s only a matter of Microsoft adding a *working* implementation of ODF in the Office product and then we’ll have an even field for all the players and the market will decide the winner not on its file format monopoly factor but on other merits. Microsoft just doesn’t want to compete fairly.
And if Microsoft doesn’t step up and produce a decent ODF import/export – then who cares? there are plenty of office suites both now and into the future that will quite frankly wipe the floor with Office.
The next Wordperfect Suite from Corel is going to be supporting ODF out of the box, Lotus Notes 8.0 which apparently will be released in the second half of 2007 will have a complete productivity and collaboration suite – and if it is anything like their original notes price, retail pricing alone they’re 1/4 the price of Microsoft Office retail.
Then add to the mix StarOffice from Sun, which has a side note, if Sun sold a pizza box sized computer around the size of the old SGI Indy, bundled Solaris, an up to date version of GNOME plus StarOffice – it would be a great combo for large enterprise users and the public sector.
One thing Microsofts competitors do need to learn is how to be agressive when it comes to pushing their products – if you sit back being too timid, is it anyone elses fault if Microsoft constantly wins contracts around the world? they need to march in there, tell the customer, what ever Microsoft is offering, they’ll halve it and throw in more stuff to boot. So you make a loss of that sale; once you’ve made a few sales, get a reputation and earn, “you never got fired purchasing from [company]”, future sales will fall into place.
Edited 2007-03-05 21:43
…I have not found one post or article that compares the technical merits of ODF vs. Office XML.
Which format used appears to be a completely politically driven decision in these cases. Both formats are equally applicable and open, they just have different origins.
I hate it when decisions are made without regards to the technical merits of the solution. It’s the reason Linux butchered the RTOS market.
I have not found one post or article that compares the technical merits of ODF vs. Office XML.
None of these comments, or the article mention it, but there have been many articles, opinions, and even factual information showing that Office XML cannot become a recognizable standard, mostly due to MS-specific/proprietary information referenced in the “standard”. It doesn’t help that Microsoft has attempted to fast-track the standardization of their OOXML in what appears to be an attempt to avoid the criticism and proper review of their format.
But anyway, it looks like there’s some good detail on the pros and cons of both formats here:
http://en.wikipedia.org/wiki/Comparison_of_OpenDocument_and_Office_…
I am looking at the Open XML examples, and it’s not very human-readable at all, and I consider human-readability one of the upsides of an XML-based format.
Why doesn’t Microsoft make Open XML more readable? Call me an anti-MS conspiracy theorist, but the only reason I can fathom is they want “Open” XML as difficult as possible to understand in order to somehow make it more proprietary’ish. If compressed, the sizes of the same document saved in ODF and Open XML will be around the same, regardless of tag legnth.
No one is going to edit their docs in xml form. The tags are short because shorter tags parse slightly faster and give better performance when opening files. When you’re writing an import filter for OOXML, you’d probably put those tag names into #defines or some other string constants.
If the names of the tags are a roadblock to you implementing an OOXML filter, then you’ll run into many more problems further down the line.
http://www.grokdoc.net/index.php/EOOXML_objections
Here you’ll find quite a few technical and legal points in favor of ODF, as well as plenty of relevant links to critique and comparisons.
…I have not found one post or article that compares the technical merits of ODF vs. Office XML.
Not even one? Then how about many? This blog repeatedly compares ODF to OOXML. And it doesn’t look good for OOXML.
http://www.robweir.com/blog/
That blog is written by an IBM employee who is a bit of a director of attacks against OOXML. You’ll notice that you’ll find no one at Microsoft saying that ODF shouldn’t have been made a standard. You will find people saying that certain things this Rob Weir says about OOXML are the same or worse on the ODF side. Weir on the other hand is merely an attack dog… he has nothing good to say about the other side whatsoever and has some pretty obvious self-interests in seeing OOXML fail regardless of its technical merits.
Er… What technical merits? Seriously though, I never said the blog was balanced, in fact I said just the opposite. But nevertheless, it compares them repeatedly.
As for my POV, the blog notes that OOXML contains statements like “you need to reverse engineer that other application to comply with this standard, because we won’t disclose the details”.
If that’s true, then it’s enough to show OOXML as a silly standard, in my book.
If you note some blogs from the other side, or if you look at the specs themselves, they say that those 3-4 tags (there are definitely less than 10) are there only for achieving perfect display reproduction of extremely old documents. You can safely ignore them (modulo, of course, docs not looking precisely the same) and modern implementations are not meant to output them.
The equivalent sorts of settings in ODF (which control display and rendering characteristics) are put into app-defined configuration sections that are completely outside of the standard, so you have no hope of decoding them without reading the OOo source or spending a long time reverse engineering OOo. And other implementations might choose other methods of storing these settings.
The summary says, “Microsoft which is pushing its own proprietary Office Open XML document format in the recently released Office 2007.”
But OOXML is not “proprietary”. It is an open standard owned by ECMA.
According to the California bill, “open” is defined as
1. Interoperable among diverse internal and external platforms and applications
2. Fully published and available royalty-free
3. Implemnted by multiple vendors
4. Controlled by an open industry organization with a well-defined inclusive process for evolution of the standard
OOXML satisfies those just as well as does ODF.
Now, the problem with governments mandating ODF (as opposed to merely mandating “open xml formats” like the CA bill does), is that such a mandate codifies into stone the functionality of OO.o, leaving no incentive to go beyond that functionality, and indeed providing a disincentive to to so. But this is the entire ODF strategy: MSO competitors can’t compete with MSO on features, so make MSO’s extra features irrelevant by law. Then OO.o and the like can compete on “it’s free!!!” and nobody can do anything about it because competing on features is no longer possible. Well, that’s the strategy, anyway. MS still has OO.o beat wrt UI and enterprise solutions.
Edited 2007-03-05 19:18
Just out of curiousity, how is OOXML fully implemented by multiple vendors? I’m only aware of Microsofts own implementation for Office 2007 (go figure) and the halfbaked OOXML conversion plugin from Novell for OpenOffice.
Yes, some vendors like Corel have announced that they will support OOXML in upcommoing releases, but I can’t see that happening immediatly (given, that OOXML won’t reach official ISO certification for the next months due to the roadmap)
Furthermore, I see several problems and showstoppers for the “interopability among diverse internal and external platforms and applications” section, since for example available and well established multi-platform recomodations/standards like SVG and MathML have been not adopted by ECMA during the standardisation process. Instead, we have again a set of “MS own standards” that are embedded into OOXML.
Edited 2007-03-05 20:07
What’s the point?? SVG and MathML likely didn’t fit the needs of Office for whatever reason. Likely reason for SVG failing is that it is more complicated to implement properly than DrawingML (check out Miguel de Icaza’s subsection on SVG: http://tirania.org/blog/archive/2007/Jan-30.html).
MathML maybe is a bit harder to justify not using directly, but there is of course a reason for this: http://blogs.msdn.com/brian_jones/archive/2006/10/12/comparison-of-….
Likely reason for SVG failing is that it is more complicated to implement properly than DrawingML (check out Miguel de Icaza’s subsection on SVG: http://tirania.org/blog/archive/2007/Jan-30.html).
Perhaps I’m too stupid, but I have to disagree with Miguel de Icaza here. While it is true that there is no complete FOSS implementation of SVG 1.1, Batik and Inkscape (recently added filters capability with the introduction of the gaussian blur filter) have made nice progresses so far and I have – besides the old flowing text issue, which will be resolved with the arrival of the SVG 1.2 specification – yet to run into a problem with both implementations for static content.
In fact, SVG is the only format (besides EPS, but which is not so nice for editing) to pass content between vector drawing applications like inkscape and (for my colleauges) Adobe Illustrator and my rusty plotting programs (xmgrace and gnuplot via pstoedit).
As of DrawingML, are you aware that this is only one way of doing things in OOXML land? OOXML uses VML in many places and although this is labeled as “legacy behaviour”, a full implementation would have to duplicate the efforts and provide hooks to VML in order to fully interoperate with existing documents. VML is not a piece of cake to implement either and actually predates SVG directly.
Could you please provide pointers towards complete (or at least competative) FOSS licensed DrawingML implementations? I was not able to find one googling, thanks in advance.
As of MathML if I understand the content of your reference correctly, they (=MS) have an ugly hack for the formula representation in their legacy formats and try to keep this hack alive. Supporting this legacy behaviour by providing namespace extensions and introduce a proven, feature rich, cross-platform available standard natively for all future created documents would have been a more sensible approach for my taste, but I guess I have a different philosophy.
But that explains why virtually nobody in my field (particle physics) uses the MS formula editor. (I attended a conference last week and of the about 40 seminar and lecture talks given, only two were made with Powerpoint and used formulas rendered to pictures rather than the native MS formula implementation. The huge majority used LaTeX in connection with Beamer, Prosper and the likes)
I’m aware that ODF has suboptimal support for SVG and SIML too. But at least they have followed the (imho) right direction by starting to use the format that nearly everybody and his aunt Hettie supports now at least partially (and will support definitly better in the near future)
Regards
Edited 2007-03-06 08:59
You missed the one important reason why MathML did not work. Sure, the new equation language is nearly the same as the older RTF engine equation system, but also MathML has no support for inline items from paragraphs. The whole point is that MathML is geared more exclusively towards math than OPML is. OPML can support math nearly (not quite) as well as MathML, but can also support arbitrary objects within the math.
Also, you’ve probably not seen much Word Math in Particle Physics because the Microsoft Equation Editor (which was a component actually produced by Design Science Inc.) was really not that great. If you are familiar with TeX, it’s simply not an alternative. The entirely rewritten math engine for Word 2007 is far better. I must admit that it is not supremely stable. It may improve in service packs, one hopes. The main improvement with this new engine is that you can type in a very tex-like syntax and it will dynamically build up the equation as you go. It works quite well and it is far better than the edit-compile-tweak-compile cycle I was subjected to with TeX (I’m sure there are tools that make this better).
Check out this document for the syntax: http://www.unicode.org/notes/tn28/UTN28-PlainTextMath-v2.pdf.
Try the new Word equations… you’ll probably be decently happy with it, though it might not feel as good to you if you have an instant-feedback TeX-based system.
I will try to word it very carefully, because the reasons for my objection towards a model that allows the inclusion of (nearly) arbitrary elements into formulas is a subtle one that has to do with definitions.
Call me old fashioned, but for me, a formula is a representation of a mathematical expression with a (usally) very limited set of symbols. The AMS math symbols are sufficiant for most operations, but if one wants to be generous, lets include the various unicode symbolic fonts here too[1].
So (at least to me) formulas are a concatination of symbols from a limited set of characters.
The moment I include graphics into my formulas is the moment where I do expect the “formula engine” to step aside and hand things over to the part employed with the handling of (scaleable vector) graphics.
And I’m no puritist in this matters, I use graphs to simplify formulas all the time. But I (and after a short, informal and definitly nonrepresentative poll: my colleauges too) prefer to treat such objects more like graphics with embedded formulas, because there is a multitude of operations I perhaps want to do with my graphical elements in my formulas (rotate them, align them in a strange way, mirror them, scale them differently, group them, apply filters on them, etc. … ) that is neither necessary nor desired for the other, “native” inhabitants of the formula-character space.
EDIT: Note that LaTeX for example allows to apply many of this “special” operations to the symbols in a formula. But this thing (rotate individual symbols, etc.) are hidden behind pretty advanced commands because they are in 90%+ of the cases simply not necessary to have.
To make it short: There is a reason why Feynman graphs are called Feynman graps and not Feynman formulas or Feynman equations (besides confusing the graphs with probably already existing concepts, of course).
So to me, it is kind of a hack when one introduces graphic capabilities natively to a formula representation and consequently uses this as an excuse to not use the standard xml dialect, when it is
– obviously possible to do a XSLT transformation of the formulas (from your reference), so why not do this transformation on the fly in the background for the formulas that need them?
– There are proven ways to translate and/or embedd MathML into SVG (yeah, that one again) graphics and use the (imho) appropiate tools to handle graphic enriched formulas.
I can see, that this is a matter of personal taste, so if you have a different opinion and the new formula editor environment is a workable environment for you, then I congratulate you and hope you are productive.
But I doubt many physicists or mathematics, chemisists etc. that use LaTeX currently will switch over to the new formula representation until
– it runs natively on their OS of choice (hint: that is most of the times not one from MS)
– is at least as portable and stable as TeX/LaTeX (that will be really hard, given LaTeX s 20 years+ track record and the hardening that happened during this time)
– is as accepted for puplications and exchange as LaTeX (while many journals currently accept MS doc, LaTeX is accepted for virtually every publication, so again: try harder)
– gives results that look at least as good as the ones from LaTeX (probably the thing that is most difficult to achieve)
– is as convenient and flexible to use (this one deserves a little explaination, I know)
The “do productive work” : “wait for the compilation to finish and search for the error” ratio tends to become very large and thus favourable if one has gained some experience with LaTeX (typically writing 20 pages with many formulas on them or so. Expierience in MathML and even XHTML can lower this treshhold). I currently finish my diploma thesis and I hardly recompile what I write until I have finished about 1-2 pages to look if everything is Ok. Most colleauges of mine (and increasingly me too) have included the compilation process into their workflow and use this short interuptions for a tiny break, do some finger gymnastic, have a little chat, drink some coffee, etc.
Note, that finding errors requires some experience too (thats where exposure to concepts like XHTML comes in handy) but I have found the old outcomment-and-bisection error tracking model to be
absolutly sufficiant for the harder to spot errors. And for those with a more traditional work flow, there is still LyX and Scientific Workplace (the latter for MS Windows).
Regards
[1]EDIT2: MathML can do Unicode symbols too –>
http://www.w3.org/TR/MathML2/chapter6.html#chars.unicodechars
just for the sake of clarity
Edited 2007-03-07 08:42
OOXML satisfies those just as well as does ODF.
At some point it becomes a matter of semantics. To combat an open standard, Microsoft released their own open standard that is overly complex enough to make implementation difficult. The spec is 6,000 pages long, and contains references to settings for previous versions of Office. There are arguments over whether Microsoft’s use of container elements for non-standard and/or Windows-specific technologies will be transportable to non-Windows platforms, and then there are the MS Office specific aspects (such as macros) that are not part of the spec, which still gives MS to leverage Office lockin for an open spec.
Even Microsoft’s own Mac group was sufficiently overwhelmed at the prospect of porting openXML functionality for Mac Office, figuring it would take a significant number of manyears to implement. They’ll just be porting over the functionality from Windows itself, there will still be a delay before Mac users themselves get functionality but at least they have the option of using the core Microsoft code. Other organizations don’t.
Worst case scenario is that third-party organizations will be forced to settle for a subset of openXML implementation, which will likely result in fractured portability among applications. Except of course for Office, which supports the entire spec and then some.
Microsoft is essentially doing the bare requirement to meet the requirements of an open specification, and some would argue that they may not even be doing that. The point of a standards body should not be to rubber stamp a spec just because it is documented, it should be evaluated on it’s actually ability to be implemented in a non-partisan manner. OpenDoc for all it’s warts, has at least met that requirement. OpenXML has yet to.
Agencies and organizations are smart to look at long term prospectives rather than just treating ECMA standardization as a check box on a requirements list, otherwise there’s little point to adopting standards.
If openXML can be proven to be implementable with proven interoperability on a variety of disparate platforms and applications, then I’d be the first to agree that it deserves valid consideration. I’m just not convinced yet, it’s far too new a standard.
This keeps turning into an everyone vs. Microsoft argument, when it’s not, that just distracts from the core issue, and that is ensuring a baseline for document compatibility free from undue vendor interference. Private organizations are free to make their own decisions, public institutions have broader responsibilities. If Microsoft is so technically superior to alternatives (and I won’t necessarily argue that they’re not), then why the hesitation to support the same standards those alternatives do? If they are technically superior, shouldn’t adoption occur anyways on merit?
Microsoft’s stubborn tactics to undermine open formats speaks volumes about the value of format lock-in to closed business models, which underscores the importance of protecting open formats. Open standards versus proprietary is an entirely separate, though not entirely unrelated, argument to free vs. proprietary software. Nothing pre-ordains that proprietary sotware is at an inherent disadvantage compared to free alternatives simply by implementing open, documented standards, unless those proprietary software offerings have no other tangible benefit over free alternatives. In which case the market should be free to decide appropriately. On *merit*.
Microsoft’s stubborn tactics to undermine open formats speaks volumes about the value of format lock-in to closed business models,…
The traditional proprietary software business model is primarily concerned with dominating the connection between the software and the information it produces or consumes. The software itself is merely a means to this end. Proprietary software is difficult and expensive to deliver, maintain, and support. The only economically viable reason to distribute proprietary software in the mass market is to make sure that certain kinds of information require your software to be useful.
Controlling the format and making migration difficult are the easiest ways to make money selling software. In the absence of an exclusive lock-in of some sort, competition drives prices down toward the marginal cost of delivery, which for software is limited to support services. The software is always just a means to the real driver of revenue, whether it be compatibility lock-in of support services.
Microsoft has made selling software look easy by revolutionizing lock-in techniques. But in reality, selling software is hard, and often futile in the mass market. Critics of free software economics often question how to monetize free software. But they don’t understand that in a mass market with interoperable software, you can’t monetize the software, whether it be free or proprietary. If you want to drive significant revenues (i.e. more than ad revenues on your website), then you need to sell services. The software is just some bits you need to give people in order to sell your services.
The only problem with this model is that it encourages software vendors to intentionally make their software hard to use in order to make their services more attractive. That’s why there will always be an advantage to free software over gratis proprietary software. You can intentionally make free software hard to use, but someone else will make it easier to use, and then you won’t be able to sell your services.
Microsoft has built a revenue model where consumers and businesses pay them licensing fees, either directly or indirectly through an OEM, in order to acquire their software products. They don’t offer services for common third-party applications for their platform, and most of the base OS service revenue goes to the OEM. Given this business model and their market position, it’s not surprising that Microsoft chooses to drive revenue through compatibility lock-in instead of through service delivery.
Integrated platform vendors such as Red Hat, Sun, and IBM collect little to no software licensing revenue from their platforms, but provide comprehensive service for their platform, including most common third-party applications. It’s no surprise given their revenue models and market positions that they choose to compete on service delivery and actively lobby for software interoperability.
Edited 2007-03-05 22:36
Controlling the format and making migration difficult are the easiest ways to make money selling software. In the absence of an exclusive lock-in of some sort, competition drives prices down toward the marginal cost of delivery, which for software is limited to support services. The software is always just a means to the real driver of revenue, whether it be compatibility lock-in of support services.
I beg to differ actually – there is a big gap between Microsoft Office 2007 and OpenOffice.org/StarOffice in regards to features so it’ll be feature alone that’ll keep end users to Office rather than vendor lock in by virtue of file format or so-called ‘open standard format’ aka OOXML.
What I’ve said in the past is simply this; there is a diminishing return on software development that is occuring right now – that is why there is a move to subscription models and value added services models – the simple fact is, most software has reached a plateau in the number of features vs. demand.
What do I mean by a plateau? the fact is, how many of the features found in Office 2007 will people find instanatly useful out of the box – for me, Office 2007 is pretty much the peak of Office productivity software; its a great piece of software, but for all intensive purposes, what can they possibly add to it to justify a user paying another $300 or so for an upgrade to the next version.
Hence the reason why there is a version drag between those running old versions of Microsoft software, their happiness to stick with the status quo, and Microsofts attempt to justify to end users as to why they should upgrade – beyond, “we’re going to stop supporting it in a few years time!”.
Same goes for Windows – yes, Windows Vista is a big step forward when you taken into the technological changes compared to Windows XP, but at the same time, given what they’ve introduced in Vista, its going to be almost impossible to justify to end users another upgrade in 2 years time.
Whilst Microsoft is effectively competiting with itself, competition can catch up and offer cheaper alternatives that are as good as Office – although not as feature rich, if it does 90% of what the end user wants, and the remaining 10% is just trivial crap that were only nicities but never really actually core required features for the business, you’ll start to see migration.
So for me, its just a matter of waiting – if opensource keeps moving forward, you’ll eventually see that the feature matrix between commercial and opensource will meet, and opensource will cross over and over take commercial software.
Of course you’ll have commercial software vendors come out of the wood work claiming that they have some sort of voodoo mystical powers that only the ‘power of proprietary software’ can deliver in concert with over the top R&D budgets, but for those of in the know, its all bullcrap.
Software is nothing more than a series of algorithms, and there are only certain ways you can do things; ideas have in many cases been invented over 20 years before, but yet to be implemented – like perpendicular recording for example in hard disks, it has been around for 50 years, but only recently implemented.
Oh, god… Do you even read what you write?
1. Interoperable among diverse internal and external platforms and applications
OOXML does not interoperate among anything other than Microsoft platform and products. It is not even available long enough to the point that competitors could have implemented it on their products. Tell me: how do you open an OOXML file on OO.org or Koffice?
2. Fully published and available royalty-free
That's perhaps the only requirement that OOXML meets but even then I'll reserve my judgement as I've seen people complaining that MS “XML” more often than not has huge blurbs of text instead of binary blurbs, which clearly obfuscates it a lot.
3. Implemnted by multiple vendors
I was speechless after reading this one. Who else besides Microsoft has implemented OOXML?
4. Controlled by an open industry organization with a well-defined inclusive process for evolution of the standard
OOXML, at the moment, is controlled by Microsoft and Microsoft alone. Sure, they are trying to get ISO certification for their format, but even if they get it, I don't think that they will gather enough traction behind them to establish this as a defacto standard as they managed to do with the previous formats.
What your government did was simply to adopt the most sensible choice: they chose a industry standard and is now mandating that instead of feeding a convicted monopolist and helping it to keep its monopoly in place. Now, MS will have to compete based on merit, not file format lock-in.
As you probably noted, ODF is a royalty-free and fully published specification so there is nothing preventing MS of adopting it on its products. Of course, it will do a half-baked attempt (perhaps even try to cripple it) and then get back to the original agenda.
Your previous responses at least had a solid ground to the point that you were appointed as a solid pro-MS poster, not another chill. If this one wasn't a joke, I don't know what to think of it. Seriously!
Edited 2007-03-05 20:29
It is not a ECMA standard yet. It has only been approved to be put on the table to become one.
That’s good to know; I’ve heard it trumpeted as an EMCA standard which worries me, because that would make it a “standard” in the technical sense, even if we all know it is a 100% proprietary format in sheep’s clothing.
“It is not a ECMA standard yet. It has only been approved to be put on the table to become one.”
You may be thinking of ISO rather than ECMA. OOXML was approved as an ECMA standard months ago (the vote was 20 to 1, with ODF backer IBM being the lone holdout).
See the following links:
http://blogs.msdn.com/brian_jones/archive/2006/12/07/ecma-standard-…
http://www.ecma-international.org/news/PressReleases/PR_TC45_Dec200…
Doh! You’re right. I mixed up ECMA and ISO.
Excuse me, but have you actually looked at the ODF format? I can well and truely assure you that it is is possible to extend functionality using the standardised framework setup – so you aren’t stuck with what OpenOffice.org can use.
Compare the much simpler way of doing things of ODF to the overly complex and convoluted way in which it is being done by Microsoft in the form of OOXML, which either tells me one of two things; that their programmers are incompetant (which I doubt) or that they’re simply making OOXML so convoluted and complex that by the time full support is actually reached, Microsoft would have already leaped ahead.
Um… so if you have all the complications that Office introduces into files (some of which might be cruft built up from old versions, some of which might be legitimate facets of the complexity in real documents, especially in east-asian scripts), you’ll have a really convoluted “extended” ODF file. Is an undocumented but “standard” extended ODF file better than an extensively documented, but complicated, OOXML file??
But OOXML is not “proprietary”. It is an open standard owned by ECMA.
According to the California bill, “open” is defined as
1. Interoperable among diverse internal and external platforms and applications
2. Fully published and available royalty-free
3. Implemnted by multiple vendors
4. Controlled by an open industry organization with a well-defined inclusive process for evolution of the standard
OOXML satisfies those just as well as does ODF.
OOXML “calls up” or “references” a significant number of sub-formats that are indeed Microsoft proprietary formats.
Where OOXML could use an open standard (for example SVG for graphics) often it avoids the open standard and it uses a Microsoft proprietary substitute (in this instance, it uses WMF not SVG for scalable graphics).
This pattern is repeated throughout the OOXML standard. OOXML calls up a significant number of Microsoft-only proprietary sub-formats, such as Microsoft Excel formulas (rather than MathML), ActiveX, WMF, VBA, and in addition it calls up all sorts of “behaviours” of previous versions of Microsoft Office.
It is not possible to fully implement an OOXML application without (a) writing it to run on a Windows platform, and (b) reverse-engineering several Microsoft-proprietary sub-formats.
Even if you managed to do that, doubtless Microsoft would sue you for writing an implementation of ActiveX or WMF or whatever, since unlike OOXML itself those referenced sub-formats are not covered by any “covenant not to sue”
If I may add a little correction to your post:
MathML is a format for representing (e.g. “type-setting”) real world formulas in documents, something like
c^2 = a^2 + b^2.
EDIT: While it would be probably possible to use the MathML represntation to describe real calculations (e.g. to parse the result of such an equation and add the necessary infrastructure like parsing semantics, variables, terminals, etc.) I’m not aware of an instance that really does this.
OOML is the direct counterpart to the W3C standard MathML for this task, whereas spreadsheet applications like Excel (oocalc, kspread, gnumeric, …. ) use an internal “formula language” to encode things like
=AVERAGE(A1:A5)
or something like that (e.g. real, transparent calcuations).
Also on the subject of graphics, OOXML uses a mix of DrawingML (kind of replacement of the SVG part), VML (for legacy/backward compability reasons) and “embedded” graphic formats like the WMF.
Please appologize if I misread your post and this distinctions were clear to you.
Regards
Edited 2007-03-06 12:43
…what is the status of other free office suites for Unix-like environments (apart from OO.org)? Last time I checked*, Koffice was nice but still subpar, and the only worth application from the Gnome side is Gnumeric. Noticeably, the Gnome side AFAIK always lacked a presentation application. Has there been some serious improvement I should be aware of?
*a year ago