How To Land A Spot In The Spotlight - Part I
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.
Justin Ryan is a Contributing Editor for Linux Journal.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- New Products
- Linux Systems Administrator
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Designing Electronics with Linux
- Dynamic DNS—an Object Lesson in Problem Solving
- Using Salt Stack and Vagrant for Drupal Development
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Nice article, thanks for the
2 hours 8 min ago
- I once had a better way I
7 hours 54 min ago
- Not only you I too assumed
8 hours 12 min ago
- another very interesting
10 hours 5 min ago
- Reply to comment | Linux Journal
11 hours 58 min ago
- Reply to comment | Linux Journal
18 hours 52 min ago
- Reply to comment | Linux Journal
19 hours 8 min ago
- Favorite (and easily brute-forced) pw's
21 hours 5 sec ago
- Have you tried Boxen? It's a
1 day 2 hours ago
- seo services in india
1 day 7 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?