gnotebook: Bugs, Press Releases, and Molasses: The GNOME 1.4 Launch Considered - page 2
The Medusa Issue
Medusa, though, wasn't the only bug in the GNOME machine at the beginning of the week, and it probably wasn't the most serious.
People always make mistakes, so I don't want to launch into this coming off as a nit-picker who expects everything to go smoothly all the time, but there's no way around the fact that the premature announcement of GNOME 1.4's availability on Monday provided for a lot of confusion and may have placed undue pressure on the developers working on the release.
Things like the GNOME Foundation (and the KDE League for that matter) are around for a few reasons. They're meant to help these projects, largely composed of people who are hackers at heart, deal with the outside world. These organizations provide conduits between the corporate world and the hacker world. Their stock in trade is press releases and promotion, seeing to it that the suits interested in adopting Linux in some form or another can walk away convinced that projects born out of decidedly less formal environments than a cubicle farm will be around next week, continuing to provide code.
They're reflective of a valuable lesson learned from the Linux community's ten years of battling the old FUD point that "the kids building Linux might get bored tomorrow and quit working on it." We don't hear that as much these days because the durability of the project has been demonstrated, and because most people (except a few of my colleagues in the financial press who didn't know Linux was around until the IPO explosion) know to wince when someone refers to Linux as a "new" operating system. They'll likely save the desktop face of Linux a few years of similar struggle against the conservative and wary instincts of people who have to make decisions about accepting technology that's new before everybody else has embraced it, too.
The problem is, there's more to the game than issuing the press releases and keeping things looking slick with slides and press conferences. Those work to dull the senses of most people used to catching a few winks when the lights go out and the PowerPoint presentation goes up on the wall, but they won't completely eliminate the sneaking suspicion a lot of suits have that there's a certain lack of discipline present among free software developers. I agree as much with the next guy that "it'll be ready when it's ready" is a good sentiment for ensuring quality control, but I think it's suicidal for any project with aspirations to taking control of corporate desktops to to say that too loudly in mixed company.
Even more to the point, a sense of coordination has to be present or the nagging suspicions of those suits will never be laid to rest. They might be able to endure a week's delay insisted on by a cheeky engineer (Lord knows they've put up with worse from Microsoft over the years), but they aren't going to like any sense of disorganization.
So the confusion that ensued as a result of that premature press release on Monday was a bad thing, and it points to the need for more communication and tighter coordination between the people providing the code and the people promoting the code. By the time Tuesday evening had come around, there were two announcements and two conflicting statements about what would or wouldn't be included in the release.
It's good, in part, that GNOME 1.4 isn't a dramatic release and that the real centerpiece of the release, Nautilus, was out much earlier than the rest. Hopefully when GNOME 2.0 arrives things will be a little tighter thanks to this experience.
The Trickling Sound of Widespread Availability
And that brings me to one last, relatively minor nit with the GNOME 1.4 release, which is the issue of binary packages and their availability. I'm calling it a minor nit because I want to defer to people who sensibly maintain that there's a special kind of mania involved in insisting on having convenient packages provided on the day of a release. In the big picture, it just doesn't matter whether we all wait a week or two to get a collection of RPM's or a handy line for our /etc/apt/sources.list (though people tracking Debian Sid already have one).
On the other hand, there's no way to avoid comparing GNOME to KDE on this score. Once the KDE project got around to announcing KDE 2.1.1, they had binaries in place and propagated to the mirrors. Debian's Ivan Moore seemed to have it ready the day before the release was announced, and there were RPM's for most distributions of note the day of the release distributed world wide.
GNOME enthusiasts walking in through gnome.org's front door, on the other hand, are presented with a page that tells them for binaries they need to go visit Ximian (actually, it says "Helix Code"), otherwise they can compile the thing themselves from sources provided by a page that still indicates the latest release is GNOME 1.2. To their credit, the actual release announcement did point to a fresher page. It still looks sloppy to an outsider, though, even if those of us who already admire the project lurking underneath the confusion are friendlier about it. Point: KDE.
The 11th Hour
And that, in turn, brings me to the mystery I'd hoped to have resolved by the end of the day yesterday in time to roll into the column this week, which is just when Ximian's going to be providing those binaries to the folks who don't want to compile the whole thing themselves (often referred to as "end users," or "lazy people" depending on how diplomatic you're feeling).
Sadly, I can't tell you because Ximian isn't saying.
They'll be ready when they're ready.
Solid state disks (SSDs) made a splash in consumer technology, and now the technology has its eyes on the enterprise storage market. Download this eBook to see what SSDs can do for your infrastructure and review the pros and cons of this potentially game-changing storage technology.