Also just in from the Red Hat News blog: One of our legal counsel penned a reader’s guide to the Firestar settlement. Totally worth reading if you’re at all interested in IP, licensing, and–in particular–the defensibility of the GPL.

Red Hat is committed to providing you with the information, tools, training, downloads, and contacts you need–fast and at your fingertips. As a part of our efforts to continually improve your online experience, we’d like for you to share your thoughts and opinions with us in a short, five-minute survey. No registration or personal information is required.

>> Take the survey

The information you provide will be used to help us determine:

• The general profile of people using our site
• Which aspects of our websites work well for these users
• Which aspects of our websites need improvement
• What updates we should make to our web properties and how to prioritize them to meet the needs of the users

Thank you for your time.

Authors: James Bessen and Michael J. Meurer
Publisher: Princeton University Press
Publication Date: March 2008

Patent Failure examines the current state of the American patent system based on the way it has traditionally been treated–as a type of property system. Using the yardstick of property rights and the economics they influence, Bessen and Meurer analyze the costs and benefits of patents to innovators. Their qualification: “If the estimated costs of the patent system to an innovator exceed the estimated benefits, then patents fail as property.”

The authors rightly point out that many of the criticisms of the patent system are anecdotal. We’ve all heard about the peanut-butter-and-jelly patent. So what are we to base reforms on then? Patent Failure answers that with empirical evidence, largely economic, but also from history, international comparison, and legal precedent. The book focuses quite a bit (some might say a bit too much) on the claims brought by E-Data, now a decade-old case.

For quite a few years, patents have been lumped in with the completely different systems of trademark and copyright under the title “intellectual property.” And, as the authors point out, the quotation marks have fallen away. Many, if not most, people now assume patents are property. But for certain industries, namely software, patents fail as a property system.

So what should we do?

That “for certain industries” part is a sticky point. I have to admit, it’s easy for me, and I suspect others, to forget that patents can work quite well outside of software. But because that’s where the controversy is, that’s where the media is, and so it’s the failures we hear about. Bessen and Meurer do plenty to build a separation, often making exceptions for chemical and pharmaceutical patents. Those types of patents come much closer to passing the patent-as-property test than software.

The authors then devote chapter 9 to “Abstract Patents and Software,” the entirety of which you can download as a book preview. They point out that “no other technology has experienced anything like the broad industry opposition to software patents that arose during the 1960s.” That is to say, this unprecedented opposition is coming from within the industry the patents ideally help protect. Software developers oppose patents on their own work. You simply cannot draw the same fence around the property lines of software patents the way you would around the property boundaries of the land you own. The authors conclude:

[Software patents] play a central role in the failure of the patent system as a whole. Any serious effort at patent reform must address these problems and the failure to deal with the problems of software patents–either with software-specific measures or general reforms–will likely doom any reform effort.

Like not giving away the end of the movie, I’ll leave it to you to read and form your own opinion of their recommendations that follow that chapter. You can also read excerpts and some interesting discussion about the book on PatentlyO, a patent law blog.

And if you’re interested in hearing more about the authors’ ideas firsthand, Michael Meurer will be presenting a session about Patent Failure at the Red Hat Summit on Thursday, June 19 at 11:30.

At the 2006 JavaOne conference, Sun announced plans to open source Java. This wasn’t exactly a surprise to those of us working on Java at Red Hat, given that there had been rumblings before. But this was a real announcement. We were immediately interested in learning exactly which license Sun would choose. Even if it was a legitimate open source license, it still might not allow us to combine our code with Sun’s.

We have been working on free Java for many years–most particularly through gcj, a project started at Cygnus in 1998 by a developer named Per Bothner. Gcj has been steadily improving over the years, but still wasn’t fully Java-compatible, partly because we couldn’t get permission to run the official Java compatibility test suite. We had also been working on GNU Classpath, which is GNU’s free replacement for the core Java class libraries from Sun. We were very curious to see the “official version.”

We were thrilled to hear Sun announce in November 2006 that it had selected the exact same license as GNU Classpath.

When the complete Java source code–now called OpenJDK–was released on May 9, 2007, there were a few challenges. Most notably, some of the code was missing. Over the years, Sun had licensed Java libraries from a variety of sources, some of which would not allow their code to be open sourced. In order to work with this encumbered code, Sun provided some “binary plugs” that were copied into the build. This presented a problem as Fedora’s rules don’t allow the inclusion of anything that isn’t open source. It’s hard for us to maintain confidence in code we can’t see.

We were 95 percent of the way to a truly free Java. The way to fill that last five percent became clear: use the code from GNU Classpath. We later discovered that one of the reasons Sun selected the Classpath license was so that they could work with the Classpath developers and the Linux distributions that already used GNU Classpath. This was a great vote of confidence.

We needed to start a project to combine OpenJDK with the GNU Classpath code. This project could have been hosted within Red Hat, but we didn’t want this to be seen as Red Hat only. Classpath came to the rescue and Mark Wielaard, GNU Classpath maintainer, set up the IcedTea project. This is the repository for the totally free version of OpenJDK.

Bootstrapping was another not-so-obvious problem. Much of OpenJDK is written in Java. Sun built the first release of OpenJDK with its unfree Java. Fedora, however, doesn’t allow packages to depend on any unfree software. This time, it was gcj that came to the rescue. Since gcj is completely free software, we could use it to build OpenJDK. This also ensured that unfree code couldn’t “leak” into our OpenJDK package during the build process.

Over the next few weeks, a team within Red Hat worked vigilantly to create the OpenJDK and GNU Classpath hybrid that was to become IcedTea. Less than a month after we received the OpenJDK source code, we were able to release IcedTea 1.0. In a few cases, we had to create non-functional stubs for code we didn’t have, but the result was good enough to run many of the Java applications in Fedora. Since then, Sun has created replacements for many of the binary plugs and we have gradually been able to remove much of the GNU Classpath code.

The OpenJDK that Sun released only ran on i386 and AMD-64 machines. Fedora runs on other systems, in particular those based on the PowerPC. To solve this problem, we started an IcedTea porting project. That project produced an interpreter-only OpenJDK port for the PowerPC, based on Sun’s C++ interpreter. This later became Zero, a truly portable “zero assembler” version. As you might expect, a pure interpreter is not as fast as the high-performance JIT (Just In Time) compilers often used in Java implementations, but we’re working on that.

The OpenJDK code that Sun released was a preview of Java SE Version 7 rather than an implementation of Version 6. Java SE Version 7 has not yet been released and neither has its specification, so IcedTea cannot officially be certified as compatible with anything. Despite this, it works so well that we shipped it with Fedora 8.

Though it is not officially part of the Java platform, for many Fedora users the Java web browser plugin is essential to a complete desktop experience. Sun did not open source its Java plugin with OpenJDK, presenting another opportunity to utilize IcedTea. GNU Classpath includes a Java plugin named, for historical reasons, gcjwebplugin. By adapting Sun’s applet viewer code slightly, we were able to integrate gcjwebplugin into IcedTea to provide a working Java plugin. This plugin was released as part of Fedora 8, and is installed by default on both x86 and x86-64. This was the first time a 64-bit Java plugin had been available to Fedora users; unfree Java plugins are 32-bit only.

The plugin is closely related to the other Java deployment technology, Java Web Start, which also currently lacks an open source replacement. We’re working on IcedTea to complete the support for both the plugin and Java Web Start. We’ve integrated and extended NetX, an open source web start implementation; it is now nearing release-readiness for Fedora. We’re making good progress on gcjwebplugin’s two missing features: a LiveConnect Java/JavaScript bridge and signed applet verification. Future Fedora releases will boast increasingly better integration of these Java deployment technologies.

After the release of Fedora 8, the lack of an open source version of Java SE Version 6 became more of a problem. Developers were using IcedTea on Fedora, but as it was a preview of Version 7, there was a risk that people might rely on libraries and interfaces that would change when Version 7 was released. Sun started an OpenJDK 6 project, which took the OpenJDK 7 code base and made the changes necessary for it to be compatible with Version 6. We immediately realized that this would be far more useful to Fedora users and developers.. After some discussion, we decided to base the next Fedora’s OpenJDK on the Java 6 code.

At the same time, Sun decided to allow Fedora to use its OpenJDK trademark for IcedTea. This makes perfect sense as there are now so few binary plugs needed to build OpenJDK that it’s a distinction without a real difference from a user’s point of view. Fedora 9’s package is now called OpenJDK, not IcedTea, and it is based on OpenJDK 6.

We have also been permitted to run the official Java SE Compatibility test suite on OpenJDK. This test suite has a crucial role in Java: to be called Java-compatible, an implementation must pass every one of tens of thousands of tests. Simply running this test suite is a huge effort. We still fail some tests, so our OpenJDK package cannot yet claim to be Java compatible, but we are working on it. Watch this space. When we pass the last few tests, we will finally be able to say “Java is free!”

AbiWord just had a great 2.6 release and the developers took several hours of their spare time over a few weeks period answering questions and providing information. Thanks to the team and especially MarcMaurer for his time and patience. We present you a detailed interview with the AbiWord team on a broad range of topics.

Marc Maurer
Location: Enschede, The Netherlands
Age: 27
Profession: Software Engineer
Hobbies: Hackers have to hack
IRC nick: uwog
Website: http://uwog.net/

Martin Sevior
Location: Melbourne, Australia
Age: 49
Profession: Associate Professor of Physics
Hobbies: AbiWord, Running, Karate, Enjoying life
IRC nick: msevior
Website: http://msevior.livejournal.com/

Tell us something about the history of AbiWord.

AbiWord was started in 1998 by AbiSource Inc., a company founded by SourceGear corporation. The initial plan was to build a free office suite named AbiSuite, which would encompass things like a word processor, presentation program and a spreadsheet program. The office suite would be cross platform and use the native UI on every operating system it was ported to. Unfortunately they didn’t have a usable product yet when the venture capital was all used up. I think this was somewhere in near the end of 1999. Around that time StarOffice was also open-sourced, so new venture capital was hard to come by with such a big direct competitor in the market. In the end, AbiSource Inc. went belly up and volunteers started to take over the project. The only code written so far was for the word processor part of the office suite (AbiWord), so that’s what people started hacking on, and continue to hack on till today.

How many people are on the team?

The more regular contributors are Dominic Lachowicz from the USA, Martin Sevior from Australia, Robert Staudinger from Austria, Hubert Figuiere from Canada, Ryan Pavlik from the USA, Tomas Frydrych from the UK, and me (Marc Maurer) from The Netherlands. Then of course we have quite a bit of people sending the occasional patch or translation updates. Then there is Kamran Khan from the USA. He’s been very active as our Q/A guy, and he’s working regularly on all our importers and exporters

Tell us more about yourself. How did you get started?

I got started somewhere in 1999 when I was 19. I was bored during some classes, and fixed a bug in AbiWord 0.7.14. Since the community was _really_ friendly, I stuck around. That was my first ever contribution to a FOSS project. I started working on the WordPerfect importer, as my father needed that. When we saw our code would be useful for other projects such as OOo as well, we split that off into libwpd.

Within the team, how do you share your work or decide what each person works on? Do members work on specific things?

We have no policies whatsoever. Everyone is free to work on whatever he or she loves working on. In practice we see that everyone has his own niche which he works in. For example: Kamran tends to touch the import and export filters; Martin does the bulk of the document layout code; Ryan maintains our Windows port; Robert often works on the build system and is replacing our old home grown code with glib equivalents; Frydrych did most of the text shaping and rendering work, and I myself mostly work on our collaboration plugin these days and keep myself busy maintaining the stable branch.

It is exciting to see the 2.6 release after a long time. How long has it been in development?

Let me see… we branched off the development branch when we released 2.4.0, which was in oct. 2005. That makes it ~2.5 years. Wow, that’s long :-P. Bad us.

Do you want to do more frequent releases going forward?

Yeah, 2.6 was definitely bad in terms of our release process. This was due to 2 things really:

• abicollab, a new plugin that allows collaborative editing, took way more time to develop than planned and we really wanted to ship it with 2.6.
• our involvement to get the codebase ready for inclusion on OLPC took away a lot of spare time but both were important enough we felt to delay 2.6 for.

How has the experience of working with OLPC been?

When we started, it was quite annoying at times. This was mainly due to the lack of direction and concrete plans. On the other hand, that is to be expected. The end result was definitely worth it though, as the OLPC enabled us to work full time on getting AbiCollab production ready, for example.

Were you contracted?

I was, yes. I think for about 6 to 9 months but we also spent tons of spare time on it. Martin Sevior and Robert Staudinger also devoted a considerable amount of their time, and so did other abiword hackers.

Could you tell us about the collaboration plugin?

The AbiCollab plugin allows multiple people to work on the same document in real-time. You can select which transport you want to use. For example, we have a basic XMPP (Jabber) transport, a pure TCP one, and we developed one for OLPC, which uses Telepathy.

Does that require a server like Gobby, or is it peer to peer?

It’s a mix: 1 document is always the “master”, which we need for tie-breaking collisions and to make sure the documents stay in a synchronized state. However the protocol is totally lock free (good for high latency connections which we have on OLPC for example). Also there is nothing in the design that prevents us from making another user the master in a session when the current master wants to stop collaborating. We didn’t implement this last part yet, but we should have it ready soon. This lack of master-takeover is why the AbiWord 2.6.0 release notes still called AbiCollab “experimental”.

How do Abiword sessions on a network discover each other–do you connect specifically to an IP address?

That depends on the transport used really. For XMPP you add your Jabber account information. For TCP you connect to a specific IP. For OLPC the discovery is built into the platform, which we tightly integrate with. This integrated approach works really neat in practice. For the desktop I’ve been wanting to make a Telepathy backend, but i didn’t get to it yet.

We are currently also working on another transport that will use a webservice called http://abicollab.net/ that we are developing. With this backend you just login using your email address and it will automatically fetch all your documents, friends and groups from the webservice.

Martin: Actually our webservice really takes the online experience to a different level. All your on-line documents are accessible from the browser or within AbiWord. In addition we solved one really critical bottleneck in collaborative document production: you don’t need to wait for your colleague to check in his changes before you can see what he has done. You grab the most recent document off the site and that is what he is typing in. You can see exactly the latest changes at all times, even when the latest work was not saved yet. By hosting the documents on the site we automatically get around the problem of imperfect file format filters. Users just grab an AbiWord release (a 20 second download) and they see exactly what you’ve typed. No one else has anything like it and I expect Microsoft will be scrambling to add this feature for their next version of Office. It was worth the long wait for 2.6 to get this right.

Marc: To plug this even more: one cool feature will be the ability to direct link to any revision of a document hosted on http://abicollab.net/ in any format. For example, you can give someone a link to the latest version of your resume in PDF format. As soon as you update your resume (ie. hit CTRL-s in AbiWord), the linked PDF will reflect those changes immediately. Pretty neat if you ask me :)

What are the future plans for Abiword?

For 2.8, we are trying to be conservative. It will not have a ton of new features; It will feature the new Annotations feature though, as well as a proper GTK+ widget that application developers can use in their application as a rich text widget. The fun thing about the widget will be that you will get everything that abiword supports for free, such as support for all the file formats abiword supports and all AbiCollab’s features.

What kind of features do you see in demand from users?

Interestingly, not any particular feature stands out anymore. In the AbiWord 1.x era users mostly wanted Table support. For 2.x it went from the lack of floating textbox support, to document revision tracking and better support for international scripts. These days we are pretty much feature complete I’d say, with Annotation support being the single obvious hole in our feature list. On the other hand, Annotation support will be a feature that only a very small percentage of users will actually use, so I guess most people are happy with AbiWord’s feature list as it is.

Oh, and don’t forget improved OOXML filters. As MS Word 2007 will start being used more and more, the number of .docx documents floating around the net will pick up dramatically. Our users will expect us to be able to handle those.

Do you have many platform specific features, or do you use the same technologies everywhere?

We use the native toolkit on every platform. That means GTK+ on unix-like platforms. Cocoa on OSX (although we don’t have any developer working on that platform at the moment, which is really sad) and the Windows API and GDI on Windows platforms. We do try to make as much of our code cross platform though, for example, one really annoying thing we have to deal with is having 3 separate graphics classes (render engines)–we really want to get rid of that.

How are you planning to deal with these things in the future?

On UNIX, we recently switched to Pango, which is available on OSX and Windows as well. If we then also move to cairo, we can share a single render engine on all our platform. For the toolkit, some people have expressed interest in creating a GTK+ port for Windows and OSX. We don’t plan to make that the official port though, but it’s certainly interesting to see what the result will be.

Are the ports for different platforms managed by different people?

Yes, but in practice there is a lot of crossover. Also, we don’t have a lot of manpower, so if the platform maintainer is gone for a while, one platform can lag behind the others for a while

How has been the collaboration or competition with other FOSS office suites been?

We don’t share a lot of work with other office teams. However, we do create code that is shared between OpenOffice.org, KWord and AbiWord, for example, We created the libwpd library, a library for importing Word Perfect documents; that is currently used by OOo, KWord and of course us. We also created enchant (Dominic mostly) - that’s a general spell checking framework that is starting to be picked up by the others. We don’t compare ourself too much against the rest though. We are a tiny team compared to OpenOffice, with quite a different vision.

Has similar sharing of code not been possible with other filters?

It would have been, but every project already had its own filter for the most common file formats and no one is keenly interested in ditching working code.

So the quality of import/export filters would be different between them?

That’s very much so. For example, we’d love to share OOo’s word import filters.

Why hasn’t that happened then?

That can’t be easily split off from OOo. The code is too integrated. The OOo hackers obviously have no time/interest in untangling it of course, which is understandable.

Is Abiword capable of supporting all the Word features, even if the code is shared?

Not to the extent that OOo can, but we would be able to support almost all features users typically use; the one area lacking would be Annotations and Word Art. The first we will fix in AbiWord 2.8. The latter we will probably not implement.

How do you work with distributions?

We try to get as close to the distros as possible. For example I’m the AbiWord maintainer in Fedora. That really helps us to get high quality packages in the distribution. With Ubuntu for example it’s a bit harder, as we are too far from the actual packagers. That leads to some issues, such as a lot of Ubuntu users still think after 2.5 years that we don’t support the ODF file format which is not true; this comes from the fact that Ubuntu ships that import/export filter as a separate package. Not a lot of users seem to be aware of that; they don’t know additional packages exist that’s why we are consistently pushing the distros to ship the most useful functionality in 1 package. We hope Ubuntu will fix the long standing bug report about this, as they are a popular distro.

How long have you been the maintainer for Fedora? How has the experience been?

Let me see. My first spec file change was Fri Mar 14 2005. I must say the Fedora experience has been getting better consistently over time. The merging of extras and core was one of the best things that happened over time, making outside contributors a first class citizen. Also the web services (Koji and Bodhi for example) have improved a lot over time. Another good thing is that Fedora is really close to upstream. I often push an Abiword update to Fedora even before it hits abisource.com, which is very nice to be able to do. The lack of bureaucracy is a real blessing. The other area that has seen good improvements is the package review that helped cleaning up my packages a lot recently. Creating a working package is one thing; having consistency across nearly 10,000 packages is very hard to achieve, but Fedora is doing better every day in that respect.

What do you mean by lack of bureaucracy?

Let me give an example about the lack of bureaucracy. AbiWord 2.6.0 was released a few days after the official Fedora feature freeze. I was unaware of this (didn’t really pay attention to the schedule, sorry :), so I pushed it in and now my push caused some problems, such as dragging in a lot of new dependencies on the live cd. Instead of forcing me to revert my invasive change, Fedora allowed me to fix it to be able to have the nice new Abiword available in Fedora 9. They could also have chosen to deny my push, as it really was after the feature freeze date.

Is there anything you want to see Fedora improve on to be a better platform for upstream ?

I really would love to offer suggestions wherever, but I can’t see how Fedora could improve on this a lot. The process ‘Just Works’ :-)

How is the concept of GNOME office working out, and what is your integration with Gnumeric like?

GNOME is still missing a presentation program.

As much as some people would like to see it differently, GNOME Office really never existed. It started off as this weird ‘Meta-Package’ concept, just listing every productivity related program on their website. We tried to bring some direction to it by focussing on Gnumeric, GNOME-DB/GDA and AbiWord. However, apart from updating the website, it really went nowhere. As for the integration with Gnumeric, we do ship a ‘GNOME Office’ plugin, which is based on libgoffice. The plugin allows people to embed (and edit) Gnumeric charts within Abiword, which is pretty nice. It is not based on any component model such as bobobo, but instead the plugin provides the glue between goffice charts and Abiword’s general embedding functionality. Also, we made sure you can copy/paste Gnumeric cells from Abiword and visa versa.

As for the presentation program, there was a tiny amount of code in libgoffice for a while that could read PowerPoint files. It was never really used for some reason; I guess no-one is really interested in creating a true GNOME presentation program. The AbiWord developers always used AbiWord in fullscreen mode to do their own presentations; Martin Sevior recently added a new plugin to Abiword that added a ‘Presentation’ view. This will show your document in full screen, and uses the common keybindings, such as left-mouse click will go to the next page/slide, and the right mouse will go back if anything has changed. He has expressed interest in improving its capabilities, so its usability might rise above the gimmick level in the near future.

Has the Abiword team participated with the ODF spec?

We were asked to join the review committee, but we didn’t accept.

Why not?

In contrast to what everyone was saying, we would be far too small to make any real change. ODT is basically run by the big corporations like Sun, Novell and IBM. It would be naive to assume there was anything we could change about the format. Those are my views by the way, I can’t speak for the other Abiword developers; I doubt they will disagree.

Martin: In a nutshell neither Dominic nor me wanted to be part of the odt committee because we felt it wasn’t a good (or fun) use of our limited time. Both dom and I have full time real jobs as well as families. There is only so much we can do. For my part I’d rather hack on Abiword than have to fight political battles. All that said, if we had been on the committe we might have prevented a couple of silly things being part of the spec.

Such as?

Martin: ODT has page reference positioned images and frames. This means that an importer cannot place the image or frame in the document without laying out the document first. So if you want to translate an ODT file to a webpage you’re screwed, because you don’t where to place the image.

Marc: Not if you do a 2 pass export :) This obviously sucks complexity and performance wise, but technically it is doable.

Martin: ODF also doesn’t define a region over which comments are applied. So in Abiword you can highlight a region and put in a comment like “This phrase makes no sense” or even better, suggest a sentence that should be used instead. Your collaborator on the document can then just click “replace” on our annotations dialog and the text in replaced. Now we can’t preserve this feature when exporting to ODT, because comments are only defined at positions in the document not as regions. I have no idea why they did this.

Any comments on ODF as the default format? There was a 2004 discussion, but has anything changed after that?

No. We will not make it our default file format. Our internal model does not map 100% to ODT and visa versa (basically because ODT is nothing more than a dump of OpenOffice.org’s internal format). Any data loss that happens because of saving and loading a file again will not be accepted by our users. A user can make ODT the default in their own profile though. Interestingly, we do save to ODT by default on the OLPC XO laptop. We can do that there, because we only have to support a subset of features AbiWord supports, making the roundtrip (almost) flawless.

So you don’t advise distributions to set it as default either?

No, I’d strongly advise against making ODT the default format in Abiword for distributions given the previously mentioned lack of 100% feature coverage.

How is the support for OOXML?

We only support OOXML importing at the moment, and it doesn’t cover the full spec by far. We got the OOXML import filter as a result of last years Google SoC program. This years SoC program will hopefully futher improve our import capabilities, and maybe bring us an initial OOXML export filter.

Was writing a OOXML importer hard to do? Did you run into any major problems? How did it compare to write a filter for ODF?

I’ve no idea really, as I never hacked a single line on either of those filters. AbiWord has become big enough that you can’t know every line of code anymore I guess :)

What about this year? What are the projects?

This year we will have 6 students working on AbiWord. Two people will work on our OOXML filter (import and export); one person work on improving our LaTeX export filter; Ryan will work on improving our handling of document styles; Robert will port AbiWord’s render engine to Cairo and replace gnomeprint with GtkPrint and finally we will have a student working on a multi-page view, allowing you to view several pages side by side.

What do you think about OOXML becoming a ISO standard?

I’m really sad about the ISO verification process, which is a complete farce. As for the format itself, from our point of view it’s just another file format we have to support, with all its good and bad parts. In the end, it doesn’t matter a single bit if it’s ISO approved or not. Millions of people around the world will MS Office and thus create documents that people expect us to support. So even though I’m strongly against how the process was conducted, we will have to support the format.

Was ODF support different in any way?

No, us supporting ODF (even before it was ISO approved) is exactly the same as us supporting OOXML.

How and why did you get involved with Fedora specifically as a maintainer?

For every release, we always uploaded quite a number of rpms to our website (for SuSE, various Red Hat Linux and Fedora Core versions, etc). This gave our users the opportunity to always run the latest version of AbiWord as soon as we made a new release. While this effort was appreciated by lots of users, it also proved to be very time consuming to maintain for us. It also was not the ideal solution we were looking for in terms of ease of use. For example, the AbiWord RPM includes lots of plugins by default, which drags in quite a number of dependencies. The process of manually resolving these dependecies often proved too hard and confusing for our users, even when they were all available in the default repositories.

The only proper solution to solve these issues was getting close to the distribution AbiWord maintainers, or even become one. The latter was not possible in the Red Hat Linux era, but that all changed with the creation of the Fedora Extras reposities. This gave me the perfect opportinity to become the maintainer of AbiWord, and upload new releases directory into the official Fedora repositories. Since then I’ve maintained AbiWord and a number of its dependencies in Fedora, ensuring that Fedora users always have access to the best AbiWord experience possible.

How much does being far from the actual distribution package maintainers affect you, versus the distribution model in Windows where you are directly reaching end users?

When the distribution does a decent job of packaging AbiWord, it works really well for users. They can get all their software and updates from in one single place: the distribution’s software repository.

Things start to fall appart when the distribution starts making the wrong choices: split out the plugins in a seperate package or not, which plugins to package and distribute, that sort of stuff. Splitting out plugins in a seperate package for example only makes sense if having a small download is of absolute importance. From a users point of view, it’s almost always the wrong choice. Ubuntu bug 24195 (https://bugs.launchpad.net/ubuntu/+source/abiword/+bug/24195) is a classic example of this, where they decided not to ship the OpenDocument filter in the main AbiWord package. We had a lot of users complaining to us that we didn’t support the OpenDocument format. They simply didn’t know a seperate plugins package existed (nor should they have to know).

When a distribution didn’t package a plugin that a particular user would like use, then the game is basically over. The user would have to resort to compiling the whole of AbiWord and the required plugins himself, which is almost never an option.

This is all very different on Windows, where we can provide the latest version of AbiWord and all its plugins in a simple convenient installer on our download page. In the end, we have far fewer complaints regarding software distribution coming from our Windows users than from the Linux users. If you consider the fact that our Linux userbase by my estimates is a lot smaller than our Windows user base (and more technical generally as well), it shows us that we have a lot of work to do on the software update distribution front.

The AutoPackage we provided on our download page for AbiWord 2.4.x came close to the easy software distribution channel we have for Windows platforms.

Abiword was one of the earlier adopters of AutoPackage. What happened? What has been the experience with it?

Our AutoPackage was an experiment done by Robert. While it seemed to work nicely for a lot of users, a whole bunch of users also had some serious issues with it (I think they were mostly libstdc++ related, but I could be wrong here). Also maintaining an AutoPackage took a non-trivial amount of time, time that Robert was unwilling to spend on it. Being unmaintained, it followed the path of so many other unmaintained bits before it; it was dropped.

If someone steps up to create a new AutoPackage and shows some dedication for maintaining it, I’d be very willing to put it back up on our download page.

Have you looked at PackageKit?

Well, I never touched PackageKit yet, but it does look very promising indeed for plugins, dictionaries, templates and other complimentary add-ons.

Living off Abiword? How many get paid? For specific features? Is any commercial contributor involved?

Noone is living off AbiWord at the moment. In 1999, AbiSource Inc. tried and failed to do just that. Ofcourse, they had the problem of starting from scratch with nothing of value to offer for a while. Eight years later we have a solid product that from time to time generates corporate support requests. Any AbiWord developer that is interested in taking up on the offer is encouraged to do so. Besides doing the specific OLPC adaptations, our mail-merge feature and command line based printing options are both developed under contract for example.

For a long time some of us been toying with the idea to create a legal entity to direct all the corporate support requests to. It didn’t really get anywhere up till recently, when we came up with the idea of offering additional services around our real time collaboration technology. We hope to announce our services and plans within the next few months.

Any parting comments?

I’m really happy to see AbiWord 2.6 being as well received as it has. Since it was so long in development and everyone seemed to be too busy to do some development releases, we (or at least I) totally lost track of the quality of it all. Various people all over the internet even declared AbiWord to be dead as a project :) In the end, I just ended up tagging trunk on a rainy weekend and declared that 2.6.0 was done. I won’t go as far as some people by claiming (almost) feature parity with OpenOffice.org Writer, I’d say it turned out to be a pretty solid release. Stay tuned for the upcomming 2.7.0 development release. It will feature Annotations and it will finally have proper Smart Quote support!

Another new feature introduced by Satellite 5.1 is multiple organization support. This feature allows you to partition your Satellite into different organizations, each with their own subscriptions, systems, and content. It provides Satellite administrators with a new way to control user and system access to resources on a Satellite server. For more details on multiple organization support, please refer to our whitepaper: RHN Satellite 5.1 Best Practices for Multiple Organizations (PDF download, ~700KB).

The Satellite Team would like to learn how we can improve this feature to better suit your needs–and we need your help.

We’ve put together a survey to figure out how we could make the multiple organization support feature more useful for you. You do not need to have made use of the multiple organization support feature in order to fill out this survey; all you need is experience working with a Satellite. The survey presents some details about how the new feature works and asks for you to talk about how different parts of it may or may not fit your organization’s needs.

The survey also has a lot of free-form questions. Depending on how many questions you choose to answer, it may take between 15-40 minutes. The Red Hat Network Satellite Team will use the information collected in this survey for future improvements of the Satellite product. We won’t share this information with any third parties without your consent.

We would really appreciate any feedback you might have time to give. Your feedback will have a direct impact on the future development of this feature. Here is a link to the survey:

RHN Satellite Multiple Organization Support Survey

Thanks for helping us make Satellite a better product!

The Red Hat Network Satellite Team

Over the past year, the OOXML debate launched a worldwide discussion about what an open standard should be, how it impacts the technology industry, and why open standards are important.

Last week, OOXML–an XML format designed for Microsoft’s office suite–was approved as a standard by the International Organization for Standardization (ISO). In past articles^{1 2}, we have discussed problems with voting irregularities, the use of a fast-track process without adequate industry review, proprietary Microsoft technologies used without specification, and other problems. Now that OOXML has been approved despite these objections, let’s take a look at the standardization process and the impact that OOXML’s approval will have in the office suite space.

A credible process?

The OOXML debate has raised many concerns about the ISO standardization process, especially for fast-track standardization. Voting irregularities were reported in nearly one-quarter of the “P” countries that voted to approve OOXML. In a highly publicized statement, Norway requested to retract its vote. This compounds the issues raised in earlier rounds, such as new countries and technical committee members joining at the last minute in order to influence the vote, or incentives offered to Microsoft business partners to encourage them to vote for OOXML³.

Even without such irregularities, the ISO fast-track process was not designed allow adequate review of such a large and complex standard. Clearly, ISO needs to examine how such standards are approved, ensuring that they receive thorough and fair technical review, and that politics does not trump this review.

The fast-track review process used for OOXML required over a thousand technical issues be resolved very rapidly. It was simply not possible to adequately review these resolutions in time for the vote. Some of these issues clearly were not addressed well³.

Here’s one example: Microsoft’s date format incorrectly calculates leap year and days of the week for the year 1900, and cannot represent dates before 1900. Instead of fixing this problem, Microsoft added the standard ISO date and time types as another option. Thus, the same date can be on different weekdays depending on which date format is used to store it.

Life for open source after the vote

Microsoft still dominates the office software market. The European Union advised Microsoft to submit OOXML for standardization because it strongly favors open standards that allow it to safely preserve legacy documents and reduce vendor dependence. The adoption of OOXML as an ISO standard will help Microsoft overcome government procurement obstacles that it currently faces due to its proprietary formats.

However, the European Union has launched an investigation into Microsoft’s practices to influence the OOXML vote. It is not clear how this will impact European adoption of OOXML.

While open source advocates are understandably unhappy that OOXML was approved, the management and documentation of OOXML may have one positive side effect. Open source office software like Open Office or Abiword have long supported Microsoft’s proprietary binary formats, and the fact that these formats are now documented will make it easier to provide more complete support for them. And data in any XML format is easier to access and use in applications than proprietary formats.

However, there is still much work to be done. The OOXML standardization process has highlighted real weaknesses in the specification as well as in the ISO processes. We encourage the ISO to examine its procedures for standardizing software–especially the fast-track process–to ensure fairness, adequate technical review, interoperability, and compatibility.

That leaves, of course, the one big question: Now that there are two ISO standards for office document data, what does this means for ODF?

As the ODF Alliance said recently, “ODF will continue to be the document format of choice that best meets the needs of governments interested in ensuring access to their own information, now and in the future.”⁴

ODF is a simpler format that is easier to process, and less tied to legacy issues found in Microsoft office software. Open source office software is available for ODF formats. Red Hat, like many open source companies, will continue to support ODF and encourage governments to adopt ODF instead of OOXML.

¹ http://www.redhatmagazine.com/2008/03/24/iso-approval-a-good-process-gone-bad/
² http://www.redhatmagazine.com/2008/03/06/ooxml-why-the-debate/
³ For some further details, see http://www.odfalliance.org/resources/Oracle%20Technical%20Concerns%20DIS29500.pdf
⁴ http://www.odfalliance.org/blog/index.php/site/odf_alliance_statement_on_the_iso_vote_on_ooxml/

Things you can do

• Find an event near you.
• Find out if your software supports ODF.
• Get an ODF-supporting t-shirt.

Previous RHM articles about ODF

• OOXML: Why the debate?
• ODF: The inevitable format
• Spread the word, share this ODF artwork

You probably don’t lose any sleep worrying that your word processor is saving files in the wrong format. You may have some old files that don’t open correctly, or someone might have sent you a spreadsheet that doesn’t work in anything but Excel, but you probably found some way to work around the problem.

But when data is important and needs to be used in different ways or archived for a long time, the format really does matter. It all boils down to one question: who owns your data? If your data can be used in a wide variety of applications, you own it. If it can only be used cleanly with one vendor’s applications, that vendor is really the one with control.

This is why standards are so important. A complex standard that can only be fully implemented by one vendor does nothing to solve this problem, especially when the format was designed for only that one vendor’s data. This is the crux of the debate over OOXML, an XML format designed for Microsoft’s office suite, which was submitted to ISO for fast-track standardization as DIS 29500. This proposal will be accepted or rejected on March 29, 2008.

In this first article, we will examine the background of ODF and OOXML. Next week, we’ll talk about the ISO certification process and how Red Hat is participating in this effort. The final article will discuss the implications of next month’s OOXML vote for Red Hat and the FLOSS community.

ODF: An ISO standard for office data

The Open Document Format–or ODF (ISO/IEC 26300)–is an XML format designed to exchange office document data. Originally developed by Sun, it has been reviewed and developed by OASIS (Organization for the Advancement of Structured Information Standards) since 2002. ODF was unanimously approved as an ISO standard on May 3, 2006. The ODF specification is a little over 700 pages long, was created by an open process that involved multiple vendors, and has been implemented in a variety of products, including Open Office®, KOffice, GoogleDocs, IBM® Lotus® Symphony, and Macintosh® TextEdit. The ODF standard is the only existing ISO standard for office document data.

Because many government bodies mandate that standards be used, ODF has benefited greatly by being an ISO standard. Government agencies need to share information widely, so they want to create and save documents in a format that can be accessed by multiple applications. They also need to ensure that important documents like patent applications and legal contracts can be read long into the future – an important consideration when word processors have difficulty with documents only a decade old. By January 2008, several government groups—including twelve national and seven regional organizations–have adopted pro-ODF policies. Technology research firm Gartner estimates that by 2011, 50% of government and 20% of commercial organizations will require ODF.

ODF is a smaller and simpler specification than Microsoft’s OOXML. ODF was designed to represent office documents; OOXML was designed to represent Microsoft Office applications.

OOXML: A proposed standard for Microsoft Office Data

Microsoft has been using XML in some file formats since 2000, and they provided full support for exporting office data to XML in Microsoft Office 2003. These XML formats were designed by Microsoft for the exchange of Microsoft Office data.

Office Open XML (OOXML) is a further development of the formats used in Microsoft Office 2003. OOXML is not only complex, it can not be completely implemented without access to inside information. Although its specification is more than 6,000 pages long, it contains various references to things that are defined only in Microsoft’s software, not in the specification itself.

The European Computer Manufacturer’s Association (ECMA) submitted the DIS 29500 proposal, and in their disposition of comments, they note that:

“Many National Bodies requested more complete documentation for some legacy application compatibility settings in DIS 29500, such as ‘AutoSpaceLikeWord95,’ ‘truncateFontHeightsLikeWP6,’ and others. ECMA agrees with this comment, and will provide the full information necessary to implement all compatibility settings within DIS 29500.”

Although many such features are being deprecated for use with legacy software, it makes no sense to put deprecated features in the first version of a standard to allow one vendor’s data without explaining how other applications should process it. And this is just one of over 1000 unique issues that have been submitted by the National Bodies. There’s simply not enough time for ECMA to fully resolve all the technical issues with OOXML by March 29, let alone review the resolutions. Microsoft is hoping the delegates will approve OOXML anyway, on the promise of a future release of this information. But the standard that the National Bodies are being asked to vote on is the one in front of them, not something they hope will materialize some time in the future.

Where do we go from here?

The fact that there are several XML formats for office data demonstrates that people want to use data from their office documents in a flexible, open way. Red Hat supports ODF because it is a simple standard designed by an open process to support multiple products and has already been approved as an ISO standard.

We believe Microsoft should review ODF and identify any missing functionality so that it can be added to the existing standard before creating a completely new standard.

OOXML–despite its complexity–is not currently well-defined enough to be fully implementable. It would take a great deal of time to resolve all of the issues that have been identified, and the current ballot resolution process simply does not provide enough time to fix these issues and create a truly open standard that all vendors can implement.

Next week we will look at the ISO certification process and how Red Hat has been participating in the discussion.