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 is committed to 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 interim, that 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 need to 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 email that 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 "evolution rather than revolution", and that 2.32 would fit that model well:
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 on:
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 specific task", like the Tomboy notes applet or the Hamster time-tracking applet, he said.
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:
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.
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 freedom.
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, and, for 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 computers.
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 them.
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 it...
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 KDE to use Orca with Qt applications so Orca can be used on either desktop.
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.
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 other.
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 example, but 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 information.
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 project.
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 efforts.
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.
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 file.
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.
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 well-written articles.
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.
Page editor: Jonathan Corbet
Copyright © 2010, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds