What is GNOME not going to be?

[nelson media mit edu (Nelson Minar)]

>>IMHO, GNOME tries to build the ``best'' GUI environment, so the priority
>>should be at getting a good 
>I think this just about sums it up. Gnome *will* be the best, and
>thus we will need to incorporate a metadata implementation of some kind.

I started a big free software project about four years ago, Swarm. We
had a meeting of potential users to spec out what was needed. It was
an exhilirating meeting, lots of ideas about what our fancy software
could do. But then one of the people at the meeting stopped us cold
with a simple question: "What is Swarm *not* going to be?"


I want to raise the same question here: what is GNOME *not* going to
be? I'm a newcomer to GNOME and so far I'm very impressed. But the
discussion I've seen on this list worries me, because it seems that no
one has any ideas what the boundaries of GNOME are. It's a giant
thing. A GUI, an application launcher, a session manager, a whole
bunch of new and converted apps. Fine. But it's also a CORBA ORB, and
a database front end, and now it might even be a whole new conception
of what a file is in Unix.

What is it that won't go into GNOME?


I don't mean to start a flamewar here. I have no right to. I
understand why people want to build their own ORB, their own new
concept of files, etc.. The existing solutions for these things sucks
and we know how to make it better. But that has to be balanced with
some realism about the scope of the project.

I don't know where the balance should be struck. There's an awful lot
of energy behind GNOME right now, a lot of people working on it. The
new ORB seems to be working out well; maybe writing a new filesystem
and getting people to use it isn't an impossible goal. But I would
encourage people to think about limiting the scope of GNOME, to think
about what is the least that needs to be done to make a wonderful GUI
for Unix. It'd be a real shame if the whole project ran out of steam
at some point because so many pieces had been designed in and there
wasn't the manpower or expertise to implement them all.

With apologies if this has all been hashed out months before,
  Nelson