Right now there is an ongoing discussion on LibO mailing lists (you can see the thread on Nabble) regarding ooxml support: historically, OOo allowed READ but not WRITE for this format but LibO enabled also the WRITE part.
Many people (like myself) feel that writing to that format is a very wrong move: MSOffice will support the previous formats for a long time so why implementing that pseudo-standard built with the only purpose to undermine ODF?
Creating independent implementations for ooxml only help MS, not the community. The most important thing to do these days is to support ODF not to give life support to that pseudo open "standard".
So here it is my question: which is the position of Calligra developers on this issue?

would this not be better addressed to the Calligra-devel mailing list?

Calligra doesn't have an official view on OOXML, but I think I speak for most calligra developers when I say:

* We think OOXML is a very poor format in general due to its many technical shortcomings.

* We think OOXML is a very poor interchange format due to its complexity, sheer size, and undocumented features. Also the fact that there is *no* implementation, not even from MS themselves, for the standardized format makes it even worse.

* The political origin of OOXML as a way to deter adoption of ODF makes it an unpleasant thing to handle.

So, we support import from OOXML to let users move away from it. In fact, I think our implementation is very good, and maybe even the best of all free implementations in many ways.

We do not support writing to OOXML. Even if we would, I am sure that the result would be bad enough with resulting data loss that nobody would consider using it for roundtripping data.

Last: All this said, it's not impossible that somebody or some organization would start implementation of OOXML export filters. Whether the community would accept this contribution and take it into the main sources is not yet decided. I expect that it would.

I always find these arguments strange with this idea that making it harder to use proprietary formats in free software will make people use free ones more.

If Firefox didn't exist on Windows / Mac, would people rush to Linux so they could use it? No, they would all be using Internet Explorer and Safari instead (I leave Chrome / Chromium out of this becauseit's combination of being open source and proprietary at the same time just complicates the analogy without adding anything).

To put it another way, if you're a small town (FOSS) trying to convince people to move from a large city (proprietary software), you don't do it effectively by locking the gates to make it difficult for people to escape. Yes, there's the justification of "If we unlocked the gates it would make it easier for people to move out to the city!". In reality though, there's far more people in the city, so the few extra people who stay because you made it hard to escape are dwarfed by the huge number of people from the city you've scared away from coming to your town in the first place. After all, no one wants to be locked in somewhere that makes it difficult to communicate with the outside world. It's much more effective to fling the gates wide open, make your town as attractive as possible and let everyone in the city know why it's worth visiting. Do your job well and many will want to visit, and then move to your town.

Lock in and removing interoperability is only effective when you are the dominant player with the largest number of users. If you're not, it's shooting yourself in the foot. What we need is ladders from closed to open software, with each rung close and easy to get to from the last, not gigantic moats trying to prevent people from escaping (or entering).

</ rant>

Note: I do understand the arguments about using developer time to make our own offerings as good as possible, when they're genuine and not coming from the ideological purist perspective of "anything proprietary we won't touch even if it's to help get people away from proprietary software."

On an interesting philosophy side note, it really seems to me that fundamentally this debate is actually about whether people subscribe to a deontological or consequentialist philosophy than anything to do with software. While personally I believe in both for different things, on this issue I definitely see the consequentialists as being more effective.

Using the analogy of big city - small town, ooxml should be like a highway that it is trying to pass on the middle of your garden.

Remember that the xml format used by msoffice is not the same accepted by ISO, and quite probably they will go on changing it to enforce their "vendor lock-in" strategies. If they settle on a real open standard then no problem, but this is not the actual situation.

Even if I try to avoid it, I'm not against closed source software but the data I produce must be under my control and that can be accomplished only with really open standards.

Anyway, I started this thread almost two years ago. I'm more relaxed now...

Regards

RGB wrote:Right now there is an ongoing discussion on LibO mailing lists (you can see the thread on Nabble) regarding ooxml support: historically, OOo allowed READ but not WRITE for this format but LibO enabled also the WRITE part.

First of all, I am not a Calligra developer.
The discussion is pretty pointless. Since 5 years Microsoft Office (except Mac versions) has very solid support for ODF. The upcoming MSO release will bump ODF compatibility to version 1.2. As long as no esoteric ODF features are used, ODF is a fine exchange format between MSO, LO, OO, and Calligra.

The only benefit of OOXML write support would be slightly older MSO versions and the Mac variants of MSO. However if those targets would be considered worth the development effort, at least for word documents RTF would be the vastly better option: Well documented and compatible with even more software (given enough care even compatible with 1990's software).