Don Marti

Mon 22 Nov 2010 07:00:00 AM PST

Notes on publicity for projects

(updated 25 Jun 2011: link to notes on Jennifer Cloer talk)

(updated 21 Feb. 2011: followup)

With a little work, almost any open source project can have a better publicity operation than a venture-funded startup or a Fortune 500 corporation.

Companies still need to hire PR firms for managing access to confidential information and expensive resources. But if all the information and value that you provide is freely available anyway, you can handle the publicity task yourself.

These are my notes on some of the best practices from successful companies and open source projects. Not intended to be a comprehensive guide, just a few ideas.

Story

People read, remember, and learn from stories, not facts.

The Free Software Foundation starts with a great story. Richard Stallman wanted to get the driver software for a printer, so that he could add a feature to notify the user whose job was in progress when the printer jammed. He asked for the source code, but couldn't get it. He didn't think it was right to do this to the users, so he began building a whole new software environment, where independently developed code and a new kind of license would protect some future programmer's ability to help future users.

A longer telling of the story is For Want of a Printer in Free as in Freedom by Sam Williams. Of course, there's a moral to the story. Programmers want to help users, so it's wrong to put restrictions on software that would prevent some future programmer from making it more useful.

Plenty of Richard Stallman stories are more entertaining than the printer story. And Stallman himself has written carefully crafted essays where he explains the reasons for his software licensing strategy in much more detail. But people remember the printer story, and far more people can tell the printer story than can explain any of the other stuff. Famous companies and projects, like famous comic book characters, have powerful, often-retold, origin stories. Your origin story might start off kind of bland...

One day, Joe Hacker realized that some of his company's customers only used the web board to ask questions, and some only used the email lists. So he wrote a new piece of social software that worked seamlessly as a mailing list for the mailing list people, and a web board for the web board people. And they could all reply to any thread, and they had the best online discussion ever. The end.

Add enough detail to make it memorable. Maybe one of the web board users came up with a great way to make burgers, and one of the mailing list users posted recipes for homemade pickles and potato salad, and they all had the best cookout ever.

It's possible to come up with a false story, but it usually doesn't work. Darl McBride at The SCO Group had a weak case but a great story to go with it. And his PR person, Blake Stowell, did all the techniques correctly, but with incorrect facts. The result was a short-term pop in the stock, but a bankrupt company.

If a story sounds great, but isn't accurate or doesn't convey your message, don't tell it. The difference between a good reporter and a good publicist is this: a good reporter tells the best available true story that covers the assigned subject. A good publicist tells the best available true story that carries the message. So think about story and message together. You can't convey a message without a story.

Besides your origin story, you'll gather other stories. Most of the publicity work is matching up stories with places to tell them.

Getting the Message Down

In order to convey the message, you need to understand what it is, which means writing it down. You'll probably need to write it down in four ways: mission statement, USP, elevator pitch, and the about paragraph. (It's not a lot of writing. All four message documents should fit on one page.)

Karl Fogel explains the value of a mission statement: it's a quick description of a project that lets people decide, within 30 seconds, if they want to learn more.

A related idea is the Unique Selling Proposition (USP): a short message for potential customers to explain what benefit they can get from you but nowhere else.

Mission statement is what you do, and USP is the value that users get from working with you. There will probably be some overlap, especially since you're probably looking for users and for contributors, but mission looks at the inside and USP looks at the outside. Compare the mozilla.org mission (which is on the long side as mission statements go) to the Firefox USP: "The faster, safer, smarter way to browse the Web."

An extended version of the mission statement and USP is the elevator pitch. Think of taking a 30-second elevator ride with the CIO of a company that could benefit from using your software. What would you say? While the mission statement explains what you're doing, the elevator pitch adds some supporting information to help convince the listener that you're actually doing it well. An elevator pitch might be written down, but the real value is in being able to give it in person in your own words.

A written version of the elevator pitch becomes the "about" section for the bottom of the press release. You'll also paste this into places such as the description fields of directory sites and conference talk submission forms.

Avoid trying to put any of the four items into marketing-ese or corporate speak. Reporters know that you're a collaborative project, so they expect a natural voice. Just avoid 1337speak, Jargon File terms, and curse words, and you'll be fine.

Press list

A big press list is worth very little. Now that it doesn't even cost the price of a stamp to send out one more copy of a press release, every reporter gets way more of those than he or she can possibly read. What you really want is a short list of reporters who will (almost) always read your email.

Step one is to read what they write, including blogs. Jennifer Cloer of the Linux Foundation says, "Be a good listener and demonstrate that you are." This puts you ahead of most of the professional PR people who contact them. (Most hackers have the skills and tools to read way more, way faster, than typical business people. Take advantage of this to keep up with what the media is saying about your project and your category.) Use what you learn to keep a set of notes on each reporter who covers your project, your competitors, or related subjects. Turn ons, turn offs, preferred channels of communication, publication schedule. Subscribe to the RSS feed for each reporter's blog. You know how bloggers are.

Use Google News to search for recent stories on your software category. If you find a story on a proprietary competitor that's accurate, well-written, but boring, and carries a reporter's byline, then that reporter is a prime target for you. The competition isn't telling a good story, but this poor reporter has been assigned to cover the category anyway. You can help each other out.

Many IT reporters are technology fanboys/fangirls, so develop relationships with reporters who think your project fits into the way that IT should be. This doesn't just apply to the message, but also to the medium. If a reporter who covers your area is ga-ga for podcasting, screencasting, microblogging, or some other medium or social site, you'll get more coverage if you participate in it yourself.

Then, just do your elevator pitch for the reporter, either in an introduction email or in person.

Good advice: "When your CEO is coming into town, organize a cup of coffee with us, an off the record, get to know you conversation. You may hear nothing more from us for months, but when you do get a call, respond quickly. When the window opens, it can shut very quickly." -- Matthew Bishop, American Business Editor and New York Bureau Chief for The Economist. For "CEO" substitute project leader or major contributor.

Conferences are often great opportunity to meet with reporters. If you can't get into the Legacy Overpriced Conference About Legacy Overpriced Technology, set up a meeting in a nearby coffeehouse. Repeat, nearby. Everyone is on a tight schedule at conferences.

Keep the press list up to date. Don't keep sending releases to a reporter who has moved on to a new beat or a new publication. It's a sign that you aren't reading.

Embargoed briefing

This is a technique from professional PR that you might not need. The reason to do this is if you have complicated new technology that hasn't been explained well in public, and you want your version of the explanation to be the one that future reporters borrow from.

You send a presentation (PDF is fine) to a reporter and talk through it on the phone, then take questions. Think of it as a really short version of a conference talk, for an audience of one. More here: Why and How Embargoes Work in Tech Blogging.

Offer to do a briefing before you announce a new project or version, and ask the reporter to agree to an "embargo" until the date of the real announcement. This makes the reporter look smarter, because he or she gets the best of both worlds: a story that appears on the day of the announcement, but that he or she had time to write.

If the reporter has a blog, check it for anything that the reporter might have to say about embargoes. Don't offer one to a reporter who rants against them. The protocol is: you send brief email offering information under embargo, the reporter writes back and agrees, then you send the info.

Don't bother with an embargo unless the subject is hard to understand.

The reviewer's guide

Really, just read a Fedora reviewer's guide and do that.

The reviewer's guide is an outline of all the information you'd like to see in a review. And a lot of reviews end up being based on the guide. A good place to look for reviewer's guide items is successfully completed "user stories" from the development process. A user story should have the feature and its benefit in one place, and you can rewrite it from a reviewer's point of view.

Reporters don't want to look stupid, writing, "For the first time, ExampleWare 4.0 includes a pink pause button," and then getting a bunch of web comments all saying, "u clueless n00b, pause button was pink in 3.5!1!! This site used to be cool but it sux now." Explain the new features, and why they matter, in the reviewer's guide.

Include a note at the end granting permission to use the screenshots. Yes, some people will lift your screenshots without asking, but save the nit-picky ones the trouble of asking for permission.

The phone

You don't have to have a contact phone number, but it helps. If you don't want to have media calling you at an unrelated employer or client, get VoIP service or something.

If you have a phone number and put it on press releases, answer or check it. A lot. Mainstream media people are used to gettting quick calls back.

Blogs

Blogs: you know, they're like press releases, only you can curse! You don't have to have an Official Project Blog, but it's very helpful to have several main participants posting to personal blogs often, especially leading up to a release. Running a Planet site is easy, and a good community-building tool all the way around.

Many projects, even ones with an official publicty effort, seem to get much of their "ink" from contributor blog posts that get picked up in the media. It seems like technology reporters are more comfortable adding an RSS feed than getting on yet another mailing list. If you have a productive discussion about a useful feature on a mailing list, summarize it to a blog. And make press releases and other announcements available via RSS, too.

Press releases

If blogs work fine, why send press releases at all?

Lots of archives pick them up, so they're cheap SEO.

Media people who are trying to build "top ten" lists look at them.

Releases have your contact info at the bottom, so more people can find it.

If you get a businesswire.com account for your press releases, you can "squat" on the news feeds for publicly traded proprietary software companies. If you mention a competitor, insert the company's stock symbol, and presto, you're in their news section on some finance sites. (Chris DiBona showed me this one.)

The release lets the reporters who didn't get an embargoed briefing know. The best way to handle unfair negative coverage is to do a killer next version, and brief every reporter who covers your area except the one you have a problem with.

If you're going to do a press release, keep it simple. Plain text in the body of the email, and use a descriptive headline-like subject. Many reporters have crappy corporate email but good RSS tools, so make the release available through an RSS at the same time the email goes out.

Write a press release like a short newspaper story, and put the "About" section on your project, plus your contact info, at the end. Copy the format from something that an expensive PR firm sends out, but don't copy any marketey or blustery language. Newspaper style is best. If you need practice writing like a newspaper reporter, pick up a used copy of On Reporting the News by William Burrows.

There are some online guides to press releases that tell you to follow up with a phone call. Do not do this. Reporters hate "I'm calling to see if you got my release" calls.

General email rules

The Care and Feeding of the Press has some good rules for handling email to the media, whether it's a press release or a pitch. Many of them are the same as the rules for a good technical mailing list, so you shouldn't have to learn two sets of email rules.

(See? If you can survive your project lists, you can survive email-overloaded reporters.) Read the whole thing.

Followups

If you get media coverage, be sure to mention it in project news as much as you can. The amount of web traffic to your story will influence how much future coverage you will get. Link from the home page, "announce" list, project blogs, wherever it makes sense. Include a brief quote and a link to the original bylined piece (the one that "your" reporter gets credit for traffic to). Don't cut and paste entire articles or link to a meta site when you can quote and link to the original.

If the media site offers comments, post something, even if you have to register. If you don't have anything specific to say, just a thank you and an invitation for readers to join a project forum is fine. Check back to see if anyone asks questions in the comment section, and participate in comment threads. If there's a good comment section on one article, you're more likely to get a followup.

Never use the comment section of a web site for corrections. Make those private, brief, prompt, and polite, and send them to the original reporter. Joe "Zonker" Brockmeier says, "When a journalist gets something wrong about your project—and they will—suggest corrections gently and do not encourage your user or developer base to go postal on their comment section."