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.

Sorry, the Maureen O'BlahBlah's of the world will never get my respect. That includes these "tech journalists" who don't bother to do actual research and report the truth, just regurgitate "the wire" and vendor press releases. Brian Lamb of C-SPAN, one of the few real journalists left, knows better and would never show the journalistic laziness that most "journalists" I've seen "report". Of course, the advertising dollar$ to their firms might have a whole lot to do with that laziness....

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.