As we all know, OSCON provides a multitude of opportunities for those in the Open Source world to learn not just the ins and outs of what's new, but how to improve their projects on fronts ranging from code to documentation to community members. One such opportunity at this year's convention came in the form of a panel presentation on press relations, a subject that can be both touchy and treacherous where PR pros are scarce. As that's the business we're in, and our readership includes many in target audience, we thought it would be beneficial to pass on.

Note: Given the nature of the information being covered, we've diverted somewhat from our normal news and comment format. Where appropriate, we've included comments from our own experience in covering the Linux and Open Source community.

The panel in question, What Open Source Projects Need to Know About Interacting with the Press, boasted four presenters well-known in the field: Freelance journalist Esther Schindler, openSUSE Community Manager Joe Brockmeier, O'Reilly's James Turner, and Page One PR's Jennifer Cloer, who oversees public relations for the Linux Foundation. (The panel description also lists long-time tech journalist Steven Vaughan-Nichols, though Schindler's post does not.) According to Schindler, who recently wrote a summary of sorts about the presentation, the panel covered a variety of important items, from the perspective of both journalists and professional PR representatives.

Schindler lists four items from covered by the panel as "not, perhaps, the most important lessons, but they are certainly issues that have irritated me," though her post indicates that a broader discussion of the presentation could be forthcoming if desired. The items cover common obstacles encountered by journalists when covering Open Source items of various types.

First, says Schindler, is to "make yourself discoverable," by which she means, give journalists somewhere to go when they're interested. She suggests including a press page on the project's website where reporters can find basic information to work from. Suggested items include a description of the project, what its status is, who journalists should contact for more information, and potentially "ready-to-use screen shots, press releases, and previous mentions in the press." She makes a particular note that doing so is a matter of providing clear information about the project — to journalists as well as those interested in contributing to the project — rather than coddling reporters.

It might surprise project leaders how often journalists — including those of us here at Linux Journal — go looking for information about a project we want to cover, only to be unable to find it or even a suggestion of where to ask for it. It's a missed opportunity for both sides — we lose our story, and the project loses free publicity, in some cases free publicity in front of a large and well-targeted audience. It's also helpful to remember that journalists — particularly those who freelance — are working on many items, potentially for many clients, and don't necessarily have the time, nor are they being paid, to spend hours digging for information.

Schindler's next point is to "speak in a language we understand." She immediately notes that this doesn't mean issuing formal press releases — with an interesting note that "we ignore 95% of press releases anyway, for reasons that have nothing to do with open source." (We'll not claim to write on every release that finds its way to our inbox, but announcements from Linux and Open Source-related projects do have our attention.) "Speaking our language," says Schindler, is about explaining what your project does, what you're announcing, and why it's important. As one might expect, no one can be an expert in everything, so what is common sense to a heavily-involved developer with particular expertise in the project's field probably won't be to those without such credentials.

We too — and we at the news desk are geeks, even if sometimes we don't seem to be — have trouble understanding the intricacies of some projects. While we understand distribution releases and new GNOME features, large-scale changes in programming languages and kernel development make escape us from time to time. A little explanation goes a long way in helping not only to get the gist across to the journalist, but to make sure what they tell their readers about your project is accurate.

Schindler also includes under this heading the importance of "thinking outside the box" — or the binding, as the case may be. Open Source projects often court Open Source publications, under the assumption that such publications will be sources of interested users. While that's true, Schindler notes that projects generally involve more than being Open Source — "If your software solves a problem for left-handed oboe players" — and that other publications that cover those areas — those covering left-handed software and music magazines, in that example — would likely be equally interested.

The next point on the list is to "gain some empathy for the journalist's point of view" — something we should all aspire to regardless of whose point of view it is. The main theme of this point is to understand where reporters are coming from, and what they have to work with. Journalism isn't like software development — while an extra day or two won't necessarily upend the release of a software package, reporters don't have the same opportunity. Depending on the publication and the type of item being written — a news report vs. a feature article, for example — a journalist may have a matter of hours between the time they pick up a story and when it needs to be finalized in print.

Schindler urges project leaders to make an effort to work within a journalist's time frame — if a reporter asks for a quote or information about a particular point, consider it something to be answered as soon as possible rather than as time permits. An established spokesperson — like a community manager or administratively-oriented project official — makes accommodating such requests much easier, as that person can be prepared to answer at short notice, taking pressure off others who may be less able to do so. Most journalists will be happy to give a deadline if asked, though, as Schindler points out, it's more likely to be "'I need to know by 2pm'" than "sometime this week." We experience this dilemma ourselves — while projects with dedicated PR reps generally provide more contacts than any journalist could use, it can be difficult to find someone within a community project to offer a quote at the last minute.

Turning the tables a bit, Schindler notes that there shouldn't be any problem in asking the journalist in question about the piece their writing. She notes that while blog posts and feature articles generally take a deeper look and may "address a meta-question," news items tend to be short, sweet, and to the point, focusing on the 5 W's — Who, What, Where, When, and Why — as well as the big H, how. By asking about the article to be, you can gauge the type of response required — a short news post may only need a one or two line quote, while a feature could incorporate an in-depth response.

Tomorrow: Schindler's final point, and our own suggestions for happy exchanges with the press.