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.
to post comments)