Leading items

GNOME ponders its code of conduct

A wide-ranging discussion on the GNOME Foundation mailing list got rather heated at times, but touched on a number of different problems that many projects struggle with. The GNOME code of conduct (CoC) and how to keep the project's communication channels free of inappropriate content—including flamefests—was the topic, which makes it fairly ironic that a sub-thread descended into flames. While there was talk of voting on whether GNOME should leave the GNU project, cooler heads seem to have prevailed, so any vote on that is unlikely. The negative publicity that resulted from that proposal, however, led to suggestions that the mailing list cease being public—or that a private list be created—essentially keeping some portion of the foundation's discussion of its business out of the public eye.

The discussion sprung out of some complaints that the foundation board got about an inappropriate blog posting from a community member. Since many blogs of community members are aggregated on Planet GNOME (aka pgo), which is run by the project, inappropriate content could chase contributors away or reflect badly on the project. But the roots of the concern go back further than that. It was brought up by foundation member Dave Neary back in May, but it certainly wasn't new then either:

Not surprisingly, there are mixed feelings about having a "policing" role for the board. But, any kind of solution to the problem requires an understanding of what "inappropriate" means, and that's where the CoC comes into play. The code itself is pretty general, listing four things that community members should strive for:

• Be respectful and considerate
• Be patient and generous
• Assume people mean well
• Try to be concise

The overall intent is summarized in the code: "GNOME creates software for a better world. We achieve this by behaving well towards each other." Also unsurprisingly there seems to be little disagreement about the contents of the code, at least until some kind of enforcement enters the picture.

In November, partially as a response to the problem reported to the board, board member Lucas Rocha proposed that the CoC become "an official document that new Foundation members are expected to explicitly agree with before being accepted". But the CoC explicitly states that there is no "official enforcement of these principles", so it doesn't sit well with some that folks could just agree without there being a way to do something if they fail to follow it. Others, of course, complain that the CoC is far too vague to serve as any kind of guide for punishing violations. There are also those who think the problem is small enough that it could be handled on an ad hoc basis by the pgo editors, as Philip Van Hoof suggested:

Others are concerned that GNOME is losing community members because of the tone and content of Planet GNOME, mailing lists, and other channels. Would a more formal enforcement section of the CoC—like the one proposed (and later withdrawn) by Jason D. Clinton—actually help keep those members? Or would it just lead to a different set becoming disgruntled with the "rules" and leaving because of that? Those are difficult questions to answer. It is also unclear how many people have been put off by inappropriate behavior rather than having left because their interests or employment changed.

Most seemed to be reasonably comfortable with enforcement being left as it is. There are some obvious problems—porn or spam were mentioned—that will be dealt with immediately, any others will be left to the discretion of pgo editors, community members in mailing list threads, and/or the board.

For Planet GNOME, though, there is a great deal of content that falls well within the CoC, but might be objectionable for other reasons. The site is set up to be "a window into the world, work and lives of GNOME hackers and contributors", but some are not that thrilled with non-GNOME content being posted there. There was discussion of various technical measures that could be taken: getting bloggers to limit their pgo aggregation to posts with certain tags, adding some kind of voting system to pgo that would raise and lower the visibility of posts based on their popularity, and so on.

Many current and former GNOME contributors post about their work on their blog and sometimes those posts refer to non-free software they are working on. That seems perfectly in keeping with the stated mission of pgo, but it didn't sit well with Richard Stallman: "GNOME should not provide proprietary software developers with a platform to present non-free software as a good or legitimate thing." He suggested several different options for how he thought the project should discourage those kinds of postings. That set off a firestorm.

Stallman is strident, and steadfast, in his opposition to non-free software—something that should surprise no one—but he tends to be generally polite in his email. Those who were upset by his suggestions were rather less so. Their position is that the Planet is following its mission and that none of its content is endorsed by the project. David "Lefty" Schlesinger put it this way:

Stallman disagreed, noting: "What it says [has] a substantial effect on what people think GNOME is all about." Eventually, Van Hoof proposed a vote on GNOME's membership in the GNU project, because he believes that GNOME members do not agree with Stallman:

Van Hoof eventually withdrew the proposal for lack of support, along with a recognition that GNOME's membership in GNU is largely symbolic. When Behdad Esfahbod pointed to the criteria for GNU software, Luis Villa noted that "we've always ignored about 90% of this page with no ill effects for either us or GNU." GNOME and GNU have broadly similar goals, but overall are not closely aligned. Villa continued:

The proposal to leave the GNU project did hit Slashdot and other outlets, though, which was seen as a bit of negative publicity the project could just as soon do without. Esfahbod proposed closing the mailing list to members only, but later amended that to propose creating a new private list. The consensus seems to be against the proposal, citing decision-making transparency as a desirable feature for GNOME. Murray Cumming pointed out that hiding the discussions will not solve the problem:

Supporters of the idea point out that other projects do have some private lists, and that allowing non-members to post can just derail the conversation—much as Stallman and others did. Clinton describes the need for a private list as follows:

One worry is that either all the conversations would migrate to the private list, reducing the transparency of the project, or that all would stay on the public list, which would make the new list moot. Sometimes projects need to struggle with issues, doing so in the open may not make for the best press, but it may make for the best decisions. As Miguel de Icaza put it:

This is not the first time GNOME has struggled with some of these issues, nor is it likely to be the last. There is much for other projects to consider here: content of aggregation sites, codes of conduct and what to do if they are violated, project transparency, and so forth. We are lucky in many ways that GNOME did have these discussions in the open. Other projects may make other decisions based on what has been discussed here, but the recent threads certainly will provide much in the way of food for thought as those decisions are being made.

Comments (21 posted)

Openmoko's WikiReader

Openmoko, the company that first gained attention for its Linux-based phone platform, launched a new pocket-sized open source product in time for this holiday season, the WikiReader. The WikiReader is an inexpensive ($99), low-power, 4-inch square touchscreen LCD display device pre-loaded with the text of three million Wikipedia pages on a microSD card. In the smartphone era, skeptics might dismiss the device as woefully underpowered, but to the open source community the more pertinent question is what else can it do?

Unboxed and unconnected

Physically, the WikiReader is distinctive; its square shape is easily hand-held, but stands out from mobile phones. It is white, which suggests the industrial design of e-Ink book readers, but the hardware interface is minimalist: power button on top, and three hardware buttons on the front, "Search," "History," and "Random." The screen is a monochrome LCD display with 240-by-208 pixel resolution and no backlight, but it is also a capacitive touchscreen, used for the on-screen keyboard when searching, selecting links, and scrolling through articles.

The device is very lightweight, slim, and at this size easily fits into a shirt pocket. It is available for purchase directly from the WikiReader web site, and from Amazon.com. The housing is not particularly tough, however, more akin to remote-control-quality plastics than the sturdier-walled materials on a cell phone or GPS unit, so the careful buyer might keep on the lookout for a padded PDA case of some sort to absorb abuse.

Inside, the device uses an Epson S1C33 32-bit RISC CPU, 64KB of Flash ROM, 32MB of RAM, and a user-accessible microSD storage card. From the factory, it ships with a 4GB card, although other sizes are supported. For the curious, a debug connector is also accessible from the battery hatch. Power is supplied by two AAA batteries, which Openmoko claims will last 12 months given an average of 15 minutes usage per day. There is no other connectivity; no WiFi, no USB.

The content is a subset of Wikipedia's English-language text (no "adult" content; other omissions are not described). Naturally, given the display characteristics and storage, the 4GB card contains only article text; estimates put the total size of Wikipedia at 72 terabytes.

In use, the WikiReader always starts up on the search screen. Typing in a word on the onscreen keyboard pops up a match-as-you-type list of matching articles; the user can click on any of the links as soon as the right article is found. The History button brings up a clickable, scrollable list of recently-viewed articles, and as expected, the Random button loads a random page, almost instantly.

4 gigabytes of content is nice, but Wikipedia is constantly changing and growing. To handle this situation, Openmoko offers two choices: downloaded updated microSD card images (for free), or buy a subscription service, through which the company will mail a new microSD card semi-annually, for $29 per year. On top of that, naturally, the user also gets to collect the old microSD cards for use elsewhere.

A pocketful of information

In spite of the hardware limitations — many of which only seem like limitations in comparison to always-connected, touchscreen mobile phones — the WikiReader is remarkably fast, and despite being only a portion of the total Wikipedia, the amount of content is overwhelming. In fact, for looking up answers or information in a pinch, it easily beats connecting to the Wikipedia site over a mobile data connection.

The only real weaknesses are in the interface itself. First, the search function only matches the beginning of an article title, not the middle, and not full-text search. This can be a usability impediment in two ways; first by requiring the user to know the exact title of the article, and second by forcing the user to type extremely long titles (such as any "List of ..." pages). The latter issue is made worse because the on-screen keyboard is tricky to use. It is a QWERTY layout, with each key less than 5mm wide and 6mm tall. Additional space is taken up by non-sensitive black borders around each key, shrinking the target area.

As several blog reviews of the device have noted, although the history function is convenient, it would be greatly improved by a way to bookmark particular pages, and perhaps forward-and-back navigation buttons. Others have noted that the LCD screen can be difficult to read under poor lighting conditions due to the lack of a backlight.

More substantial criticisms tend to revolve around the guts of the device specifications itself, comparing it to considerably more expensive devices like e-Ink book readers and phones. Indeed, there are ways to access Wikipedia content on these devices (even offline), but the comparison misses the point Openmoko is shooting for. The WikiReader is intended for use in the offline world; it is not an underpowered Wikipedia browser or ebook reader, it is a pocket-sized reference encyclopedia. One that can be updated, for free, and uses free content. On those merits, the WikiReader is indeed a success.

Nevertheless, given the device's pedigree in multiple corners of the free culture movement (Openmoko's dedication to open source software and hardware, and Wikipedia stance on content), there are other criticisms that deserve a closer look. Benjamin Mako Hill lamented the lack of editing features — correctly noting that Wikipedia's true openness stems not from the licensing of the content for reuse, but from the user contributions. The device could cache edits locally, he said, which could be uploaded from a PC when the microSD card was pulled for an update.

Hacking

Adding editability would require substantial software changes, of course. Fortunately, the source code is all available online in a Git repository. There is documentation for cross-compiling the entire system for the S1C33 architecture from a Linux system with GCC, descriptions for flashing the boot loader, and a description of the boot sequence itself.

At boot time, the device loads an executable from the microSD card (by default, one named KERNEL.ELF, although it is not a proper operating system kernel) that contains hardware and filesystem drivers that launches the wiki reader application itself. Holding down the "History" button when powering on causes the device to load CALC.ELF instead, a basic calculator application. Holding down "Search" when booting loads FORTH.ELF, a Forth interpreter that can load the calculator or a variety of test and diagnostic applications (all written in Forth) instead.

Replacing KERNEL.ELF on the microSD card with another correctly-compiled application allows the user to customize the software without danger of bricking the device by re-flashing. It also allows Openmoko to roll out updates to the product without requiring customers to step through an upgrade process: just swap out the old card, and swap in the new.

The simplest enhancements, however, might only involve adding more content such as Wiktionary or Wikitravel (after all, the name is WikiReader, not WikipediaReader), or replacing the content with alternate languages. The tool suite contains Python and PHP utilities to convert MediaWiki XML dumps into the compressed format stored on the card, including creating the article index. Adding or replacing MediaWiki-formatted content should be as simple as exporting the XML from the wiki and running the utilities. Several users have already undertaken this task for French and Spanish Wikipedia content.

A more daring hack would be altering the wiki reader application itself to support additional content types. David Samblas, having noted that the sample Forth applications include basic graphics support, has undertaken [article in Spanish] adding portable bitmap format (PBM) images to the reader. His test images are of dubious quality for some image types — such as photographs — but others, such as line-drawing maps, might actually be useful on the device. He has not yet posted code to add this feature to the reader.

What else the WikiReader hardware can be hacked to do is an open question. Browsing the Openmoko mailing list, it is clear that a lot of early adopters are already pushing the device. Because the reader has a built-in Forth interpreter (powering the wiki reading application and all of the "hidden" test programs), writing new Forth applications is probably where outside software development will begin. So far, though, there is not yet a set of complete Forth development tools, only the toolchain at Github that is used to build the factory software. In the short term, there is still substantial room for expansion of the feature set just within the confines of the default reader application. Where Openmoko takes the product line from here is more fun to speculate about; perhaps if WikiReader is a success, a higher-end version will follow.

For today, however, the product makes for a fun stocking stuffer for the family hacker. Openmoko is positioning the device in its advertising as a way to get content into the hands of the "75% of the world [that] is offline" — including people in airplanes or on beaches, and "most everywhere." The WikiReader certainly does that; several online reviews have praised its value in museums and tourist locations, where data plan charges would make a connected device prohibitively expensive to operate.

But Openmoko also praises the "important role" Wikipedia plays in people's lives and its goal of providing a free encyclopedia to everyone in their native language. Hopefully the WikiReader hacking community can make that a reality as well. There are hackable high-end ebook readers, including some with larger, nicer displays, WiFi and GSM connectivity, and more content. But they are also reportedly much more difficult to work with. WikiReader takes aim at a more modest target, and hits it.

Comments (14 posted)

Some thoughts on MySQL and Oracle

Your editor wishes to take no position on whether Oracle's acquisition of Sun Microsystems should be allowed to proceed by the European Union. Such a decision certainly involves a number of antitrust considerations which go beyond the free software community. That said, some of the positions being taken around this acquisition shine an interesting light on how parts of our community work.

Fear #1 is that Oracle will kill MySQL, which Oracle is said to see as a threat to its cash-cow relational database management system. One might respond that similar fears were expressed after Oracle's acquisitions of Innobase and Sleepycat Software, but that things have not turned out that way so far. One might say (as Eben Moglen has) that keeping MySQL healthy is in Oracle's economic interest. One might also respond that Oracle could arguably do more damage to MySQL by breaking off the acquisition and allowing Sun to simply die. But what is most interesting about this particular concern is the lack of faith it shows in our community's ability to cope with such an outcome.

MySQL is licensed under GPLv2; it is free software. It can always be forked; indeed, some groups have already done so. There is nothing Oracle could do about that. Oracle could stop developing the free version of MySQL; it could even release future improvements which are available only on proprietary terms. But all it can take from us is the stream of future development which (we assume) we would have otherwise had from Sun. We might wish we had some of those enhancements, but it is another thing altogether to say that we are entitled to them. Free software generally does not come with a promise of future enhancements; what it does come with is the freedom to make those enhancements ourselves.

To say that Oracle would kill MySQL is to say that our community is not strong enough to continue its development outside of Oracle. That suggests that MySQL never really was an independent free software project. MySQL users who believe that should be clear about the position they think they have put themselves in: in this view, they are users of a proprietary product which happens to put out its code under the GPL. If this code has no future without its supporting company, the fact that it is freely-licensed has relatively little value. But such a view essentially writes off the community that has built the amazing collection of free software that we use every day. We are stronger than that.

Another interesting claim is that MySQL's license is the problem. Richard Stallman signed his name to a letter which expresses this worry:

The "more flexible license" in this case would be to add the "or any later version" language to MySQL's GPLv2 license. This statement looks like an attempt to push a license change onto MySQL, based on the assertion that GPLv2 somehow inhibits community contributions. Your editor is unaware of any study showing that developers are less willing to contribute to GPLv2-licensed projects; if such a study exists, it could certainly benefit from wider exposure.

That is not the only attempt to use this situation to bring out regime change on the licensing front, though. Consider Monty Widenius's "Help saving MySQL" post from December 12. He is asking readers to send messages to the European Commission; suggested text is helpfully provided. It includes:

Back in the days of MySQL AB, Monty and others were happy to put the GPL onto the MySQL code. It allowed them to release the code freely while building a business around selling proprietary licenses to companies which did not want to be bound by the GPL's terms. But the right to engage in this kind of business was sold to Sun with the company. Now Monty would like to get it back so that he, too, can sell proprietary versions of the software. This certainly looks like a bit of a request to have his cake and eat it too; it is not surprising that some observers have not been entirely impressed.

What we are really seeing here is the logical outcome of the corporate-controlled open source project model. Such projects may well create an external development community, but that community tends to be weak compared to well-established, independent projects. Additionally, the use of copyright assignments - common with company-owned projects - puts control of the entire code base into a single company's hands. As Eben Moglen noted in his submitted opinion on the acquisition, the single ownership of the MySQL code is part of the problem:

Anybody who has dealt with corporations for any period of time has probably learned one fundamental lesson: the company that one deals with today may differ significantly with the company one encounters tomorrow. Even in the absence of acquisitions, corporations tend to be just one bad quarter away from a total change of attitude. Being acquired will almost certainly change a company's approach to a project it owns - especially if that company is the sole copyright owner for the code in question.

Developers who contribute to a corporate project should be aware that they are signing their code over to an entity which may take a distinctly unpleasant turn tomorrow, regardless of how friendly it seems today. Users of this type of software should be aware that they cannot count on any promises which do not exist in a signed agreement with the owning company. The only exception is the license that the existing code is released under: that will not be going away. For a lot of MySQL users, the GPLv2 license is a more than sufficient promise for the future. Companies which have based products on the availability of affordable "GPL exception" licenses will be on less certain ground - though it is worth noting that Oracle has promised to extend those licenses for at least another five years.

Users of PostgreSQL (for example) need never worry about a takeover by Oracle or any other company; it is an independent project which will never be controlled by a single organization. Users of MySQL probably need not worry either; it is a well-established project which should survive a shift to a more community-oriented mode of development, should such a shift prove necessary. But the worries about this acquisition - at least, those which are not motivated by personal agendas - shine a light on what can happen with software which is controlled by a single organization. Being used as a political football in a regulatory fight, with all the associated uncertainties, is just one of the risks involved.

Comments (46 posted)