Michael Meeks has a tough job. Anyone who's struggled with making documents not created in Word interface with Microsoft Office should be able to sympathise.
As a distinguished engineer and architect at Novell, Meeks is tasked with tackling interoperability between Novell's OpenOffice.org productivity suite and Microsoft Office, a job made easier as a result of the high-profile tie-up between the previously vehement rivals.
If it's technically possible to make the project a success, Meeks is the man to do it, having earned a distinguished reputation as a software engineer. But, as with anything around interoperability and Microsoft, there is more to the issue than just the technology.
Things have been further complicated by IBM's recent entry into the OpenOffice.org community, as the company brings with it considerable experience in office applications and users through its own Lotus Domino offering. Faced with a string of competing office applications, not to mention hosted alternatives, such as Google Docs, an arena that was once dominated by Microsoft is looking distinctly crowded.
ZDNet.co.uk met Meeks at the OpenOffice.org forum in Barcelona and talked standards, compatibility and interoperability.
Thanks to Novell's relationship with Microsoft, is it fair to say the two companies are co-operating now?
I think at some level we do. [Novell] released this OpenDocument Format (ODF), which is now an ISO standard. I think people are really interested about not being locked into Microsoft's document standard — .doc. I like to talk to people about software freedom and the incredible power that comes from being able to tweak the software to your needs and adapt it and reuse it in different situations.
Sometimes it is difficult to explain to people, but it is easy to explain to them about their document data not being accessible to them. So there is huge traction out there and lots of people are starting to get interested in open standards and open formats.
So then Microsoft decided they were going to do an open standard too, and guess what: it is a .zip file and it's got XML streams inside it. But, having said that, it has been difficult in the past to do binary file format interoperability. You can make many good arguments that it is not a benefit to have one company totally dominating the market. You need some sort of file format interoperability.
Isn't one file format (such as ODF) better than two? Surely the weakness of having many is the confusion it creates?
Well, yes, and it should be ODF. In an ideal world... yes, a single file format that was a superset of features and so on would be ideal, but it is very difficult to even conceive of that happening. There is just such a lot of vested business interest in this sphere. It is just very difficult to do anything technical. I just can't see anything like that happening.
IBM has announced it will support OpenOffice.org. How do you see its contribution shaping up?
They are very involved in open source but they have held back from contributing to OpenOffice.org for various reasons. Now they have bitten the bullet and we will see how it goes. Software can only improve. It can always get better.
I think IBM brings real credibility to OpenOffice.org and, of course, huge resources. There are a lot of perspectives around this and mine is that a purchaser really wants multiple suppliers. They don't really want multiple implementations. It is no problem having multiple implementations, but it means rewriting the same thing again and again. If that turns you on, of course, then fine.
What they really want is to be able to say that, if this person won't support me, I will go to IBM, or Novell or whoever. Then you can have confidence that there will be people there who can support you. And, if someone is doing a really bad job, you can just switch to someone else and that has just never been the case in the software industry in recent history. There is no choice in document formats. You are tied into a single vendor.
Free software gives you the freedom that, even if you are a one-man shop, you can have it fixed if it is annoying you enough. The example I like to give is "Clippy" — remember? — that whipping boy of journalists. You couldn't turn it off and it came on and you had to talk to it before you came on.
Now turning Clippy off, in my estimation, is a single line of code change. With Microsoft you just couldn't do that. You couldn't get into their software, find the piece of code and...
...just fix it. If you think about the software cost of some catastrophic blunder, often it would be way cheaper if you could just get in and fix it. I think that is a huge benefit of the free-software industry.
You are focused at the moment on the issue of how you get the look and feel of OpenOffice.org right, I understand. What are you looking for?
The main issue is that, when we have a dialogue — and most Windows systems have the same problem as OpenOffice.org has — what you do is, you have this little canvas, a Visual Basic thing, and you draw a button, and you draw another button and so on.
Now there is really no layout to this. You can't enlarge the window, because it really wouldn't look right. You enlarge things and it would just add grey space or something. If you increase the font size, the thing grows as the fonts grow but, beyond that, there is nothing exact. Modern toolkits, like Java, introduced layouts so it was more like a web page. You see that when web pages resize they can do that.
The real reason it has become a focus is that our toolkit currently looks much like Windows — well, say Windows 95. To improve that we have gone for things that you see in Windows XP. The trouble is that, when you start introducing these new looks, particularly on new different platforms, like Unix or Linux and Mac OS, well...
You know that Mac buttons are huge and have these pulsing backgrounds so the area that you have allowed for your scroll bar needs to be twice as tall and so on.
The problem then is that either you add lots of wasted space for all these different platforms and shapes or it all goes horribly wrong. You scale things and it looks ugly.
So, hopefully, we have now solved that so, if you want to resize a figure, then fine. You just resize it. That is the thinking behind it.
Is it going to be difficult do this efficiently?
It is more of a resource thing rather than about efficiency. For example, take German. Often the words are quite long. The problem is that, when you resize, you have to leave enough space for German screens.
Did you use consultants for this?
Yes, we have used our internal consultants and we have exercises where we have people doing basic tasks and struggling to do them. And we did hundreds and hundreds of hours and that paid off massively in terms of usability.
If you look at the Windows menu, it shows you can install many different applications on the system, so you wind up with this four-column mess. Then you have to try and find this application that you have just installed and you have forgotten the name of it, and so on. We had a sort of similar tree-hierarchy thing in our menu but then we realised that, actually, this is not a very good ergonomic way of working. So now we have favourites that you can customise very easily and then you can use search and your browser and go through your applications. Then you might be an expert user, in which case you know the name anyway, so you just type the name, hit enter and it runs it. Otherwise you have categories and you can browse it and so on. And then some users find tree views very irritating. And categorisation is sometimes difficult. There has been some really interesting user-interface work there.
So when will it be ready?
This is really a discussion between us and other people working on the code. Now this is a competition between us and other people, but I think ours is a very strong contender. Within the next month I would expect to see it start to move.