LWN.net Weekly Edition for October 16, 2008

OpenOffice.org releases 3.0, faces new challenges

A new version of the popular free software office application suite, OpenOffice.org (OOo) 3.0, was released this week to lots of press and enough download traffic to bring down its webserver. While the release isn't a huge leap forward in terms of features, it does provide some compelling enhancements. Perhaps the most interesting is the increased focus on extensions, a la Firefox, that don't require modifying the core OOo code. This may help combat the problem—or perceived problem—that Sun is stifling OOo development through its bureaucratic procedures for adding new functionality.

The first thing one notices when starting up OOo 3.0 is the new splash screen, but it appears for only a short time. One of the major complaints about the suite has been how long it takes to start up—something that has been addressed in 3.0. The application opens to a new welcome screen (seen at left) that presents a more friendly appearance, rather than an empty window, for new users. Once past that point, the various tools look much as they did in OOo 2.4 and earlier versions.

The other changes are mostly under the covers; they will be noticed by power users, but are not immediately obvious to basic users. These include:

• Writer (word processor) has a new slider for zooming
• Writer allows multi-page display and editing
• Calc (spreadsheet) allows up to 1024 columns per sheet
• Draw (drawing) can handle poster-size files
• Impress (presentation) supports multiple monitors for presentations
• Writer has additional editing modes for multi-lingual support as well as wiki document editing
• Calc has a new equation solver
• Chart (graphing) has improved graphical output

The OOo extensions repository has many different kinds of add-ons for OOo, that provide new or enhanced functionality for users. The most popular is the PDF import extension which allows loading PDF files into the application for editing. Given that OOo has long had the ability to natively export PDFs, importing them is an excellent addition.

Clearly Sun and the OOo project see extensions as a fertile ground for innovation by folks who are not necessarily OOo "contributors"—as they have not signed the Sun Contributor Agreement (SCA) [ PDF, currently unavailable due to the download traffic problems ]. Sun's community manager for OOo, Louis Suarez-Potts, puts it this way:

One of the new features that OOo developers are most excited about won't affect Linux users at all. OOo 3.0 has a native Mac OS X look and feel, rather than the earlier X11-based interface. A native Windows version has always been a part of OpenOffice (and its precursor, StarOffice), but the new default theme is said to be particularly attractive on that platform.

There are various new features aimed at those currently using—or needing to interoperate with—Microsoft Office. There is support for Access database files as well as improved Visual Basic for Applications (VBA) macro support. Somewhat controversially, OOo 3.0 has added the ability to read (but not write) Office Open XML (OOXML) files. OOXML is the newly minted standard for office documents that Microsoft and Ecma pushed through the ISO standardization process earlier this year.

Support for OOXML is one of the contentious areas surrounding OOo. There are two (vocal) developer camps, one Sun-centric, the other Novell-centric; unsurprisingly they tend to clash over OOXML as well as development pace and direction issues. It has gotten to the point where a fork, called Go-OO, has come about, led by Novell's Michael Meeks. Go-OO's version of OOo has been adopted by several distributions leading some to see it as a "hostile" fork.

Sun's chief open source officer, Simon Phipps, clearly sees Go-OO (and the related OO-Build) as an attempt by Novell to control OOo:

Meeks most recent look at OOo development is the proximate cause of much of the current sniping in various blogs. Meeks analyzes commits to the OOo codebase to try to extract trends in the development of the tool. His conclusion is stark—undoubtedly inflammatory to those in the Sun camp—"Crude as they are - the statistics show a picture of slow disengagement by Sun, combined with a spectacular lack of growth in the developer community".

While there have been various responses to the analysis—including this LWN comment thread—there has, as yet, been no real counter-analysis that comes to a different conclusion. Perhaps there are other ways to slice and dice the data that look more favorable to growth in the OOo community, but if not, the conclusion is worrisome. OOo is a very useful tool, that is used by many, which offers a way out of Microsoft lock-in. Because of Novell's close association with Microsoft, people worry that Go-oo is an underhanded means for another kind of lock-in—this time to Novell.

In what seems almost a taunt—as well as a validation of the accusation of a hostile fork—Meeks adds a postscript to his analysis:

There have long been complaints about the pace of OOo development, along with calls for creating a foundation to oversee it. It would seem that OOo is at a bit of a crossroads. If Sun's commitment is reduced, without a corresponding increase in contributions from others, OOo could stagnate—or Go-oo could take over.

Ostensibly, the SCA is one of the sticking points for some contributors. They do not trust Sun not to take their contributions in a proprietary direction. But the conflict is really rooted in issues of control and development direction—two things likely to lead to forking. While two forks is suboptimal, perhaps, it may lead to improvements in both the code and the development process for OOo.

There are legitimate concerns on both sides of the issue—undoubtedly the mostly silent user community has yet another perspective—but there is enough bad blood between them that it is hard to see it resolving in some relatively amicable way. The office application suite is an extremely lucrative product, at least in the proprietary world. One gets the sense that both Sun and Novell are seeing dollar signs which are clouding their vision. A neutral foundation of some kind might be a good first step towards reconciliation.

Comments (33 posted)

LK2008: Embedded and Mobile Linux

Linux-Kongress 2008 attendees had the opportunity to hear two different sessions dedicated to organizations trying to improve the state of Linux support for embedded and mobile systems. They have similar goals, but are taking different approaches and have different levels of resources available to them.

The first of these is OpenSourceEmbedded, presented by uClinux developer Jeff Dionne. He opened with a statement that, ten years ago, Linux-based embedded systems were nearly unknown. Now those systems are everywhere, with hundreds of millions of deployments. Embedded systems, he says, make up the largest installed base of Linux systems.

All is not perfect, though, in the embedded sphere. Linux still has an uncomfortably large footprint for embedded use. There is also no unified distribution for embedded use; instead, the industry is full of homemade solutions made by vendors. He would like to address this situation through the creation of a next-generation platform. It would take the form of a kit that developers could start with which comes equipped with design examples for a number of applications: telephones, digital video recorders, etc.

There are two hardware platforms being targeted initially by this effort. One is a Plasma MIPS processor - a very simple device which can be implemented with an FPGA. A simulator for this processor runs about 600 lines of code. The other, more advanced platform is a LEON 2/3 SPARC processor, a full system with a memory management unit and which supports multiprocessor configurations. Examples of the first processor include a RealTek MIPS system, while the LEON SPARC CPU is similar to current SuperH 3 processors. The Plasma and LEON SPARC processors are being designed now, with the intent of producing them as open hardware designs.

On top of these processors will be a base operating system layer with a "mini-POSIX" environment. There will be an interesting packaging system which stores components as separate "blocks" in flash, outside of any filesystem. The running system will be assembled from the blocks by the boot loader. This organization is designed to avoid bricking; any bad or corrupted components can simply be bypassed without affecting the functioning of the rest of the system. This, evidently, is how PalmOS did things.

The next challenge is creating a community around this whole effort. To that end, resources are to be put up at opensourceembedded.org - though nothing is available as of this writing. The site will include project hosting, along with the ability to download the development kits. Jeff says that the uClinux experience has shown that the kit approach works; with a ready-to-use code base like that, a community can come together.

There are also plans to create an organization behind this effort which, among other things, can enter into non-disclosure agreements with hardware manufacturers. This organization will also work to help vendors ship GPL-compliant products.

OpenSourceEmbedded appears to be in an early state, so it's hard to make any guesses about how successful it will be. For more information, see Jeff's slides [PDF].

Mobile Linux

The closing session at the 2008 Linux-Kongress was a talk by Dirk Hohndel, who began by noting that Linux-Kongress is, in fact, the oldest Linux event. It was first held in 1994, and hosted many of the kernel developers who were active at that time; Dirk estimates that about half of the development community was to be found in a single room. It would take a rather larger room to accomplish that now. Dirk complimented the event on its avoidance of commercialism and its sustained focus on the technology.

The technology that Dirk came to talk about was mobile Linux. He started by expressing his disappointment with desktop Linux. It has become a collection of poorly-integrated applications which are somehow trying to replicate Windows 95. The result does not work well on the desktop, and it most certainly is not optimized for the mobile environment.

But, says Dirk, mobile Linux is not really embedded Linux either. Embedded Linux evokes images of access points and other single-application boxes which are not meant to be extended past a single function. They are not concerned with the user's experience, and they are not concerned with mobility. The subject here is devices with a screen, and which can have new applications installed onto them. So some sort of desktop-like interface is needed, but current desktop Linux does not fill the bill.

According to Dirk, the problem with desktop Linux is the fundamental approach: developers are not the target audience for this software, but they are making all the interface decisions. What's needed is input from people who are specialized in interface design and human-computer interaction. That leads to a "scary thought": interface specialists are generally not coders, but they will be making decisions that coders are expected to implement. That is not a normal mode of operation in the free software community, but it is needed here.

Other problems include the proliferation of "80% done" projects. Much of the work has been done, but nobody wants to do the work to finish the job. There's also far too many choices; in general, says Dirk, people do not like it if they have to choose between more than two alternatives. When dealing with the Linux desktop, it's hard to find situations where there are fewer than six choices. And, overall, the Linux desktop lacks consistency. That, says Dirk, is why he uses an Apple laptop. Apple enforces a consistent design across the application space and, he says, the result is very nice.

Devices should be simple and natural to use; such devices are increasingly hard to find anywhere. As an example, he held up a paper notebook. The device boots very quickly, has a nice "touch-based" pencil-oriented interface. No manuals or explanations are needed. Linux-based devices should be just as easy to use. But, at the same time, they need to offer an experience which is close to what people expect from an ordinary, desktop computer. It should have access to the Internet, and users should be able to install software.

Dirk then pulled out an Eee PC system and gave the five-second boot demonstration. This work, he says, is an example of what is being done by Intel in support of the Moblin project. Intel is trying to solve some of the hardest problems in the mobile space, contributing the results for everybody to use.

To that end, Moblin is working toward the creation of a base distribution for mobile systems. The user interface will be based on the GNOME mobile work, but with a lot of enhancements. The end goal is the creation of a Linux distribution for mobile devices which is far better than the state of the art today. It is not, he says, an attempt to compete with distributors; instead, Moblin is providing a base which the distributors can build on. Intel's effort will naturally focus on Intel processors, but contributions for any architecture are welcome at Moblin.

In conclusion, Dirk noted that Linux's success on the server side was relatively easy. The mobile problem is much harder. Intel is hoping that others will join in to help Moblin reach its rather ambitious goals.

Comments (6 posted)

Fedora checking community health with EKG

Measuring the health of communities is an interesting, difficult task. The Fedora project has recently started using a new tool, called EKG, to try to get an overview of the demographics of the free software projects that are sponsored by the distribution. EKG is still young, but already provides some interesting information. Because it is GPL-licensed, as is the Fedora norm, it can be picked up by other distributions or interested parties to target their own projects.

At its core, EKG is a few Ruby scripts that process mailing list data so that graphs can be produced. Currently, it produces both pie charts and line graphs that indicate the number of Red Hat posters versus those from elsewhere. A portion of the most recent set of graphs can be seen at right.

Red Hat's Michael DeHaan has taken on development of EKG to use as a tool to measure how well various projects are building a community separate from Red Hat. There are lots of free software projects that have been released by Red Hat—or Fedora, which often amounts to the same thing—but may or may not be seen as useful tools outside of Fedora. By looking at the mailing list traffic, particularly over time, some idea of which projects are building a community, and which aren't, can be derived. As the project page puts it:

Mailing lists are just one measure of the health of a project, of course, so DeHaan is looking at other metrics. Commits to the project repository—along with the identities of the commiter—would seem an obvious choice. Better graphs with more useful information on each axis as well as time series of the pie charts are also on the "to do" list. He is also looking at derived statistics that will allow direct comparison of different projects by using equations that in some way model success.

It is difficult to draw any conclusions from the limited graphs that are currently available. One thing that does stand out, though, is the popularity of gmail.com email addresses, which seem to account for around one-quarter of posts. One can also certainly see projects that are completely dominated by "inside" (i.e. Red Hat) folks. The JBoss lists are a good example.

Projects are trying various ways to measure how well they are doing their job; EKG is another way to do that. For the kernel, the statistics on each release are gathered by LWN, as well as over longer periods by the Linux Foundation. Ubuntu has its Upstream Report which looks at how well bugs are getting to upstream bug trackers. Undoubtedly other projects have their own ways of trying to measure their impact.

As yet, there is no mailing list for EKG development. We look forward to the day when EKG is applied to its own development list. It would seem that some kind of "metahealth" measurement of the community might be able to be derived from that data.

Comments (none posted)

LK2008: The values of the Linux community

The opening keynote speaker for the 2008 Linux-Kongress was James Bottomley, who presented his views on the Linux community's values. What these values are, says James, is not entirely obvious. Related groups - the free software community, for example - have well-articulated value systems which define them. The Linux community's values are not so clearly expressed, but, he says, they are central to what we do.

James started with a bit of history, noting the the initial value placed on software was entirely commercial. Once the industry realized that software could be worth far more to its users than it costs to create, the proprietary mode became dominant - and that has affected the evolution of programming in general. The value placed on the code by its developers became irrelevant, leading to "paycheck coding." There is no value placed on creativity, and such a model leads to bad code.

Eventually Richard Stallman came along and challenged the commercial view of software. But, during this time, about the only alternative to commercial software was the BSD Unix distribution, and that got caught up in the lawsuit by ATT. So closed software took over; Windows won on commodity platforms, but proprietary software also became dominant in the Unix arena.

In 1991, Linux hit the scene; since then, it has become the most popular and vibrant free software operating system available. In a sense, this is interesting, in that Linux is licensed under the GPL, a license that many companies hate. Apple explicitly chose BSD as the base for MAC OS to avoid GPL-licensed code. But, despite this antipathy, lots of companies use Linux, and even contribute to its development. It is interesting, James says, to look at why that is.

The reason is the Linux community's values. In particular, the community prizes technical merit above all other considerations - including small things like what any company or user would like to have. Also prized is passion; code supported by a developer who clearly cares about it will generally fare better in the review process. If the code quality and the passion are there, the community does not care about much of anything else. Factors like the source of the code or who might benefit from its incorporation don't really matter.

In particular, contributors to the kernel are not required to sign on to any particular belief system or any specific view of freedom. A contributor may have an FSF-like belief in free software, or, instead, be a corporate developer who does not care about software freedom at all. Even the BSD community requires acquiescence with a specific view of freedom. A Linux contributor, instead, need only be willing to contribute the code under the share-alike rules of the GPL.

As a result, anybody can play with Linux, regardless of philosophy or corporate status. We have a community which is defined by contributions, not by a specific set of values regarding software freedom. That has allowed the formation of a very diverse community with a specific shared interest: creating the best kernel we can.

There are some significant benefits from this approach. It forces companies to recognize their engineers' values; that, in turn, makes for more motivated developers. Developers who are interested in improving Linux can get resources and support from corporations. Users get high-quality code from developers who care about what they are doing. Companies get the ability to focus on their little piece of the problem while taking advantage of the community-maintained kernel for the rest; they can also offload their older code to the community for long-term maintenance.

James compared the Linux way of doing things with the US constitution. That document only mentions freedom three times, yet it has become a blueprint which has supported freedom for over 200 years. It is a relatively short document. The proposed EU constitution, instead, is about 20 times the length, before taking into account other documents which are referenced. That document would appear to be somewhat bloated; the goals would be better served by a more concise formulation.

Similarly, the Linux community spends little time talking about freedom. Instead, the focus is on a set of brief principles involving code quality and passion. Freedom is not legislated; it arises as an emergent value inherent in the Linux way of doing things. Linux has managed to bring about software freedom without talking about it, and without imposing a view of software freedom on its contributors. In the process, Linux has succeeded in creating something which is as free - or more free - than the GNU system envisioned by the Free Software Foundation.

During the question period, James wished for a free software advocate who would argue the point with him, but no such person emerged. He will, it seems, have to repeat the talk in a different venue before he can have that debate.

Comments (49 posted)