OOXML? What’s that second ‘O’ for?

This was originally intended to be a comment on Dmitri’s post on the topic, but it quickly outgrew what I felt would be a polite size for such a comment. Oops!

OOXML hasn’t lost quite yet, and it did come dangerously close to passing in its first run through the Holy Gauntlet of the ISO. With any luck, voting parties will be better informed when its next chance comes around.

OOXML is just the same old formats, along with the same old problems, encoded as something vaguely resembling XML. I doubt Microsoft will clean up the spec enough for ISO to accept it; legacy crap has been a hallmark of their formats since the beginning, and if they haven’t managed to fix that problem yet, I can’t see them fixing it now.

However, even if they do rework the spec into something useful, an even bigger problem remains: Microsoft has shown no intention of using OOXML in a standard fashion; that is, the file formats actually used by Microsoft Office products may be based on OOXML, but it is unlikely they will ever be standard.

This means that there will be no improvement over the current situation, in that there is no guarantee that documents written in Microsoft Office products will be usable elsewhere.

In the past, people used Microsoft’s de facto standards, and accepted this, because they didn’t know otherwise. Now, a lot of people understand the problems of closed, proprietary formats, and some progress has been made. If OOXML is standardised, people will believe that the problem has been solved, and not as many will care about seeking alternatives.

The standardisation of OOXML would cause a serious regression. People will still be using closed, proprietary formats in Microsoft Office products, but now it will be under the guise of openness. A brilliant, disgusting deception.

Not a cloud in the sky

I know this isn’t news, but it’s something I’ve dreamed of for a long time. Finally, a group has taken it upon themselves to make it a reality for an important software project.

The Linux Weather Forecast.

I’m commenting on this because I think every project should have something similar. And I’m not just talking about software projects, either; this kind of thing is equally relevant to any project, regardless of size or type.

Key things to include:

• The current state of the project
• Where the project is headed
• Where the project is not headed
• Where the project might be headed

All of the above should be broken down for any sub-projects. Now, what have I left off? Notably the high-level goals of the project, and its background. I’m not suggesting that these are unimportant, but they can go elsewhere.

Why is this so important? It gives a great overview of what the project is, and what it aims to be in future. It gives potential developers a lot of information at a glance that they can use to decide whether they might be interested in contributing, and how they could go about doing so. Developers from other related projects can more easily see how it might relate to their project, and how they might better work with your project. It can generate interest and exposure, and stop your project from being a confusing black box to outsiders.

Note that the Linux Weather Forecast doesn’t read like an advertisement. Its purpose is to inform — not to boast about how great Linux is, how it can lower your TCO, or any other such waffle. It is simple and to the point, and that’s why it is so great.

With any luck, other large projects will notice this and follow suit.