Four Things Open Source Projects Should Know About Dealing with the Press

It's kind of funny that I led a panel at the O'Reilly Open Source Convention that I didn't mention at all in my OSCON conference coverage. Perhaps it was due to an unusual dose of modesty. However, in What Open Source Projects Need to Know About Interacting with the Press, which was also illuminated by Zonker Brockmeier, Jennifer Cloer, and Peter Galli, we spent most of an hour sharing advice about the mistakes that open source projects make when they interact with journalists. I won't repeat everything we talked about — I'm not sure if you're that interested (please tell me!) — but I thought it was worth enumerating a few suggestions. These are not, perhaps, the most important lessons, but they are certainly issues that have irritated me.

[ See also: Convincing the Boss to Accept FOSS ]

The first step for any open source project that wants to be discovered is to make yourself discoverable. A journalist who's looking at open source projects to include in an article about, say, Highly anticipated open-source releases coming in '09, won't necessarily have the first idea what your project is about, its current status, or whom to contact. Create a /press page (just like the commercial software companies do) with this information, which can also include ready-to-use screen shots, press releases, and previous mentions in the press.

This is not a matter of us indulging in journalist laziness. When I was working on candidates for that article, I looked at lots of sites, probably over a hundred of them. Several open source projects seemed to have an imminent release, but I couldn't find a straight-up definition of the project, much less an answer to "Why should I care?" or "What're you working on?" Or (be still, my beating heart) someone to contact to ask for more information. Who might actually respond. This month.

Creating a /press page isn't a bad idea even if attracting media attention is low on your priority list. Having the "who we are, what we're doing, and why you should care" info in one place also might help users and developers find out if your project is worth their download time.

When you deliberately court the attention of the press, speak in a language we understand. That doesn't mean you need to write a formal press release (we ignore 95% of press releases anyway, for reasons that have nothing to do with open source), but do explain in an e-mail message to journalists what the software is, what the announcement means, and why the editor's readers should care about it.

As my old friend Alan Zeichick says: "We don't have the context to immediately 'get' the importance of what you're doing. Be sure to explain it to us."

This doesn't mean we're idiots. We try not to be. But you've gone deep with your project, and I haven't. I may not be familiar with the problem that it aims to solve. So tell me about it.

Another point in regard to attracting media attention: Don't limit yourself to the open source tech press. If your software solves a problem for left-handed oboe players, then it's at least as important to inform the journalists who write about left-handed software (proprietary or otherwise) and the writers at music magazines. (You might have to tell the latter what "open source" is, but at least you don't have to explain "woodwinds.")

It helps to be charming and friendly. It helps even more if you demonstrate that you have a clue about my publication's audience or what I've written about previously.

Also, gain some empathy for the journalist's point of view. Recognize that we are on deadline, which for most news journalists means posting the article within a couple of hours and for feature authors within a couple of days. If we ask for input, or a quote, or anything to which your project spokesperson (you do have one? yes? please say yes) might want to respond, it generally does mean, "Drop everything and answer us now." If the journalist doesn't give you a deadline ("I need to know by 2pm"), it's okay to ask how long you can take to reach the right developer in Poland, but err on the side of "emergency response." It's unreasonable, I know, but so are our deadlines.

It's perfectly fine — and appropriate — to ask the journalist you're corresponding with about the type of article she's writing, which may guide you in the depth or nature of your response. A news story is mostly "what happened, when, and the implications" while a feature story or blog post (which incidentally is what I do most often) might address a meta-question.

Please treat journalists with respect. And encourage the community to do so, too.

Don't be a jerk. Don't get snarky if a reporter or editor doesn't grok the intricacies of your project. As Alan Z pointed out: "While it's not your job to represent the OSS community — because there isn't such a beast — realize that what you do does reflect on other open source efforts, at least to that reporter." I wish Alan was overstating things, but I have encountered these attitudes far too often personally.

Your community guidelines (whether that's a formal document or the cultural vibe) should include something about treating the press like real humans who, duh, do not consider "coverage" to be quoting from other articles or a FAQ. We call that plagiarism, not coverage. I recognize that developers point others at existing resources because what other developers want is answers. However, journalists may not want a feature list as much as we want perceptions, experiences, and opinions. If I post a message in your IRC channel asking why you chose an app, please don't send me to the FAQ! I want your personal story.

This barely skims the surface of "press relations" lessons for open source projects, and it doesn't begin to include the suggestions made by Jennifer, Zonker, or Peter during our session, but it's a start. (If you have any questions you'd like me to address in later blog posts, please ask in the comments here and I'll do my best to respond. If there's enough interest, this could be an ongoing series.) There are, however, a few other resources you might want to explore:

• I'm more than a little famous in professional PR circles for Care and Feeding of the Press; some of it is stale, now, but the long essay should still give you a sense of how we set priorities.
• Josh Berkus gave a wonderful session on open source press relations at the Open Source Bridge Conference, which I mentioned towards the end of my own conference coverage. He published his slides on his site.
• If you're serious about getting your project noticed, I recommend that key committers sign up to participate in Help a Reporter Out. If a reporter needs expertise that someone in your project can share — even if it's not about the software, per se — you might be able to get a bit of press simply by, well, helping a reporter out. It's a free-to-all service that I depend on regularly.

You should follow me on Twitter. Just sayin'.