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:
I have talked to too many people
who don't read pgo, or have turned off individual blogs, don't use IRC any
more, or avoid certain mailing lists, because they are unhappy with the
tone & content of discussions & posts. If someone is behaving in a way
which is negatively affecting a significant portion of the GNOME community,
the board should be the place to go where you can complain, and have your
complaint publicly recorded (in the minutes of a board meeting, for
example) with anonymity, investigated and evaluated, and if necessary, have
the guilty party censured and/or punished. Currently, this social policing
role has been completely ignored by the foundation and its leaders.
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
" 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:
My opinion is that incidents like this can be better managed by asking
the maintainers of the planet to do editorial control, and to not shun
away from skipping blog posts.
I think this could use some guidelines (for both the bloggers and the
planet maintainers who for example could inform the blogger about their
decision, allow the blogger to adapt his text, etc).
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
Planet GNOME is not presenting anything as anything. It does
not have an editorial stance to espouse, nor a political position to
promote. It's about people, not polemics.
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:
I understand your position. I think you might not understand the
position of a lot of GNOME foundation members and contributors.
Their position isn't necessarily compatible with your position that
GNOME should "avoid presenting proprietary software as legitimate".
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:
Which is really my position on the whole thing: the adults in this
project have always treated requests from GNU the same way we treat
requests from any other community member- if it makes sense, we do it;
if it doesn't make sense, we ignore it.
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:
You cannot stop silliness on the internet. If you try to hide things
then you'll just make the hidden information seem even more interesting
and you'll have to argue with random unrepresentative public statements
without the benefit of pointing people to the archives for the facts.
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
This is about signal-to-noise ratio,
not about keeping secrets. It doesn't matter if someone leaks the
discussion; in fact, we should always behave on -private as though it
could and should happen. It objective is to cohesively attain consensus
amongst ourselves without constant, distracting nit-picking by others
whose weight of opinion is not as equal as ours.
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:
Raw community discussion is like a kitchen, it might not be pretty,
but what counts is the result. We should be proud of the software that
we create, how we got there, and the fact that we have nothing to hide.
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, 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.
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
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
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
Comments (14 posted)
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
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
Many other FLOSS software projects are expected to move to GPLv3,
often automatically due to the common use of the "any later
version" clause. Because the current MySQL license lacks that
clause, it will remain GPLv2 only and it will not be possible to
combine its code with the code of many GPLv3-covered projects in
the future. Given that forking of the MySQL code base will be
particularly dependent on FLOSS community contributions - more so
than on in-company development - the lack of a more flexible
license for MySQL will present considerable barriers to a new
forked development path for MySQL.
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.
That MySQL should be released under a more permissive license to
ensure that forks can truly compete with Oracle if Oracle is not a
good steward after all.
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:
The crucial issue is not the license under which MySQL is
distributed, although GPLv3 might be preferable to GPLv2 if one
were writing on a clean slate. Rather, the central issue is an
increase in the copyright diversity of the project, in which
multiple parties have significant code in the main line. This would
be sufficient to prevent anyone having an exclusive right to make
proprietary enhancements or to undertake distribution under
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
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)
Page editor: Jonathan Corbet
Next page: Security>>