The Medusa Issue

April 6, 2001

By
Michael Hall

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).