Four Things Open Source Projects Should Know About Dealing with the Press
It's kind of funny that I led a panel at the O'Reilly Open Source Convention that I didn't mention at all in my OSCON conference coverage. Perhaps it was due to an unusual dose of modesty. However, in What Open Source Projects Need to Know About Interacting with the Press, which was also illuminated by Zonker Brockmeier, Jennifer Cloer, and Peter Galli, we spent most of an hour sharing advice about the mistakes that open source projects make when they interact with journalists. I won't repeat everything we talked about — I'm not sure if you're that interested (please tell me!) — but I thought it was worth enumerating a few suggestions. These are not, perhaps, the most important lessons, but they are certainly issues that have irritated me.
The first step for any open source project that wants to be discovered is to make yourself discoverable. A journalist who's looking at open source projects to include in an article about, say, Highly anticipated open-source releases coming in '09, won't necessarily have the first idea what your project is about, its current status, or whom to contact. Create a /press page (just like the commercial software companies do) with this information, which can also include ready-to-use screen shots, press releases, and previous mentions in the press.
This is not a matter of us indulging in journalist laziness. When I was working on candidates for that article, I looked at lots of sites, probably over a hundred of them. Several open source projects seemed to have an imminent release, but I couldn't find a straight-up definition of the project, much less an answer to "Why should I care?" or "What're you working on?" Or (be still, my beating heart) someone to contact to ask for more information. Who might actually respond. This month.
Creating a /press page isn't a bad idea even if attracting media attention is low on your priority list. Having the "who we are, what we're doing, and why you should care" info in one place also might help users and developers find out if your project is worth their download time.
Sign up for ITworld's Daily newsletter
Follow ITworld on Twitter @IT_world
Esther Schindler
If the comments are ugly, the code is ugly
claird
SVG a graphics format for 21st century
pasmith
Take Chrome OS for a test spin
Sandra Henry-Stocker
Solaris Tip: Have Your Files Changed Since Installation?
jfruh
Android fragments vs. the iPhone monolith
mikelgan
What Gizmodo missed about the Pro WX Wireless USB disk drive
Sidekick: The Good News & the Bad News
Either way you look at it Microsoft Data Center management did not follow standards or best practices in this failure. In which case it makes me wonder more about the outsourcing of corporate data much less personal data.
- mburton325
Join the conversation here
Quick, practical advice for IT pros. Made fresh daily.
Want to cash in on your IT savvy? Send your tip to tips@itworld.com. If we post it, we'll send you a $25 Amazon e-gift card.
/press page it is
I will add /press to our site. I didnt realize that was the norm... Thanks.-jp
Remember, that a reporter is
Remember, that a reporter is the most important person you will ever meet. So even if they're a giant douche then you have to kiss their ass every chance you get, and buy them lunch, cos they're giving up their life to make YOUR project a success.Well, that's what I got from this article.
Be careful when asking for an immediate answer
The quote in the article, "it generally does mean, 'Drop everything and answer us now,'" is quite disrespectful when approaching solo developers and small teams. Interruptions are so disruptive to the software development process that seasoned software developers don't work with people who make such silly demands. "Drop everything and answer us now," sounds like, "Bow down to me so I can make my deadline at your expense."