GNOME release sets

This is an attempt to reconcile two seemingly intractable points of view.

GNOME should be a bare bones graphical shell with essential utilities and leave application distribution to the distributions.
GNOME should be an all-singing all-dancing computing environment.

The people in the former camp ask questions like "why does GNOME need photo management software anyway?" while the people in the second camp wonder why GNOME hasn't caught on to the fact that photo management software is essential these days.

So here's a proposal to have a number of release sets in the official GNOME desktop. Embedded platforms would choose just the platform. Some distributions would choose to ship just the core of GNOME and not repackage the multimedia applications or the office productivity applications. Or they may decide to choose the applications which use the Java or Python VMs rather than Mono. The important thing is that all of these applications would be in the GNOME release.

GNOME development platform
Shipping the platform would be essential for all the rest. Its contents would rest unchanged from http://live.gnome.org/TwoPointFifteen/Platform The GNOME platform should remain low-level, C based, a lowest common denominator for services which all GNOME applications can expect on any platform (including embedded).
GNOME platform bindings The bindings set should be inclusive - including bindings for the most active and popular binding projects around - C++, Python, Java, C#, Ruby at least. Applications written in these languages would be considered for inclusion in all of the release sets except the core platform and the core GNOME distribution.
GNOME core
- See http://live.gnome.org/TwoPointFifteen/Desktop for the current GNOME desktop release. The core GNOME distribution will include only a bare bones desktop and graphical shell, with basic applications such as web browsing, email, text editing and so on. The core desktop release should focus on being lightweight and adaptable to a wide range of platforms, including small screens and thin clients. The core desktop should include applications in C only. From the existing release, the following applications seem better placed in other release sets:
  - gnome-games
  - ekiga
  - nautilus-cd-burner
  - sound-juicer
  - totem
  - vino
  The following applications/proposals would be moved to other release sets based on the requirement that the core be C only:
  - deskbar-applet
  - gnome-python-desktop
  - Tomboy
New release sets
- The initial additions to the release sets would be:
- GNOME admin
  - This release set will contain software useful to system administrators for large-scale deployments, and will include remote administration and system lockdown tools. Initial contents:
    - Pessulus
    - Sabayon
    - Vino
    - Alacarte?
- GNOME Office
  - The GNOME productivity suite, including integrated office applications, word processor, spreadsheet, project management and related software Initial contents:
    - Abiword
    - Gnumeric
    - Planner
    - Glom
- GNOME Media
  - The GNOME Media release set will contain all the applications you use from day to day - music and photo management, multimedia editing tools and more Initial contents:
    - f-spot
    - nautilus-cd-burner
    - rhythmbox
    - serpentine
    - sound-juicer
    - thoggen
    - totem
- GNOME Connect
  - GNOME Connect is a grouping of applications to connect you with friends and family - includes instant messaging and collaboration tools, and videophone/VoIP for free phone calls. Initial contents:
    - ekiga
    - gaim
    - xchat-gnome
    - straw
    - gnome-blog
- GNOME Power
  - Power users have special needs that aren't fulfilled by typical tools. Power users want to hack on the desktop, and make the desktop act the way they decide. Initial contents:
    - Brightside
    - Deskbar (plus gnome-python-desktop)
    - Devil's Pie
    - Gimmie
    - Tomboy
- GNOME Games
  - A collection of games, which will hopefully grow. Initial contents:
    - gnome-games
Other possible ideas:
- GNOME Art
- GNOME Kids
- GNOME Developer

Advantages, disadvantages

The advantages:

Getting more GNOME developers invested in the GNOME release process.
Recognising the efforts of GNOME application developers not contributing to a bare-bones desktop
Showing our community as inclusive rather than exclusive
We will make GNOME exciting again, at least for a while
GNOME will begin delivering high-quality applications to its users, rather than allowing those applications to develop in a vacuum around the project
In an ideal world, we will be increasing collaboration and a shared codebase across several actors.

The disadvantages (or rather threats):

We will inevitably end up having competing applications for release sets. gthumb versus f-spot, rhythmbox versus muine, straw versus liferea and so on.
GNOME risks becoming too big a tent, like (say) debian. We already have too many communication channels and a hard time tracking what's happening - if we double the number of applications, that could get worse
GNOME Office 2 - the GNOME Office release set is essentially unmaintained and abandoned - there was no release team buy-in, or developer buy-in.
There are certainly others I haven't thought of

I would suggest that we set objective standards for the inclusion of apps in a release set (product activity, release regularity, stability and HIG compliance, for example -- see GnomeCertification) and then freely include applications which duplicate functionality in the user set. We will be putting a stamp of approval on applications, signalling to repackagers that we consider all of these applications to be worthy of the GNOME mark, and the redistributors will then choose the one(s) they want to ship.

The release team should be responsible for maintenance of the release sets, but obviously not for the applications therein.