Promoting a free software project

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.

Why?

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.

Project description

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.

Email announcements

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.

Web site

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.

Mailing lists

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.

The press

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.

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 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.

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 well-written articles.

Common sense

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.