Re: GNOME Nirvana; How to reach it and what to do once we get there.

[Luis Villa <louie ximian com>]

[Sorry for the very delayed response- seems to me like it is still worth
discussing, though.]

On Thu, 2003-06-12 at 19:05, iain wrote:
> My main problem, seeing as some people seemed to have missed my point,
> was that as computers get more and more ubiquitous, people are going to
> require that they do more and more and more stuff. And the current
> scheme of things means that we're going to keep adding more stuff to the
> desktop to keep up with the "Greatest Common Factor" and the perceived
> need that this entails. 
> 
> Chasing The Greatest Common Factor.
> 
> This seems to be the current "ethos" to the GNOME Desktop.

Well, in that wording, it's something one of us is chasing, yes. :) 

> The other people who are most suited to the level that GNOME is aiming
> for, are the who are in group B, and use what they're given.

I'm not sure that's correct. I build my software from CVS every time I
have spare CPU cycles, and I'm damn happy with the approach we're
taking, so far.

> Where does this leave us?
> 
> Currently, there are 120meg of tarballs (gzipped) for "The GNOME Desktop
> (Version 2.3.2)". 17 new modules were proposed for the next major
> release, and of those 17, 14 were accepted. The GNOME Desktop seems to
> be growing at a huge rate, and as I said above, the more ubiquitous
> computers become, the more people want from them, and the more programs
> they will need. The current way we're doing things, the GNOME Desktop
> may need to come on a CD soon. If I was still stuck on my 33.3 modem,
> there's no way I would contemplate downloading 120meg of tarballs.

<nod>

> Is it GNOMEs place to make a complete Desktop package?

> So, in answer to my question, no, I don't think that GNOME needs to
> define a complete Desktop package that meets the needs of the "Greatest
> Common Factor".

I am not sold on the 'Greatest Common Factor' bit; it seems to me a sort
of tortured way of explaining where we ought to go. But we clearly need
to have parity with the proprietary desktops and exceed them where we
can.

> What does The GNOME Desktop need to do?
> 
> I think that The GNOME Desktop needs to do two things.
> Firstly, I think it needs to define a set of packages that provide the
> very basic level of functionality. In this I would include 
> * The panel
> * Nautilus
> * The terminal
> * Basic applets
> * Some basic utilities (a find tool, a calculator)
> * Yelp
> * The control centre for setting The Desktop options.

I'd find a desktop without a web browser unacceptably crippled. Probably
most people would feel the same way about a music player. [And plenty of
people are still convinced that we don't need a file manager. :) How do
you propose we draw the line on 'very basic level of functionality'? The
list you're proposing would be less functional than win95.

<snip correct description of sort of suckiness of software map and fifth
toe>

I agree that we need to make finding useful and high quality tools
easier, and group them in sane and useful ways. There is still value, I
think, in picking the best of the best and calling that a desktop.

> So, what do you ****ing want?
> 
> My simple idea would be some sort of rating scheme, 5 GNOME feet awarded
> to first class software heading down to unrated software and a web site
> that has a simple way to find this software. Someone said apps.gnome.org
> and that'd be perfect. Software could be submitted to this software map
> and when submitted would start in unrated. There would be a very clear
> guidelines to what a program needs to have to be a 1foot, or a 2 foot
> etc. For example, to be 1 foot maybe a program needs to be fully HIG
> compliant. 5 foot programs may need to be fully documented, fully HIG
> compliant and fully accessible.

That's a pretty reasonable idea, I think, but only as a supplement to a
cleanly defined GNOME. 'Don't like the official web browser? Here are
other options that work well and follow X, Y, and Z guidelines.'

> And what advantages will this give us as a project?
> 
> Well, simply it will allow people to have a desktop that best suits
> their needs rather than the arbitrary needs that we as the developers
> think they have. This lets us have more satisifed users, rather than a
> disgruntled user base who think that the needs of grandmothers are
> coming before theirs, and maybe less people bitching about corporate
> takeover.

I don't think you've made much of a case that the current approach hurts
users at all, except possibly in the 'it is too hard to find
alternatives' case, which is a legitimate gripe. But, despite the
difficulty, they can still go out and find galeon to replace epiphany,
they can still use xmms or ogg123 or whatever the hell they want to play
their oggs, and in the end the difference between getting 120M (to get
GNOME tarballs) or 123M (to get GNOME + galeon tarballs) is not going to
kill anyone. That applies for both distros and people who download and
build their own stuff.

Furthermore, I believe there are strong values to GNOME to clearly
defining 'what GNOME is' and sticking with it. It's better for QA, l10n,
and a11y to have a defined set of things they can concentrate and work
on. It's better for any community marketing group (if one finally
springs up) so that they have a defined product to pimp to the world.
And, really, I think there is value to me, at least, to being able to
say 'this is what I love being involved in and this is what we create.'
Not 'well, we sort of do this, and a bit of that, and we thought that
was 4 out of 5.' I want to point to something and say 'the community I'm
a part of created this defined thing.' That's valuable to me, at least.

That said... the current system is clearly not great.
*The core is almost definitely getting too large, too fast. The criteria
probably do need to change, but how, besides 'this was what win31
included'? That would definitely slow growth, but would also make us
seem pretty feature impoverished compared to even win95 (and remember,
that was _8_ years ago.) 

*adding modules was a painful process that no one wanted to go through,
least of all release team. (At least in retrospect.) Anything that
reduces the need for that to happen again is good.

*It is definitely too hard to find quality apps; everything Iain has
said about fifth toe and apps.gnome.org are correct.

I don't have any brilliant, great ideas to solve any of these things. My
off-the-cuff suggestion is that one way that we could help alleviate the
problem is more meaningful groupings, like GNOME Office has striven to
be for many years. If someone had the desire to organize and motivate a
meaningful 'GNOME media' release with the same standards for QA, UI, and
a11y as the desktop release, it would take a huge amount of pressure off
the core. Ditto 'GNOME communications.' Do that, and you've knocked out
all the media stuff (totem, gnome-media, maybe RB in future, etc.) and
all the communications stuff (AIM, gnomemeeting, maybe evo in future?,
etc.) from core, while still giving QA, l10n, etc. defined sets of
things to work on, and still giving those hackers a sense of
participation in something bigger than themselves (which I think is
something most of us value.) I'm sure you could look at the core apps
and find other groupings as well. [Maybe 'display tools'- gthumb, gpdf,
eog, ggv?][And obviously a11y tools fall out of this as well.]

If you break things down in that way, 'GNOME' is still fairly clearly
defined ('it's desktop + media + communications') so you have those
benefits for all the teams, but you've reduced the pressure for the core
to grow and you have slightly more flexibility and less pressure on the
edges. You also more clearly define where we need to grow- if there are
enough tools for a 'group' of tools to form, then probably that means
there is interest and demand for them in a way that isn't necessarily
reflected in our current process.

Anyway, I'm really not sure that is a workable solution- it would
require strong leadership at the team/group level that isn't currently
there. But otherwise, it seems to solve the problems that I see that we
have. I don't think making things more diffuse, as Iain proposes, solves
these problems- it's a large-scale way of saying 'we don't know how to
do this, we'll just code an option.' 

My two cents-
Luis