Re: Quo vadis, GNOME? (was: Getting Bugzilla support into Bug-buddy)

[Havoc Pennington <hp redhat com>]

Hi,

I think these are important questions, but it's also important to look
at some of the complicating factors and try to get a real solution out
of it.

IMHO rule number one is not to get all gloom-and-doom and flamefest,
because the problems we're having are the same problems you'd expect
in any large organization, especially large organizations that grow
quickly from small ones, both commercial and nonprofit. We simply have
a lot of different people to organize and interests to balance, and
our infrastructure and skills aren't yet up to the task. We'll get it
worked out over time; there's already been tremendous progress over
the last few months, though I don't know that it's been publicly
visible, it's my perception. We're going through pretty natural
changes and many other projects and organizations have faced similar
issues.

In particular I think you can point to the Linux kernel, Python,
Mozilla, gcc, any number of projects, and see them facing the same
kinds of decisions. I don't know if anyone has the perfect recipe for
success yet.

mawarkus t-online de (Matthias Warkus) writes: 
> Looking at the CVS logs, no one seems to be really working on the core
> anymore. Pretty much all of the code commits go into Nautilus,
> Gnumeric, Evolution and Eazel's and Ximian's supporting and
> surrounding technology and tools.

Keep in mind that we've really discouraged much change to the panel,
control center, session manager, etc. because they would destabilize
the stable versions of those, and we've essentially been in code
freeze for these core components for a _long_ time.

The original plan for 1.4 was to leave the panel, etc. unchanged and
stable, and just add Nautilus. So here we are just following the plan.

I do think it's appropriate to focus on shortcomings rather than
introduce bugs into the panel - the panel does not really need more
features, I have to say. ;-) Beyond Nautilus, some items to look at
are e.g. cleaning up the mess of small add-on apps such as
gnome-utils, finishing Bonobo, a reasonable help system, better docs,
more UI polish to existing panel/control-center/etc. rather than new
features for same, etc. So GNOME 2 should focus on that kind of stuff
IMHO. GNOME 2 would maybe be cleanups + help system + new devel
platform. This is getting into details though and open to discussion.

My point is just that lack of work on the core was the plan all along,
it's not symptomatic of anything.

> I think we're at the point where we should ask ourselves whether the
> GNOME Project can still be considered a living entity at all. And
> whether it's a good move to, at this point, tie our next release to
> Nautilus, which, however cool, is essentially a third-party product
> with the main purpose of generating revenue for Eazel.  If we go on
> "outsourcing" software that way, we might end up with a "GNOME
> desktop" which is not much more than lots of commercial free software
> bundled together haphazardly.

The issue here is complicated.

I don't think we can say that Ximian took over GNOME packaging as you
mention later, because no one was doing the packaging. ;-) Well,
Debian did Debian packaging, Red Hat did Red Hat packaging, GNOME
released tarballs.  Ximian just added another package set to
that. They're free to do so of course.

So, the tarballs have always been the community GNOME distribution,
and that continues. If people are all using Ximian, that's really not
something we should object to as a project.

Linus doesn't ship Linux distributions, he ships a building block of
them which gets rebranded and productized by companies. I think that's
more or less the right approach for GNOME.

For the larger issues.

One reason we created the GNOME Foundation was to have an institution
and decision-making body that could represent GNOME in the face of
competing interests. i.e. companies are really organized and push for
what they want, the foundation organizes GNOME. It represents GNOME's
interests as a whole.

At the same time, we have to recognize that the foundation has no
power to actually write code. We can't say "put 3 hackers on that."
There are lots of unaffiliated volunteers around, but they work on
what they want and aren't available to be ordered around.

Also, the foundation has run into the problem/blessing of maintainer
authority. The foundation can't tell maintainers what to do, and many
maintainers work at companies. Any maintainer who isn't feeling
cooperative - perhaps encouraged by their affiliation - can refuse to
cooperate with community plans. I don't think we have a good way
around that issue. If people aren't playing in good faith, they just
screw the project. I don't have a suggestion for fixing this; I'm not
prepared to say "the board should be able to override maintainers"
because that's a whole different can of worms. Giving maintainership
to unaffiliated volunteers won't work, because as soon as someone
competent appears they have their choice of several employers and most
decide to pick one of them.

There are lots of new unaffiliated volunteers - more than there used
to be in the past, I would say - we aren't necessarily channeling
their energy too well. I'd say it's in part because many projects have
sort of semi-inactive maintainers who are trying to do too much so
don't have time to nurture potential contributors.  Also in part it's
because we simply don't _want_ more features in core GNOME. The
remaining desired features are more stability, more docs, keyboard
navigation, accessibility, packaging, etc. - boring polish that
volunteers don't want to touch. ;-) Anyone who does seem interested in
doing that sort of thing well gets hired quickly.

Addressing the specific issue of Eazel: Nautilus _is_ far nicer than
what we would have developed on our own. That's why we wanted Eazel to
do it, and why I'm glad Eazel did do it. And the goal of GNOME 1.4
well before Eazel appeared was "GNOME 1.2 plus file manager."

You express concerns about outsourcing software - the problem is,
there's no one else who's going to write it, and again, if someone
appears who is, they get hired or at least have that option.


So it's a good problem to have - we have tons of people working on
GNOME, lots of them get paid to do what they enjoy, companies can't
hire enough GNOME hackers. How do you keep a body of unaffiliated core
hackers in that environment? I have no clue. Send suggestions if you
have them!

We do have a long list of unaffiliated people we want to fly to
GUADEC, so perhaps I'm exaggerating a bit. Most of them are working on
sort of peripheral projects such as the office suite instead of the
core desktop though.

> The official GNOME 1.4 should not ask anyone to subscribe to any
> commercial service and it should not contain corporate advertisement.
> Maybe the problem can be solved by stripping all the Eazel stuff out
> of the Nautilus version that'll ship with GNOME 1.4. Eazel could ship
> their corporate design and their services as a third-party add-on and
> market it from their own site.

I don't know. We need a policy on this, and it's on the "pending
agenda items" list for the board. Discussion is welcome, please
brainstorm ideas.

One suggestion is that all hooks for services should be required to be
generic, with a selector widget where users can choose among possible
providers, and we list any provider that wants to be listed. Or
specific vendor services could simply be an add-on component that you
have to download; e.g. you download the "Eazel services" module for
Nautilus.

> There should be some guidelines enforced by the GNOME Foundation
> laying down what passes as GNOME. To me, a branded distribution of
> patched GNOME packages with different artwork, containing corporate
> ads and free clients for corporate fee-based services, is *not* GNOME
> anymore. 

It's true now that "Ximian GNOME," "Red Hat GNOME," etc. are not
considered GNOME itself, and we don't support those. Our community
release is the tarballs and only the unchanged code contained
therein.

So it's the same problem that people feel "Linux" gets lumped together
with "Red Hat Linux" or whatever. I have no real suggestion for how
Ximian or Red Hat can avoid that while still communicating what their
product actually consists of to customers, though. ("It's GNOME, we
just call it Frobnicator instead to confuse you.")

FWIW the problem seems pretty overstated to me, newbies get confused
but anyone who has a reason to care tends to figure it out quickly.


Anyhow, on any of these matters, concrete suggestions are
welcome.

Havoc