Author: Robin 'Roblimo' Miller
This is the first secret you need to know. PR is not magic that can be done only by a person who has been sprinkled with PR Pixie Dust by the PR Fairy. Ordinary people can do PR just as well as many of the professionals. Indeed, many IT journalists think some PR pros need more training. If you have time to read a long screed, check The Care and Feeding of The Press — A guide for press relations staff (or those who play them on TV), by Esther Schindler (with help from other members of the Internet Press Guild). This piece is obviously aimed at professional PR people pushing commercial products, but everything it says applies to open source projects, too.
If you read even the first hundred words of Esther’s article, you’ll notice that commercial PR people often do things that annoy journalists instead of filling us with warm fuzzies. By avoiding some of the worst mistakes Esther lists, you will make yourself at least as effective a PR person as half the ones you might spend money to hire.
Rule One: Talk to us!
The big secret of professional PR people is that they communicate. They send us email. They call us (usually far too often and at inconvenient times). In other words, they don’t talk about doing media relations work. They sit down, write press releases, and send them out.
A press release doesn’t need to be fancy or follow a certain format. All it really needs to have is a title that’s short enough to be read quickly (no longer than the average NewsForge headline), followed by a first paragraph that summarizes the news you’re putting out in 25 – 50 words (much like the first paragraph of a NewsForge story), then several paragraphs of additional detail about the product or service, with contact information at the end.
Think “who, what, where, why, when, and how,” and you can’t go wrong.
If you’re sending your press release to NewsForge via our editors at NewsForge email address or our online submission form, please use the simplest format possible; for email that would be ASCII text, and for the submission form it would be minimal HTML. Do not send MS Word or OOo docs as attachments in an email; we are unlikely to read them. And don’t attach photos or screenshots. Give us links instead. This saves us email downloading time when we’re in a hotel or another remote location where we don’t have our office broadband connections available, and makes your release faster to read no matter where we are.
Don’t worry about perfect wording. A press release that gets revised and re-revised and never sent is useless, while one that gets sent even if it has flaws will get the word out. The trick is — I already said this — talk to us. It’s that simple.
Overdoing it
This is where many PR professionals screw up, and you shouldn’t. Send us a release or announcement only when you have something substantive to announce. Don’t send us a press release every day or every other day. There are companies that do this. For some reason they seem to think you, as a NewsForge reader, are dying to know that so-and-so just got promoted to assistant vice president in charge of sitting by the door. Maybe so-and-so’s mom is interested and she reads NewsForge. That’s nice, but hundreds of thousands of people read this site, and we like every story on it to be of interest to at least a few thousand of them, not just to someone’s coworkers and family members. If your news is of interest only to a limited circle, the best way to distribute it is by emailing friends and coworkers (but not us).
A software “point” release is not substantive unless it fixes a particularly annoying problem, and even then it’s probably not newsworthy in a general sense unless it’s a widely used program. For software that’s not widely known or heavily used, it takes something a little more major than a couple of bug fixes to make people want to read about it. In many cases, just the fact that the program exists and fills a vital need — hopefully one shared by many computer users — is newsworthy. Once. After that, only major changes or advances are going to interest anyone who’s not already using your software, and current users ought to be on your mailing list or at least smart enough to check your project page now and then, so that’s how you should distribute that kind of “in-group” information.
“I have a great idea for an open source project…”
Hey, me too! And lots of other people.
When Linus Torvalds first told the world about the operating system that later became Linux, he had actual code to share — and code that worked, no less. He didn’t say it would be a great idea for someone else to write code that performed a particular function. Nope. He wrote some code himself, then invited others to join in. He made no big claims for his work, and didn’t speak in grandiose terms about project road maps or anything like that.
The big secret of successful PR isn’t the PR itself. It’s making sure that what you’re announcing is worthwhile. If you have something good to offer, there’s no need for a lot of hype, and if you don’t have much to offer, no amount of hype is going to change that.
Tell the truth
Honest marketing is effective marketing. If you say your software makes a PC get up and dance, a smart IT journalist is going to install it and whip out a camera to record its moves. If the PC just sits there, your credibility with that journalist just dropped to zero. In other words, if you claim a feature, it had better work. Saying, “Our project’s goal is to produce…” is nice, but most people (and most journalists) are more interested in what your product or service can do right now, today. Once you’ve proven your credibility, you can talk about the future and people will listen.
“Underpromise and overdeliver,” and you’ll get more long-run support than if you take the regrettably common “overpromise and underdeliver” approach. It’s easy to say your Debian-based Linux distro “runs most Windows software,” but the second a reviewer installs your pride and joy and and it doesn’t load Word or Photoshop, you are pegged as a bullshit artist for years to come.
If the program you’re announcing is a beta, say so. Reviewers will cut you a break — and some of their comments (not to mention comments added by readers who download it and try it for themselves) may help you make a better “gold” release. Asking for help with testing is fine. As long as your software performs its basic functions well enough to be useful, people will happily work with you. If it doesn’t perform those functions well — or worse, won’t install or load on most common Linux flavors — you shouldn’t be sending out press releases quite yet.
Yes, we know you need development help. Yes, we know that with a little help you’d have a great piece of software. But we also know that unless you have something solid to show, it’s hard as hell to get people interested in helping you. You must have working code before you start inviting the world to join your project. You need to give to get. “Release early, release often,” is a fine slogan, but if you release too early — or make dishonest claims about your early releases — you will get no help.
How do you define PR success?
A program for calculating stresses in ferrocement structures is never going to be as “popular” as KDE or Apache. If it runs on Linux and/or it’s open source, NewsForge will probably run a press release about it, but don’t necessarily expect us to assign a reporter to do a story on that program or for us to review it. Publications aimed at people who build ferrocement structures or who supply the materials used to make them are going to give that announcement more “play” than we will.
If a small announcement about your ferrocement program appears on NewsForge and other open source sites, plus a couple of stories about it run in appropriate trade magazines, you have just had a major PR score. Everyone who needs to know about your program now knows about it.
For a general-use program, whether aimed at professional users (i.e. server software) or at individuals (i.e. music CD-burning software), your “target market” should not just be open source-oriented media outlets like NewsForge, but also publications that talk to people who use that kind of program, even if those publications primarily talk about proprietary software. You will have a lower success rate with those publications than with ones that concentrate on open source, but if you get mentions into them you will not only be boosting your own software to a wider audience but will be boosting open source in general, which is good for the entire community.
Don’t delay! Do it today!
This goes right back to the original concept of this article: When you have something substantive to say about your open source project, don’t be shy about saying it. Don’t spend weeks or months talking about “writing a press release.” Write one. Then send it out, at least to NewsForge. As long as you include the basic facts about your project (and contact information) style isn’t terribly important. If you have a good story to tell, we have no problem with “unprofessional” press releases or ones that are written by people whose native language obviously isn’t English.
What counts in your communication with any media outlet — aside from just plain doing it — is content; if you have a good story to tell, editors and reporters (and their readers) will be interested in it no matter how poorly it is presented, while a press release that doesn’t tell an interesting story will make editors and reporters (and their readers) yawn no matter how well it is written and formatted.
