One of the great goals of standards development is to encourage the proliferation of multiple products that are comparable and interoperable at the level of standardization, but which each compete with value-added features, level of service and otherwise. This arises from a set of mutual expectations among vendors and end-users that each will benefit from the wide uptake of the standard, especially where interoperability is a necessity, or lock-in a danger.
To the vendor, the anticipated benefit is the rapid development of a larger and more long-term market than would result from multiple proprietary offerings, while the value to the end-user is greater choice, lower prices, more useful features, and avoidance of lock-in. But none of this will occur to the benefit of any stakeholder unless multiple vendors decide to implement the standard in question. As a result, the OpenDocument Format (ODF) will only be as valuable to end-users in fact as it is perceived to be potentially valuable to developers.
Happily, multiple developers, both proprietary vendors as well as open source communities, have decided that there is great value to be gained from supporting the ODF standard, promising just such an environment of rich features, service and protection from lock-in. Some have achieved a great deal of press, most notably Sun's StarOffice 8.0, the open-source OpenOffice 2.0 suite, developed by OpenOffice.org (which is supported by Sun) and IBM's Workplace Managed Client.
But there are also versions of ODF that are not fueled by vendor funding, and the most fully developed of those offerings is KOffice, an open-source office suite developed by the KDE (K Development Environment) project, which has been hard at work developing a free, open desktop environment and development platform since 1996 that runs on many UNIX variants, including Linux. A few weeks ago, KDE announced the release of KOffice 1.5, which achieves a high degree of support for ODF.
In this extensive interview, I explore with Inge Wallin, the KOffice Promotions Lead, how KOffice is different from the other major office productivity releases that support ODF, which users may find it most appropriate to their needs, in what directions future development will proceed, and much more. In the future, I hope to provide similar interviews with representatives of the other major offerings, in order to illustrate the way in which the ODF standards-based office productivity environment is evolving in real time.
1. Goals and hopes
Q: What is the KDE community’s vision for KOffice? Where would you like to take it and what do you hope it will become?
A: We have a short-term vision and a long term one. The short-term vision is to provide the best office suite for all KDE users. In some ways I think we already are that; it’s certainly the fastest and best integrated. For an example of how some users are surprised by the functionality, you can see this blog.
The long-term vision is to provide the best office suite, period. Since KOffice is developing faster than any other suite, this might actually be feasible, even if it will take some time.
What it means to be “the best”, is of course not the same for all people, but I am confident in that we can deliver lots of features without sacrificing usability. We try to leverage our community not only for developing code, but also for usability work and graphics. One example is the recent GUI competition that KOffice ran and with price money donated by an anonymous supporter.
Q: Has that vision changed over time, or have these always been the project goals?
A: From the start the goals where much more modest. I can’t speak for the original developers, but I know that the goals have been much expanded in just the short period that I have been involved myself.
Q: How many developers are involved in the whole KDE community?
A: There are 1250 people that have commit rights to the source repository. This is, of course only an approximation. On one hand, not all of these are active all the time. On the other hand there are a lot of people that don’t have commit rights sending patches to those that have, so I think it evens out.
Q: How is it that a developer community of only 14 (at the time of the release of KOffice 1.4) programmers, growing to 30 at this time, can develop and maintain a software suite of this size and complexity – working in their spare time?
A: This is due to several reasons:
– The outstanding quality of the technical platform – Qt and kdelibs
I think this is the biggest reason that KOffice and, indeed KDE itself, can be developed so quickly by so few. Qt is the best toolkit that I have ever experienced, and that sentiment is shared by most of the KDE developers. Qt doesn’t only provide widgets, but also core data structures that are simpler to use than the standard C++ template library.
The core KDE developers have then succeeded in enhancing the functionality of Qt with a higher level library of the same quality: kdelibs. The kdelibs is the platform upon which all KDE software is built, and it provides advanced features like application embedding (KParts), network transparency (KIOSlaves), multimedia framework, etc.
KOffice also contains its own libraries that further build on the foundation laid by Qt and kdelibs, further enhancing it. These libraries are used by all KOffice components, giving them a common look and feel throughout the suite.
If we want to put it in mathematical terms, then you could say that:
OpenOffice.org = Qt + kdelibs + KOffice
Actually, if we count all the developers at TrollTech and those working on kdelibs in our team as well, we are not so few any more. What is also nice is that we have a large community of volunteer developers, something that is almost totally missing for OO.o.
– The high quality of the developers
I don’t want to picture the KOffice developers as superhuman, but it is clear that the high quality of the platform attracts developers of high quality. What is nice is that the transparency of the code makes it easy for new developers to become productive very quickly.
– KOffice is well integrated into the KDE application space
KOffice can use several parts of KDE – both platform and other applications – to implement features that other suites have to implement from scratch themselves. One example of this is the export to PDF, which is provided by kdelibs. Another is print preview where we use the KDE application kpdf.
3. In what ways is KOffice different from OpenOffice.org?
Q: In what ways is it better?
A: Don’t get me started here… 🙂 Seriously, let me mention some areas where we think that KOffice outshines OpenOffice.org.
– It is much more comprehensive
KOffice contains a creativity application suite with a combined paint application and image editor (Krita), a vector editor (Karbon) and a flowcharting application (Kivio). It also has a database environment in the style of Access (Kexi) and a project planning tool (KPlato).
– Two of the applications are already killer applications in many respects, and are better than any other free applications in their field: Krita and Kexi.
– It is much better integrated into KDE, the most popular Linux desktop
– It is both faster and smaller
– It works just fine on 64 bit systems.
– And last, but certainly not least, it also has a much higher development speed than OO.o.
Q: In what ways is OOo ahead of KOffice?
A: There are several ways that OOo is ahead of KOffice:
– Compatibility with MS Office
This is the area where OOo is the strongest. KOffice can read and write .doc (although it’s really writing .rtf), .xls and .ppt files but it does lose some details of the formatting. There is also no way of importing or converting macros.
– Some OOo components have more features than the KOffice counterpart
We are narrowing this gap, but OOo is still more feature rich in its’ writer, calc and impress components. We do believe, however that Kexi is far ahead of OpenOffice Base, and several magazine reviews agree with us. We also have several components that OOo has no counterpart at all for, e.g. the project management tool KPlato and the drawing tool Krita.
– The community around the product (except for developers). For instance, there are several books written about OOo, and so far none for KOffice.
– Available on more platforms
OOo is today available on Unix, Windows and, in a somewhat clumsy way, on Mac OS X. KOffice at large is only available on Unix. However at least one component, Kexi, is already available on Windows and also supported by a polish company.
– Market awareness
Obviously more people are aware of OOo than KOffice. However, see below for how we think that this will change.
Q: How will this change in version 2.0?
A: Version 2.0 will be available on Windows and Mac OS X also. We will also implement more features in all of our applications, thus narrowing the gap where we are behind and increasing our lead where we are ahead.
With version 2.0, we will start to become a serious contender for many organizations, and we think that the market will take notice.
4. Same questions for StarOffice
A: I think that StarOffice (SO) can basically be treated like a rebranded OOo with support from SUN. This might not be 100% technically correct, but for all practical purposes it is. Thus every answer above also applies to SO.
Q: What types of users would KOffice be right for? For example, would it only be right for a developer, or would someone with an IT department able to provide support?
A: Today, KOffice is probably best for home users and small businesses where communication with MS Office documents is not crucial. Due to the full support for OpenDocument, KOffice can interact with other people and organizations using OpenOffice.org and in certain circles, those users are closely approaching 100%.
We know of several small businesses that use KOffice exclusively, and we conducted a survey on the net to ask our users what they were doing. You can find over 100 answers there online if you want more details. There is certainly nothing that prevents an IT department from providing in-house support for KOffice, and there are companies that already provide paid support for KOffice as well.
Q: The FAQ says: “Yes, some people have made very large documents with KWord. However KWord is far from being optimized for such a use.” This sounds like KWord is intended only for light use, rather than to compete head to head with Word. Is this likely to change in the future?
A: Well, I think that answer might be somewhat outdated. We might have to go over the FAQ and make it up to date.
Almost the only thing that currently prevents a user from using KWord for very large documents is that the whole XML file is read into memory before parsing it. This will make the program grow bigger than necessary. Otherwise, KWord works just fine for large documents already. In fact, we just learned that there have been a whole book written using only KWord.
Q: Will this change much with release 2.0?
A: Release 2.0 will above all make it faster and less memory consuming to read large documents into memory. Most of KOffice is already capable of handling large documents internally, especially KWord.
Q: Who provides support for KOffice today? Do you expect the support community to grow, and if so, where?
A: Today, the development community gives most of the support for KOffice. However, we have seen a budding support community growing out of the user community instead. That is very encouraging, as it shows that KOffice is getting some traction.
Q: Is there a “Red Hat” for Koffice today, i.e. a company that takes the open source program, optimizes it and provides support services for it? Do you expect there to be?
A: Jaroslaw Staniek, the maintainer of Kexi, works at a company that provides support for Kexi. However, we know of no company that provides support for the full KOffice suite yet. On the other hand, we have heard some rumors that such a company will be formed during this year. So yes, we do expect KOffice to become commercially supported soon.
Q: How does KOffice compare with MS Office with respect to accessibility for those with disabilities?
A: We are not really there yet. Here is what our accessibility expert, Gary Cramblitt, has to say:
“For blind users, it is a problem since there is currently no screen reader for KDE. For users with other disabilities, it depends upon what you are comparing. If you compare KDE/KOffice with MsOffice running with standard Windows OS, I would say they are comparable. But it is a matter of subjective opinion. If you are comparing to Ms Office running in conjunction with something like JAWS, which has been specifically integrated with Ms Office, then I’d say Ms Office is “better”. But my understanding is that JAWS costs something like $1500 and must be upgraded with each upgrade of Ms Office.”
On the other hand, both KDE and KOffice takes accessibility very seriously, and are working to increase accessibility of the whole desktop environment and KOffice. There is great work being done at SUN and other Unix companies to create the next generation accessibility architecture based on AT-SPI (Accessibility Technology – Service Provider Interface). This is work done in cooperation with Gnome, so the software that uses AT-SPI will work on both desktop environments.
We also think that most of the third-party products for the last few versions of MS Office will not work for the next version of Office, when it is released because of the greatly changed GUI. Remember that the vendor of those tools have to reverse-engineer every new version of MS Office. There is no accessibility architecture of similar power in Windows.
7. What is the roadmap for KOffice going forward?
Q: In the 1.5 press release, you note: “We acknowledge that the ODF support and interoperability is not yet perfect. We hope to be able to quickly identify and fix the incompatibilities that do exist in the upcoming 1.5.1 and 1.5.2 bugfix releases.” How soon do you expect that these releases will be issued?
A: 1.5.1 is expected in June, and 1.5.2 right after the summer 2006. What you have to remember is that it is not only KOffice that has bugs. The OpenDocument support in OpenOffice.org is more bug ridden than you might expect. Also, sometimes incompatibilities are due to incomplete ODF implementation in OOo. For instance, OO Writer has no support for frame based documents, an area where KWord shines.
Sometimes, it is also the case that the OOo developers interprets the standard in a way that we don’t agree with. KOffice has a voting member on the OASIS technical committee for ODF (David Faure), and these issues are handled in weekly phone conferences with the other committee members.
Q: When will KChart and KFormula support ODF?
A: They already do, but not fully. We expect to make the ODF support much better in 1.5.1 and 1.5.2. There is also an 1.6 release scheduled where we will add features that are currently missing for full ODF support in e.g. KChart.
Q: While your FAQ says that all of the components of KOffice are available on GPL-compatible licenses, it also says that different compatible licenses apply to different components. why is that, and won’t this make it more confusing for those that wish to use KOffice?
A: Well, the “GPL compatible licenses” in this case is only LGPL. I think we should change the wording of that FAQ.
9. ODF and KOffice
Q: What did the release of the ODF standard mean for KOffice? Was there no question that the community would wish to support it?
A: No, since the KOffice team was one of the driving forces behind ODF, there was never any question at all that we would support it. In fact, I think that ODF is one of the main factors that will make KOffice into an important player on the office suite field.
Q: How would you like to see the ODF standard evolve in the future? What would you like to see added to it?
A: The KOffice team was always a strong force behind the development of the ODF standard ever since we started cooperating with the OOo people in 2001, and we are continuing to be so. We are among the first to implement the OpenFormula standard for storing formulae in spreadsheet programs and we are strong proponents of creating new ODF formats for new document types.
We have already taken an initiative to develop ODF for layered pixel based images, and project planning tools. We are also behind developing a standard format for desktop databases. Although OOo claims to store its database files in the so-called ODF database format, in reality there is no such thing today. We hope to work with them to accomplish that soon.
KOffice is also planning to add even more components in the future – we have a mindmap program in the pipe, and more that is not yet decided upon. Those components will also need standardized file formats too, and we will always be active in that area.
Q: What effect do you expect the approval by the ISO/IEC membership of ODF to have on the fortunes of ODF supporting software in general, and of KOffice in particular?
A: Obviously, this is a tremendously important step for ODF supporting software in general. Since standardization is an important property of software, and ISO is *the* standardization body, this makes it much more likely that ODF support will be a mandatory feature in government procurements in some countries. Where and when (and if) this happens is yet to be seen.
Regarding KOffice, we now know that we made the right choice when we decided to push for the creation of ODF. Now that we have a well-defined standard, we will try to support all of it, something that no office suite does as yet, not even OpenOffice.org. It remains to be seen if we or the competitors will be first to do that.
For further blog entries on ODF, click here