Instead of the talk he was planning to give on the first day of
presentations at GUADEC, GNOME release
manager Vincent Untz needed to shift gears to announce the biggest news of
the conference: GNOME 3.0 would be delayed. The reason for the delay is
simple, the code and documentation "weren't quite ready", so
rather than have an "OK-ish" release, the team decided to push
it back. There will still be a release in September, however, as the team
the six-month release schedule, but it will be another in the 2.x series: 2.32.
Untz noted that GNOME 3 has a compelling story: "It's the first time
since I started with GNOME that people are so excited about GNOME".
GNOME 3 was first announced at GUADEC in 2008 with a target of making the
2.30 release (i.e. March 2010) be the first GNOME 3 release. In the
was pushed back to September, and now to March 2011. The team has
"quality as [its] first priority" and, after meeting with
various teams in the first few days of GUADEC, it became clear that more
time would be required for a solid release. "We want people to love
GNOME and we want people to love GNOME 3", he said.
In addition to the 2.32 release, there will also be a GNOME 3 beta release
in September. "We want people to start using it, start playing with
it, application developers to port to GNOME 3". By March, "we
want something that's really good", Untz said.
But that means developers and maintainers of GNOME modules will need to
work on two branches for the next two months: one for 2.32 and one for
3.0. That dual-branch development mode made up most of the concerns expressed by audience members about the
announcement. Some were worried that it would cause too much extra work,
but Untz and the release team—who joined him on the
stage—seemed to think it was manageable.
The release team will be taking steps to ease the transition, starting with
getting GtkApplication backported to GTK+ 2, which will help modules that
switch back from GTK+ 3. There will also be a flag (--enable-gtkN)
available in the configuration process that will allow applications to be
built for either GTK+.
Some maintainers will want to deliver new features
in September and for those, the 2.32 and 3.0beta releases will be the
same. Others may want to focus on 3.0 and will just release an update to
2.30 with bug fixes and the like. Separate from his talk, Untz said in
each maintainer will decide how to handle it and the release team will
assist: "we do not think it will be that much of a burden".
He also noted that GNOME's development model, by design, is focused on
rather than revolution", and that 2.32 would fit that model well:
addition to new features in the existing modules, we'll integrate
gnome-color-manager and rygel. That means that GNOME 2.32 will be our
first release to have integrated color management, as well as support
for DLNA (UPnP AV) for a rich multimedia experience at home, with all
the connected devices that people now have (TV, speakers, phones, video
game consoles, etc.)
Certainly GNOME Shell is the most high-profile module that is still in need
of work, but there are others as well. There are still a lot
of applications that need migrate to GTK+ 3 and GSettings, for example.
Updating the documentation for GNOME 3 still has a ways to go, "the new accessibility stack would get performance improvements that
will make the switch to the new stack much smoother for users",
the GTK+ engine for the art team's new theme is not quite ready, and so
Interestingly, most of those issues, when taken separately are not
blockers per se. But the addition of all of them would have lead to a
quality that is not up to our standards.
There are some other things the release team will be pushing, he said in
his talk, including encouraging the maintainers to "target achievable
goals". In particular, there will be something like a feature
freeze for the GNOME Shell functionality so that they finish what they
started and don't go off "making crazy plans". In addition,
the release team will be trying to get the community to implement the UI
mockups that the design team has created.
There has been some criticism of the GNOME 3 plans because of the lack of
support for "applets", but Untz sees it differently. Most of the applets
in use today are either things that will be incorporated into GNOME Shell
or are some kind of monitoring tool (for system performance or email for
example). There are also a few applets that are "dedicated to a
task", like the Tomboy notes applet or the Hamster time-tracking
applet, he said.
We don't believe that the system we have today with applets is the right
approach: the size of applets is limiting the user interface, and the
current number of existing applets probably show that applets are not
an attractive way for developers to extend the desktop. In addition, a
few applets are actually slowly moving to full applications (tomboy and
hamster are good examples). This is why we won't add support for applets
as we know them today.
There are plans to look at a system to replace applets some time after the
GNOME 3 release, but it is not the team's highest priority at the moment.
There are alternatives, though:
It's also worth mentioning here that the traditional GNOME 2 UI (with
the GNOME Panel and applets) will still be available with GNOME 3, so
people who have a need for a very specific applet will still be able to
use the GNOME 2 UI for some time.
Overall, the announcement was met with general approval from the audience.
The project wants to make a big splash with GNOME 3 and "OK-ish" is not the
way to do that. There seems to be a clear focus on the things that need to
be completed before there can be a solid release, so one gets the sense
that we won't see further delays. For users who can't wait, there are
plans to make the beta more easily available for various distributions,
which should allow more testing and a better final release.
Comments (28 posted)
The Free Software Foundation (FSF) has recently turned its attention to
accessibility. The organization appointed
Chris Hofstader as director of access technology in May, published a statement
addressing accessibility, and started an accessibility
list to discuss accessibility work. Now the organization is faced with
the question of how to bridge the gap between free software and
accessibility without an interim solution.
Despite decades of hard work, the unfortunate reality is that free
software does not meet the needs of all users. In particular, free software
is still well behind proprietary software in providing tools for developers
and users who require assistive technologies. Some technology, like the Orca screen reader has come along
well, but users that depend on speech recognition software find themselves
without a reliable alternative. This isn't new information, but a recent
conversation on the GNU Accessibility list raised an interesting question:
What should the Free Software Foundation (FSF) tell users that rely on
assistive technologies that do not exist as free software?
One might expect that the answer would be to rely on proprietary
software when necessary, and until the free software bridges the gap. Where
the FSF is concerned, however, that doesn't appear to be an option. The
discussion began with a post from Hofstader
asking for volunteers to work on assistive technologies (AT),
documentation, testing, and so on. This prompted a response from Eric
S. Johansson, who said he'd "raise his hand" but with some caveats:
I believe strongly that the tools first approach you and others have
spoken of misses the needs of the upper extremity disabled. their primary
need is income. You can't have freedom of choice if you can't make
money. For example, today, if I want to make money, I must use
NaturallySpeaking. There is no choice and the speech recognition projects
available today or the near future are not sufficient to replace
NaturallySpeaking (I.e. they couldn't write this e-mail and they take way
too much time to set up).
I would propose organizing the project to first satisfy the economic
needs of the disabled community, so they can make money, they can be
independent and as a result, be able to make choices about software
The issue at hand is whether it's acceptable to create bridging tools
that would be free software but depend on proprietary tools, initially,
like Dragon Naturally Speaking. Johansson's request does not seem entirely
unreasonable. Free software speech recognition is not currently an option,
some users, the only way to use a computer effectively is with speech
recognition software. It's not a question of opting to use proprietary
software out of convenience, but necessity.
That, however, doesn't seem to be acceptable to the FSF. The issue,
according to Hofstader, is that endorsing a temporary solution that
includes proprietary software would "either postpone or entirely
scrap the development of a libre engine that we can endorse." To
protect users' freedom, Hofstader says that FSF/GNU cannot "take
anything away" by using a temporary proprietary solution. According
to Richard Stallman, it requires taking a long view rather than being concerned
about the short-term inability of users to work with their
In the long term, no software task inherently requires non-free software.
In the short term, there are proprietary programs that do things that free
software currently cannot do. There is no dispute about this fact. The
question is what conclusions to draw from it.
To draw the conclusion that we should grant legitimacy to those
proprietary programs tends to lead to more use and more development of
proprietary programs. It may seem convenient in the short term, but in the
long term it perpetuates the problem. It does this both directly and
indirectly: directly by encouraging the use of specific non-free programs,
and indirectly by pouring water on the fire of our movement to eliminate
Thus we must steel ourselves to refuse the sort of short-term
"compassion" that makes injustice and dependence worse. Work carried out
under GNU auspices must be consistent with our principles.
One wonders how a user's dependency on non-free software, when driven by
a physical inability to use conventional input methods, could be worse. If
denied the ability to work in conjunction with the FSF on the most pressing
concerns, the alternative seems to be that accessibility development work
will be carried on elsewhere. Johansson predicts
that in the absence of a GNU-led project, a non-free alternative is still
likely to emerge:
You failed on hurd because it didn't get done early enough to garner a
significant mind share. I'm predicting, if you follow this path, you will
fail because a hybrid or even a totally non-free approach will be developed
first and lock-in user mind share. the end result will be users will be
locked into less free software and there'll be no way for you to displace
This is reality. People are hurting and need help now. Not 15 years
from now. Now! let's apply steady pressure and free them up a bit at a time
and get them sold on the important freedoms the free software foundation
represents. At the very end, you ride to the rescue with a good recognizer
and they will be a complete solution in the shortest possible time. We will
have a working solution in the shortest possible time minimizing the pain
and suffering of disabled users. Seriously man, there are few better ways I
can think of to spend a life.
Instead, Johansson urges the FSF to accept a "compassionate exception"
that would allow interim solutions. However, the FSF seems unwilling
to consider such a measure. As a result, Johansson seems
to have abandoned the discussion and GNU Accessibility list as a whole.
The good news is that the FSF isn't the only organization working on
accessibility in general or voice recognition in particular. The GNOME Project has been
particularly active working on accessibility, though it has been affected by Oracle layoffs
recently. GNOME's Orca has
made tremendous strides as a screen reader, and is work is going on with
use Orca with Qt applications so Orca can be used on either
Those who wish to help with efforts to develop a free speech recognition
program should see the VoxForge
project, which seeks to collect transcribed speech for use developing free
and open source speech
recognition engines. There's also the Simon Listens
project to create an open source speech recognition program.
A hard-line approach of all or nothing is not going to appeal to or help
users who depend on assistive technologies, regardless of the licensing
they're under. Given the response from the FSF on this issue it would
appear that it is not going to be the right organization to lead the charge
for accessibility. The insistence of licensing purity while disregarding
the immediate needs of the target audience for the accessibility initiative
does not bode well for the FSF's leadership in this area.
Comments (35 posted)
There are many good reasons to promote a free software project, but perhaps
the biggest is to attract more users and contributors; it's difficult to
do anything with an
application that you don't know about. But many projects fail to
effectively get the word out about their work, which means that it's
less likely a community will spring up around it. At both SCALE
8x and GUADEC 2010, I have had the
opportunity to talk about ways that projects can improve their promotional
activities and present an organized, interesting look to the rest of the
free software world. Hopefully, a summary of the ideas presented will be
helpful to the wider community.
One of the key benefits of free software is the cross-pollination it
allows. Not only can users look at features in "competing" applications
and suggest that they get incorporated, but developers can dig into the
code to gain inspiration on how to implement or improve a particular
feature. Assuming compatible licenses, projects can even adopt code
directly from each other. But it goes further than that. Projects can
learn from each
other's struggles and successes in areas like governance, release
management, revision control, licensing, and so on. In order to cross-pollinate, though, projects need to be aware of each
It's also important for a project to attract the people it needs to
thrive. That includes users and their feedback, but also developers,
translators, artists, advocates, designers, packagers, etc. Not all
projects need all of those roles filled, but many do.
Another benefit of promoting a project is that it is something of a morale
builder for the existing project members. Seeing a blurb or an article
about a recent release, or some interesting news about the project can put
a smile on the face of contributors. While that may seem trite, keeping
project teams cohesive is a very important part of the puzzle, especially
for smaller projects.
Here at LWN, we get lots of email from projects, generally announcing a new
release or some other project status update. One of the most frustrating
things is the number of those that bear very little information
beyond the name of the project and a release number. There is often little
or no description of what the project is or does, nor very much detail
about why the release is being done. It often looks as if it were written
only for project members or others who are likely to already know something
about it, but those are exactly the wrong targets.
A release announcement—or any other kind—is an opportunity to catch
the eye of people who don't know anything about the project, but if
it is hard to figure out what a project is, it's unlikely very many will
try. It is even worse when there is no URL in the message, or the link
leads to a web page that has the same problem: no project description on
the first page. Clicking multiple times to try to figure out something
useful about a project is a further barrier that even fewer will surmount.
One of the most important things a project can do is to create a short
project description, just a sentence or two, that gives a good summary of
what the project or application does. It should be targeted at people
with little domain-specific knowledge and try to place the project in
context for users. The idea is that it should be understandable to anyone
who is even remotely interested in the project. Even non-technical
relatives or significant others should at least be able to get a glimpse of
what problem the program is trying to solve just by reading the description.
While accurate and concise, the following leaves something to be desired
for someone unfamiliar with the subject matter:
"GauBlur is a Python script that applies gaussian blur to
images that are produced by dcraw. Radius values in each dimension can be specified and the IIR
algorithm is used." A better version might look
something like this: "GauBlur is a Python script that applies a
blurring technique to raw photos. It implements a 'gaussian' blur with
variable amounts of blurring, which may be useful to reduce image noise,
remove details, or smooth image data."
Clearly the (hypothetical) developers of GauBlur could do better than my
the idea should be clear: try to give enough information for experts to be
interested enough to dig deeper, while not burying less-familiar folks in
too much detail. That is likely to lose those who you are trying to attract.
The description should be used in every announcement that the project
makes. In addition, a release announcement should clearly indicate why the
release is being made—and why someone unaffiliated with the project should
care about the release. Is it a major or minor release? Does it fix bugs
or add new functionality? Are there security fixes included?
For major releases, or those with significant features or impact, adding a
paragraph or two that describes the new stuff in a quotable form is
helpful. Various publications may be interested in quoting from the
announcement, so giving them a chunk of interesting text will be
beneficial. In fact, some publications are really only interested in
quoting from press releases and announcements, so try to make that easy.
It is also helpful to put the announcement somewhere on the
web page in a separately linkable item, as opposed to an entry at the top
of a news feed list on the home page. It may be some time before the link
is followed—often as a result of a search ending up at the
publication's coverage—so ensuring that the link goes to the original
announcement is important.
The home page of a project is the primary means of communicating to new
users and contributors and, as such, it should be geared toward outreach.
Make it very clear on the first page what the project is about (using the
project description), don't bury that information. It is very frustrating
for anyone who visits the web site of an unknown project to have to click
around to various pages to figure out what it actually is. Make it
clear who the target "market" for the application or project is right up
front so that people can quickly make a decision about their level of interest.
While not directly related, I have recently noticed multiple
free software conference web pages that don't have all of the following on
the first page: dates, location, and theme/topic of the conference. Many
project web pages suffer from similar problems. Don't force folks newly
introduced to your project to play "find the link" on the page, put the
important information up front.
It is important to focus on information for the web pages, rather
than glitz. There is nothing wrong with adding decorative elements to a
page as long as it doesn't detract from or, worse, eliminate important
A more detailed description of the project, beyond the short version
described above, is also useful. A few paragraphs could be placed on the home page,
but a "For more information" link from the short description to an "About" page is reasonable as
well. While it is good to provide the more in-depth introduction, it is
still important that it be focused on those who don't know about the
project, and may have only limited knowledge of the subject area.
A news "feed" on the home page is a common and useful way to keep folks up
to date on what's happening with the project. As noted above, making each
item individually linkable is helpful. But, much like release announcements
(which may make up the bulk of the news anyway), each item should try to
make people who aren't following the project understand why the news is
interesting. Try to avoid some kind of "alphabet soup" of acronyms and/or
lots of project or domain-specific terms. People who know about the
project, already use it, or contribute to it aren't likely to be put off by
an overly simplified news announcement, but folks who don't know the
project will find a list of incomprehensible news items to be offputting.
For attracting contributors, something especially helpful is an updated
list of areas that need work along with contact information for someone who
can give more information. That list can bring in people who might not
normally think of themselves as contributors. Maybe the project needs a
logo or some translations done and someone with the relevant skills may
notice it, and jump in. It may be helpful to have a personal email address
as the contact for the task as some may be uncomfortable just posting to a
mailing list or showing up in an IRC channel.
Having different pages on the site to attract different groups
of contributors may help as well. Users typically want information on
download locations, screen shots, and documentation, while developers want
pointers to the code, toolchain information, and development mailing
lists. Translators, artists, UI designers, and so on will also have needs
specific to their areas.
Many projects are using IRC to coordinate and collaborate these days, which
is fine, but IRC is a bad medium for archival purposes because it is
difficult to search. It can also be hard to pull out a particular
conversation thread from multiple simultaneous IRC discussions. For those
reasons, mailing lists still have their
place. For larger issues, where design or discussion of features occurs,
it will be easier to follow and find if it is done on a mailing list.
Web forums can serve the same purpose as
mailing lists, but may be seen by some as a barrier. Mailing lists tend to
integrate well with tools that are already used by developers. Less
technical project members may find forums easier, though. If forums are to
be used, it is important to ensure that they can be indexed by web spiders so that searches
will find the information.
Separate mailing lists for different concerns (like user problems
vs. developer discussions) may be appropriate. It may be somewhat scary
for users to post a bug report to a list that mostly discusses the gnarly
internal details of the program, and the level of discourse (and courtesy) may differ
significantly between different kinds of lists. If meetings are being held
in IRC, posting meeting summaries and logs to the mailing list (and web
site if possible) can be very helpful for those who cannot attend. All of
this helps folks interested in writing about the project as well.
Getting your project in front of writers, editors, and bloggers is a great
way to spread the word about it. Release and other announcements
should be sent to various publications, but blindly sending them to any and
all publications is unlikely to be very successful. Instead, look for
publications (both print and online) that cover areas related to your
A little bit of research can go a long way toward getting your message in
front of the right people. Doing some reading of the content of the site
and noting its technical depth will give you a good idea of whether the site is
likely to write about your project. When in doubt, and even when you
aren't, look for contact information for the publication and check with the
editor to see if they might be interested. Perhaps many won't respond, but
those who do will likely be good landing places for your promotional
Cultivating authors and editors can be a good way to get various things
about your project posted, which will in turn make other publications take
note. The free software web news outlets generally keep a close eye on
what the others are doing, so a release announcement with an well-written
description of the changes that gets posted to one site could easily lead
to an article or blog posting on another. But, in order to get the
announcement posted, you have to have something that will likely be of
interest to the readers of that outlet.
Projects should also consider posting their announcements to the relevant
mailing lists of an overarching project (like KDE, GNOME, Python, Perl,
MySQL, PostgreSQL, etc.). Many of those umbrella projects will have an
"announce" list where postings from related projects are welcome.
So, what's interesting?
The kinds of things that are covered varies widely between publications,
which is where the research comes in handy. Obviously releases, especially
those with new—exciting—features, are of interest, but there
are a lot of other things that go on in free software projects that might
merit some attention.
Press releases for things like corporate sponsorship or the formation of a
consortium around a project (or that the project joins) are topics of
interest. Often these are more formal announcements that get generated by
a public relations firm hired by the company or consortium. Try to ensure
that the press release or announcement is released in a text format or is
available on a permanent web page, rather than a PDF or word processor
Development process discussions, as well as successes and failures in
release management and other tasks, are one common topic in free software
coverage. Because each project has its own ways of doing things, some of
which may well be applicable elsewhere, it is of interest to the wider
community. Switching version control systems or build processes are
plausible topics as well for much the same reason.
In addition, things like a "code of conduct", and its establishment and
enforcement, make good fodder for an article. Similarly, licensing
discussions, like issues with the current license or projects switching licenses for various reasons, are things
that multiple other projects will struggle with, so others outside of the
specific project affected will want to understand them. That is really the
key to whether a topic is interesting: is it more widely applicable?
Some of these topics are controversial and lead to flame wars, which makes
many want to sweep them under the rug, but there are a couple of good
reasons not to do that. While it might be a short burst of bad
publicity—which doesn't exist, at least as the saying goes—it is
also a way for folks to hear about a project that they hadn't heard of
before. Other projects can learn from your project's mistakes (and
successes), but only if they hear about them.
Other promotional opportunities
One of the best ways to get your message heard is to have a project member
give a talk at a free software conference. There are numerous benefits to
that, which reach way beyond just the actual conference attendees. Others
who are considering attending, or just curious about the program, may see
the talk listed and read the abstract, leading them to hear about the
project for the first time. Also, conferences are increasingly recording
talks in video or audio formats so that interested folks can actually
"attend" the talk well after it is given.
Some publications may be interested in running articles written by someone
involved in the project. Finding a project member that has some writing
skill and pointing them toward such publications may help get the word out
as well. Some publications, including this one, will even pay for
In many ways, the advice in this article is common sense, but free
software projects are typically run by technical folks, who may not stop to
think about the details of promoting their project. Something that can't
be overstressed is to ensure that project promotion is targeted at those
unfamiliar with the project. Others will be willing, perhaps even eager,
to delve deeper into the project's communications (web site, announcements,
mailing lists, etc.), but being unable to fairly quickly understand of the
nature of the project will chase off users, article writers, and others.
It should also be noted that web pages and email announcements should be
edited carefully for both grammatical and spelling problems. It is often
very useful to show a draft of these things to a less-technical person to
get their ideas. They can often help show problems with the writing, both
from a language usage perspective and on the technical level of the text.
If your less-technical friends and relatives can't at least
get a glimmer of what your project does from the web site or some other
communication, it's pretty likely that the people you are targeting will
have trouble as well.
Comments (12 posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: Danny O'Brien on privacy, encryption, and the desktop; New vulnerabilities in freetype, kernel, kvirc, libwebkit, ...
- Kernel: Whack-a-droid; 2.6.36 merge window part 1; Data temperature in Btrfs; The IRMOS realtime scheduler.
- Distributions: Membership structures in Debian and Ubuntu; MeeGo; Jolicloud; Illumos; FUDCon Tempe; RHEL 3 EOL.
- Development: Wayfinder and EurekaStreams; GNOME census, OCRFeeder, pyvm, ...
- Announcements: BusyBox and the GPL; Debian Book; Stallman interview; Wesnoth; Desktop Summit.