How To Land A Spot In The Spotlight - Part II
Yesterday, we brought you the first of two pieces covering a recent post by Esther Schindler summarizing What Open Source Projects Need to Know About Interacting with the Press, the presentation she co-lead with 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. Today we conclude with Schindler's final point, and our own suggestions.
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.
Picking up from yesterday, Schindler's final point is another that we should all strive for regardless of the individual at hand, and that is to "please treat journalists with respect." She makes a specific point of being sympathetic when a journalist has difficulty understanding what it is you do — as was said above, nobody can be an expert in anything, and most journalists are paid to be reporters, not tech experts. Unfortunately, the tech community — in general, and by no means limited to Open Source projects — tends to have a reputation for lacking patience with the un-technical as well as having few qualms about hostile reaction. The adage "one bad apple spoils the bunch" seems particularly appropriate: We know from experience that the vast majority of those in the Open Source community are patient, civil, and helpful — sometimes to a fault — but unfortunately, those who are not seem to have an uncanny ability to attract the new and un-technical.
Included within this point is advice about items like FAQ pages and other documentation. While these types of pages are available specifically to answer the kind of questions a journalist is likely to ask, Schindler notes that copying material directly from these pages or from other articles written about your project is plagiarism, not journalism. She notes a distinction that may not be readily apparent: "[W]hat other developers want is answers...journalists may not want a feature list as much as we want perceptions, experiences, and opinions." As she put it: "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."
It should be noted, we think, that this does not necessarily apply across the board. While straight news stories may be unable to pull from these materials, that is not necessarily true for all reporting. This news column is a good example, as our reporting takes the form of news and comment, which by design does involve drawing from other news items.
Schindler's points are excellent ones, and any project with the desire for positive and prolific press coverage should definitely take note. As the soapbox is all warmed up, however, we'd like to add a few suggestions from our own experience as journalistic geeks, and from our contacts with others. One question we suspect some project leaders may find themselves asking is "Why?" Why go to the trouble, why care if anybody answers a reporter's questions, why care about the press at all.
Several good reasons come to mind to answer those questions. First, being mentioned in the press is free publicity — it gives your project a voice. Presumably, if one is working on a community project, one of the goals is for somebody to actually use it, a prerequisite of which is that somebody lets them know the project exists in the first place. If the coffers are overflowing, then a media blitz might be chosen instead, but for most projects, the press is likely to be the best way to get the word out to a large base of potential users. Not to be forgotten, particularly online, is that the base in question isn't just the publication's readership — aggregation sites pick up articles and blog posts and ferry them on to tens of thousands of additional readers.
Second, and in line with the first, is that cooperating with the press means your project's voice will be heard. If a reporter has decided to write about your project but nobody will have anything to do with them, the project has lost its voice — but there will be a voice. Instead of having someone to guide them, the reporter will be forced to hack their own way through the jungle, and in the process, accuracy may be hacked as well. Worse than having no mention in the press is having one filled with inaccurate information. Still worse is to have an article filled with negative information provided by some other source — information which could have been corrected and/or rebutted if someone had just talked to the reporter when they asked.
The third reason goes along with Schindler's point about treating journalists like people. If a journalist who plans to write about your project can't find the information they need or anyone to talk to, either of the two scenarios will happen: they won't write about it at all, or they'll do the best they can, with the potential for unflattering results. No information and no comment is one thing, but if someone is nasty to the reporter, that may be what they report. Having a journalist print "When asked for comment, we were told by Project X leader John Doe to go [censored] ourselves" isn't going to do a lot for defeating the above-mentioned reputations or convincing potential users to invest their time in Project X.
Finally, journalists have memories — some are like safes, some are like sieves, but we all have them. While press attention to whatever it is they plan on writing about may not be of particular importance now, it will be important to something down the road. When that day comes, and the project is looking for coverage, that journalist may well remember that they couldn't squeeze information out of anybody, assume the same will be true this time, and pass on the story.
Our last point is an extension of Schindler's "make yourself discoverable," and that is to reach out to journalists before there is anything to report. Most journalists who work in a particular field like having contacts, as it improves the quality and speed of the entire process. That doesn't mean taking every reporter on the planet out to dinner and sending them flowers on their birthday — we like lilies, just for the record. We can't speak for every reporter, but in our case, an email to say "Hi, I'm the press contact for [Project/Company], if you ever have any questions, here's how to get in touch with me" goes a long way towards making our job easier.¹
From our viewpoint as both members of the Linux & Open Source community and journalists covering the same, we think these points are highly valuable to projects looking to put forth a polished face to the press. Indeed, a number of the points raised, as said above, would do well to be applied to all aspects of communication, not just with journalists who happen by. Perhaps the most important point of them all is to remember that the press is made up of people, and if you help them, they'll help you.
Justin Ryan is a Contributing Editor for Linux Journal.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Tech Tip: Really Simple HTTP Server with Python
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide