RE: Quo vadis, GNOME? (was: Getting Bugzilla support into Bug-bud dy)



It actually is already part of the thinking and will be reflected in the
plan - We think that the grassroots support we can garner at college
campuses and local LUGS are an important and untapped resource to GNOME.
Plus, the idea of being able to get talented programmers into GNOME while
they're still in college is very appealing.  However, this discussion has
sparked a couple of other ideas that I'll incorporate into the plan and that
we can then discuss.

Leslie

-----Original Message-----
From: Bart Decrem [mailto:bart eazel com]
Sent: Tuesday, February 06, 2001 11:14 PM
To: Havoc Pennington
Cc: Matthias Warkus; gnome-hackers gnome org; Proctor Leslie; Greg
Corrin
Subject: Re: Quo vadis, GNOME? (was: Getting Bugzilla support into
Bug-buddy)


Hi,

I resonate with the concerns Matthias expressed and generally agree with
Havoc and Maciej's responses.  One thing I'd like to point to in Eazel's
"defense" is that I feel pretty good about the way we have been bringing
new hackers into the GNOME community, in addition to hiring some really
talented GNOME hackers.  I think this is actually a very significant
contribution: people like Darin Adler, Arlo Rose, Pavel Cisler, Ramiro
Estrugo, Don Melton and a bunch of others here are making really valuable
contributions to GNOME as a whole.

But moving to the solutions space ...

Leslie Proctor and Greg Corrin are working on a marketing plan for GNOME.
I think we should make it one of our *major* goals for the year to do
aggressive outreach to college campuses and other places where we can get
the next wave of volunteer hackers excited about hacking on GNOME.  I think
we should set specific goals for the number of new people we want to bring
into GNOME, and simultaneously, of course, we need to also take another
look at the processes we have in place for absorbing these folks into the
project.

Leslie, Greg: how about making that a key part of your marketing plan?

Bart











Havoc Pennington wrote:

> 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
>
> _______________________________________________
> gnome-hackers mailing list
> gnome-hackers gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-hackers




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]