Marketing Your Project

What Is Your Project's Story?

Before your project is ever announced to the world, you need to come up with a compelling story that describes what your project is aiming at--something to get people excited about it. This is the message that will attract people to your project both as users and potential developers. If the story is not appealing, then people will not be interested in participating and won't get involved.

For most open-source projects, this story is focused on the technology being developed. For example, the Apache HTTP Server Project exists to build the best web server. The following are statements of the story for Apache.

The Apache Project is a collaborative software development effort aimed at creating a robust, commercial-grade, featureful, and freely-available source code implementation of an HTTP (Web) server.1

The goal of this project is to provide a secure, efficient and extensible server which provides HTTP services in sync with the current HTTP standards.2

Other projects have a more user-centered focus, as seen in the following comment about GNOME.

The GNOME project was born as an effort to create an entirely free desktop environment for free systems. From the start, the main objective of GNOME has been to provide a user friendly suite of applications and an easy-to-use desktop.3

You need to determine what sort of people you are hoping to attract to your project. If you want to mainly target end-users, then you need to talk about what they can do with the software you are developing, which of their problems your software solves. If you want to focus on developers who will contribute code to your project, then emphasizing the technological aspects may work, but remember that most people working on open-source projects do so because they need to use the resulting software--your developers will also be users.

Creating a good story is hard work. The story needs to express the shared purpose behind your project. It will attract people who share this vision and are willing to work to make it real. Moreover, the story should infuse all aspects of the project so that it provides guidance whenever a strategic decision must be made. In literary theory, such a story is called a topos and can be defined as follows:

a conventionalized expression or passage in text which comes to be used as a resource for the composition of additional texts.4

Topos literally means "place" or "location" in Greek, and a topos is a place from which similar stories can be woven. An example from literature is the story of the Garden of Eden. Anyone in a Western Judeo-Christian culture when asked to tell a story about the Garden of Eden will probably come up with a story consistent with the vision of creation the Garden of Eden presents. An example of a technology-related topos is Moore's Law, which is regularly used as the basis of stories about the future of computing.

For an example of the power of a good story, consider the one developed for the Jini project. As described earlier, Jini technology is a thin layer built on top of Java that allows applications to be written as remote services that can be dynamically deployed and located over a network. The obvious story is that Jini is another middleware framework for distributed applications. But this story has a technology focus that would have severely limited the spread of the Jini message--indeed the term middleware causes even developers to yawn. Instead, the Jini marketing team built a story around what Jini technology would mean to users; that story generated lots of excitement in developers, the press, and the marketplace.

The Jini topos speaks of a world of "intelligent services" that "simply connect" to form "spontaneous networks" and describes a set of home, office, and automobile scenarios derived from this topos. The concepts "simply connect" and "spontaneous networks" address how people relate to the technology. The Jini topos was highly effective and created a thriving community and associated technology--as hoped--along with thriving E-Speak, UPnP, and SOAP communities and associated technologies.

This type of story is especially important for any project with ubiquity as a goal. For Jini, success did not rest in extensive development of the core Jini protocols but rather in nurturing communities to create a wide range of Jini-based services. The story needed to inspire companies to want their products--be they printers, cameras, or whatever--to "simply connect" by using Jini technology.

Contrast this with the Apache topos (described earlier) which speaks of web servers and technology for making them effective. Whereas Jini projects tend to fan out, creating new services for people to use, the Apache Software Foundation's projects tend to focus on adding web server functionality and adopting related technologies such as Java Server Pages, servlets, and XML.

Topoi and storytelling, however, might not go over well with your highly technical developers. Although the developers at Sun in the Jini group were involved in the story-making, they quickly came to believe that the story was misguided, because it talked exclusively about a world of small devices when in fact Jini was also capable in middleware and other high-end applications, such as distributed and scientific computing. They became upset that Sun was actually not working diligently in the device space and so to them the story was a lie.

The idea of a topos, however, is that a topos enables people to make their own stories about their own areas of interest. In fact, most middleware application writers had little trouble understanding that "simply connect" and "spontaneous networks" were either literally or metaphorically true for them, although they worried that less sophisticated people might not be able to understand the connection.

If you decide to build a topos, make sure your developers understand what it's for and buy into the topos you create.

At its best, the topos as a story-making story attracts and provides room for experimentation and variation beyond what the initiators envisioned.

The Name Matters

What you call your open-source project is important. You need to choose a name that will attract developers. In effect, you are creating a brand identity just like any commercial product. You want to create an identity that matches your target audience and that is consistent with your story. Most important, you don't want a name that is too slick or connected with a commercial product.

This can be complicated if part of your business plan is to develop a commercial product based on the open-source version. You need to recognize the different naming requirements for each version.

For example, when Sun was deciding how to name its various Java IDE products, it used the more formal "Forte for Java" name for the Sun-branded versions and the more developer-friendly "NetBeans" name for the open-source version. Keeping the NetBeans name was important for historical reasons, but as a name it does not really describe the project--a Java IDE and more generally a portable tools platform--so another name might have been better.

Getting the Message Out

Once you have a good story about your project, you need to tell it to people. This is a traditional role for marketing. When you have a major piece of news, such as when you first announce your project, your company's marketing machine can see to it that the world hears about it. For very important announcements, this can include major stories in the press. For instance, the initial stories about Sun's Jini technology appeared in the New York Times , Business Week, and Wired. When top Sun executives such as Scott McNealy and Bill Joy gave talks or met with the press, they made sure to talk about what was new with Jini, JXTA, NetBeans, OpenOffice, and the other open-source projects Sun was working on. Major stories were also featured on Sun's website, along with links to stories elsewhere on the Web.

In addition to the big-splash type of announcement, you should also maintain ongoing low-key press coverage. This is essential because there is often a long time between the initial announcement and the final release. You don't want people to think that your project is dead, so be sure to publicize ongoing activities such as community meetings, working group meetings, and significant milestones. These can be as short as a single sentence in a column of industry news in a magazine. Such stories should also be featured on the home page of your project's website. Note that some PR folks are interested only in handling major stories and will balk at the smaller scale needed for ongoing coverage. If they won't do it, then you need to find someone else who will.

If your project involves infrastructure or something that can be used as part of another application or website, try to find ways to take advantage of the pride some people find in using open-source code or in the technology of your project. Create a logo, a graphic, or a sound that can easily be cut and pasted onto the splash screen of other applications or onto the website of some proud user of your stuff. The logo can link to your website, drawing traffic.

Going beyond Standard Marketing

The conventional marketing channels--major newspapers and magazines, trade press, and trade shows--are important, but an open-source project has other ways to reach potential users and developers, including newsgroups, mailing lists, webzines, and weblogs. Use all of these channels to market your project. You should encourage your developers and users to post to whatever online forums are appropriate.

It is important to use a different writing style for material sent over these alternative channels. This is a matter of voice. Richard Rhodes, author of The Making of the Atomic Bomb, wrote:

Every work of writing, no matter how modest, no matter how seemingly "objective," no matter how "true," is composed in one or more fictional voices. "Someone" "tells" every story, even the copy on the back of cereal boxes, even a legal contract, even a street sign. We may not pause to puzzle out who "someone" is--the author may not even have thought about her choice of voice in advance--but we register "someone" 's presence and assess his statements accordingly.5

Almost every reader is aware of the voice behind any writing, and so if you want to build a community, you need to make that community feel like a group of people, people with distinct and human voices. Company writing typically tries to appear as neutral as possible, as much like an encyclopedia as possible, so there is little possibility of a reader hearing a voice behind the writing, a voice expressing an opinion. The company in many cases wants the reader to believe that what is written is objectively true. Marketing writing often puts a cheerleading sort of voice behind the words.

Anything that has a slick marketing feel or inauthentic voice will be rejected and probably will give people a negative view of your project. Avoid hype. What does work is honest talk from developer to developer or user to user. As such, it is the opposite of the typical anonymous marketing message broadcast to a target audience. Instead, it is a message from a real person attempting to engage in an ongoing conversation with other individuals. Each message helps establish the reputation of the writer. Your employees need to become known and respected members of the community in order to best communicate about your project. A big test of their honesty is their being able to admit errors or mistakes and to acknowledge the successes of other projects.

One last point is that it is very important to give credit to the folks who did the work. If a number of outside developers contributed to your open-source project, be sure to acknowledge their efforts. You may even want to feature their efforts because it shows that the project goes beyond your company.