Modules

[Havoc Pennington <hp redhat com>]

Hi,

Let's try to create single-topic threads, to keep this thing
manageable.

Bart Decrem <bart@eazel.com> writes: 
> 2) What's all this about modules?  In the Apache model, there's an Apache
> Foundation and then 5 or so autonomous projects, such as the HTTP server
> project.  The foundation's only power is that they can decide whether a
> project is still a part of the foundation.  So similarly, there are
> currently a ton of projects under the broad Gnome umbrella.  These projects
> are and will remain fully autonomous: the Gnome Foundation doesn't have any
> power to tell those groups what to do, but surely the Foundation will
> identify an overall direction for Gnome and communicate with maintainers of
> packages to get their support in pursuing that direction.  So the question
> is: do we want to keep today's structure with tons of projects, some really
> modest, some pretty big, or do we want to somehow group projects into
> modules? My personal opinion is that today's structure seems to work
> reasonably well, so I don't see the need for intermediate groupings into
> modules, but I think others feel differently.
> 

I don't think there's any need to group sub-projects into modules (I
hadn't understood that that was the Apache way - I thought by
"modules" we just meant "projects".)

Anyway; to me the main issue is: how do we decide what projects are
part of GNOME?

Right now, we let any application that uses GTK use the GNOME CVS
server and become a GNOME project. However, our long-term goal is to
have all apps use our libraries, right? So, unless we want to be the
governing body for all open source GUI software, we may want to
exclude some of this stuff from the foundation. Then again, maybe we
don't.

I'd say at a minimum:

 - projects must be free software; we should likely copy the 
   Debian or opensource.org definition of this

 - projects should be actively maintained and worked on
   (Debian has a mechanism for punting projects that have 
   unhandled release-critical bugs; because we won't have a unified
   release of all projects, we can't really do that, but
   maybe there's some way to go about it)

 - should a 100-lines-of-code applet really be given the same 
   status as gnome-core?

I'm really not sure it's possible to have an objective criterion for
projects. Perhaps instead, we should be conservative and include only
the core desktop, GNOME Office, etc. in the initial list; then we can
add and remove projects at a later time, via a vote of some kind. This
is a more subjective process, but likely leads to a more coherent
result.

(In general I would lean toward more central control than Debian has;
they are effectively paralyzed by democracy at times, and their
technical direction and social climate suffers in some ways as a
result.)

Of course, this whole issue may become more clear if we clarify what role
a project actually plays in the organization, which is unclear to me
right now. If projects are purely an informal way to organize
technical stuff, and the membership list is what affects
decision-making, then it's probably fine to be really informal about
the list of projects.

Havoc