Author: Nathan Willis
Obviously Apple has good PR people, for which there is no substitute. Whenever Apple launches a product, CEO Steve Jobs delivers a focused speech about what makes the new gizmos desirable and different. It is simple for buyers to understand and easy for journalists to write up. By contrast, few open source projects put much work into public relations at all.
Consider the GNOME 2.8 release notes; they are bland, wordy, and contain no real specifics. I have read this announcement, and honestly I can’t tell you what makes GNOME 2.8 necessary — is it the same as GNOME 2.6, only with fewer bugs? If that is all that has changed, it is hardly worth a new version number.
Lest I be accused of taking sides, the KDE 3.3 release announcement has more specifics, but they are buried beneath far more words — a stack of buzzword-laden, “this product is award-winning” boilerplate that tells me nothing. And both projects focus disproportionately on minor changes relevant only with respect to previous releases.
On the other hand, the Mozilla Firefox start page is bulleted with clear and specific items of interest to users; much more informative and more inviting. No space is wasted on self-praise (do you really care if it has won awards? I don’t; I care if it works for me), it just gets straight to the point.
Undeniably most open source projects can stand improvement in this area. Robin Miller’s April 2004 article “Getting good PR for your open source project” spells out the essentials of publicizing your work. It’s a good read and links to other helpful information as well.
But let’s say you read up on PR and know how to write a killer press release like nobody’s business. You can still learn something from Steve Jobs’ example. Let’s take a look at exactly what Apple does at these product launches.
Timing!
Three key factors combine to make these product launches the rumor-site-crippling hype-juggernauts they are: the secrecy prior to launch, the simultaneous launch of multiple products, and the “big event” venue where the launch takes place — MacWorld Expos and developer conferences.
Clearly an open source project cannot veil itself in secrecy like an NDA-wrapped commercial software house; it contradicts the open development model. But the other two factors are easily within reach.
Take the Expos, for instance. The press already covers these events, but for the most part they lack excitement; reporters have to dig to find material for stories. Frequently Linux expos are barely interesting to the mainstream tech media because they are short on big news stories. But if the GNOME Foundation and other major projects would time their releases to coincide with these events, they would be handing material to a press corps that is looking for something to write about.
That may seem a bit artificial, and certainly things like the kernel should not be rushed or delayed just for the sake of media coverage. But some projects (say, Fedora and OpenOffice.org) have set essentially arbitrary dates for their release schedule, based on essentially arbitrary choices of release features. Adjusting that timing so that the new releases are announced at major Linux expos would boost the projects well with free and easy publicity.
All for one, one for all
Rarely does Apple launch just one product at its events. Instead, there’s a new iPod, and a new Mac, and two new software titles. This is also a deliberate choice intended to insure publicity: four new products all launched together are guaranteed to be a story; one new product by itself is making a gamble for headline space.
Similarly, if open source projects can cooperate to release more major updates simultaneously, they will make a bigger splash in the mainstream press. To take a current example; if the new version of the GIMP were released at LinuxWorld, it would not stand much chance of making the front page (well, except at OSTG sites). On the other hand, if the new GIMP, and the new Inkscape, and the new Blender all came out together, it would be a far bigger story, and far more likely to garner press coverage.
But it doesn’t even have to be a suite of related applications for this effect to work; the Mozilla Foundation could coordinate its next Thunderbird release with the next OpenOffice.org release, and the combined story would still be more newsworthy than either piece individually. You might say that the sum of the news is greater than its parts.
Coordinated releases and event-centric scheduling would benefit any project that chooses to work at them. Some may argue that adopting a schedule that is tied to anything other than the state of the code is open source heresy. Realistically, though, it changes nothing. People who wait for a formal “.0” release before downloading software don’t follow the development process anyway. And anyone who follows the development process itself doesn’t care about formal releases; they are comfortable running test versions already.
Nothing changes when you alter your release schedule for public awareness’ sake — except that you attract the attention of more users. And these new users are the people who will find bugs, report them, and perhaps eventually get involved in the development process itself.
Products vs. projects
It is easier to generate publicity for a product than it is for a project. The term “product” carries with it connotations of something ready to be bought off the shelf and used; “project” suggests something ongoing, perhaps continually changing and unfinished. But there is more to it than mere words. Looking at a particular piece of software as a product rather than as a project raises different questions — a project has requirements, bugs, revisions, and milestones; a product has a market, it needs promotion, it has to be moved in order to thrive.
A closed-source vendor like Apple has it easier, to be sure. It can announce all of its new developments at once, as products. The corresponding improvements to a Linux system come out independently and erratically over several months, as individual projects; announced by X.org here, Trolltech there, and so on.
But that does not mean open source projects cannot think about their code and promote their software as a product in exactly the same ways: making press releases, scheduling release events, and aiming for publicity. The Mozilla Foundation has already shown that this can be done successfully with their coordinated marketing work on Firefox and Thunderbird. The only question is how long it will take other projects to catch on and follow suit.
