Open Source Subnet An independent Open Source community View more

Six public relations lessons for open source projects

What we learned about open source PR at the Linux Foundation Collab Summit

The Linux Foundation's Collaboration Summit tends to focus on technical and legal sessions for industry experts — but one of the better sessions at the Summit was Press Training for Community Projects. Led by Jennifer Cloer, the Linux Foundation's director of communications and community, the session drew a great mix of open source contributors and press to trade ideas.

In addition to Cloer, the event brought in folks from several open source projects, a handful of press (including Alex Williams from ReadWriteWeb, Steven J. Vaughan-Nichols, and Jake Edge from LWN) and a few other PR folks. It was a half-day session, with some really good back-and-forth about how to get attention from the press and the best coverage for projects.

Care and feeding of the press is really not that difficult, whether you're working with a commercial vendor or community driven project. It is different, in that most community driven projects don't have the funds to hire PR folks. So you're going to need someone from the community to wear the PR hat — but then you don't have the funds to hire Web developers, designers, programmers, translators, or people to show up and speak at events, either. Most projects that actually would have a need for PR manage to find the bodies to do those things, they can probably find someone good at handling PR as well.

Though it's not difficult, most developers and FOSS contributors tend to approach PR as if it must be very hard to do. It's not. It's possible to do a bang-up job by following a few simple steps.

Have a press kit and basic materials

One of the easiest, most effective, things a project can do to be press-friendly is to actually have a press kit with the basics that press folks need right away. This includes screenshots (assuming the project has a GUI), high-res logo (yes, folks, print still exists), and the history of the project.

This should also include a press contact, or a way to contact your press team. Even better if you can have a phone number for press to contact you. Hint: Get a Google Voice number that is checked often and sends a note to the press list when you get a voice mail.

Your Web site should have as much information as possible as well. Too many sites are just vast wastelands of random content. Yes, maintaining a decent Web site is part of good PR.

Be easy to reach

Your project should have one or more spokespeople that are easy to reach, who will take point on press responses and finding out answers to things they don't know — or at least pointing the press in the direction of someone who might know. This goes with having a press contact listed — but you also need to make sure that they're easy to reach, and responsive.

By "responsive," I mean that if a journo sends a note to the press contact, they should get a response right away. I've heard plenty of complaints the last few years from members of FOSS projects that tech press write about a project without bothering to contact the project. The flip side of that is projects often take far too long to respond. Most tech writers I know are writing two or three posts or stories per day. There's a lot of competition to be first — which means that waiting a day for a response isn't practical or likely. Yes that isn't optimal, but it is reality.

Develop relationships

One of the most effective things a project can do is to develop a relationship with the folks who would write about them. This was a hot topic in the session at Collab — how do you do that?

First and foremost, don't wait until you need to have something covered to make an introduction. Once you project decides to start making PR a priority, make up a list of people who cover your space and start contacting them. Just send a nice short email introducing yourself and your project, and let them know you're available.

Some folks contact me and ask if they can send me releases or announcements. Don't bother asking — just do it. As long as your communications are on-target with what a blogger or reporter is writing about, they're unlikely to mind receiving infrequent announcements. If my inbox looks like you've carpet-bombed it, that's another story. But a few pieces of email a month aren't a problem. Anyone who's been covering tech for any amount of time has a deluge of mail coming their way and they know how to deal with it.

However, do not expect replies unless a reporter is going to write about a given topic. If we know you well enough, we'll likely respond even if just to say "too busy" or "this isn't up my alley, but thanks." But life is far too short to try to field every piece of email even with a terse response.

Speak up

One thing that project should do is to speak up early and often about what they're doing. Have a project blog and keep it updated. A "planet" site is really good if you have enough active bloggers in your project, but the project itself should have a blog that's updated at least monthly, if not weekly.

In other words, don't depend on the press to cover your every move — you can easily spread the word by blogging about your project yourself. Some things may be noticed and picked up by the press, but other things that may not be covered will still be visible to your community and findable via Google.

Understand press releases and announcements

One of the frustrations I've had when dealing with projects is getting them to understand what's worth an announcement and what's not. It's not uncommon for things that deserve an announcement to go virtually unnoticed because the contributors working on a project or making a decision decide that it's not newsworthy.

The flip side is when contributors think everything is newsworthy, and needs a press release. This will quickly burn out your press folks if they aren't listened to — it gets old being pestered to write press releases every time a project has a booth at a regional show that might draw 100 people.

Note the difference between press releases and announcements, though. If your project has an announce list for things like regional shows, it's worth sending a three paragraph email to the announce list to say you'll be at a show and want to get the word out. It is not worth writing a formal press release and sending it far and wide hoping the tech press will pick it up.

It's also worth knowing when it's worth spending the money on sending a press release to a wire service. For open source projects, the answer is almost never. Wire services are for companies looking to reach reporters who actually use wire services, and/or to reach investors. This rarely applies to FOSS projects ‐ so don't waste the money. If you've built relationships with the bloggers and reporters who are important to your space, sending a note to them with the release should be sufficient. If it's newsworthy, and isn't crowded out by other news, then you're golden.

Understand deadlines

Finally, it helps a lot to understand deadlines and the time it takes a story to go from your announcement to a finished story. You want to give press a decent lead time, but don't get in touch too early.

Take a major release as an example. If you have an upcoming release you'd like to have covered and reviewed, a good time to start touching base with press is at least a week before the release. That way there's enough lead time to write a story and have it ready to go the day of, instead of hoping that the folks you work with are going to have free time the day of the announcement. Odds are, that's a recipe for failure. Even if the story is written, it might not be as well done as if you gave the reporters some lead time to talk to people and so on.

Is this everything you need to know about doing PR? Probably not — but it's enough to get started and do a better job than most open source projects. Have additional tips? Leave 'em in the comments!

From CSO: 7 security mistakes people make with their mobile device
Join the discussion
Be the first to comment on this article. Our Commenting Policies