Identifying the goals for GNOME 2.0The first step in discussing GNOME 2.0 is to identify what kind of beast the GNOME 2.0 platform is.At least one set of the variables is fixed: it will be based on the Gtk+ 2.0 toolkit, Pango and Glib 2.0. There two sides of the spectrum as I see them for GNOME 2.0 are:
But we have to attempt to measure the time it is going to take us to deploy a full desktop based on both, balance our time constraints with our desires and come up with a list of features that we want in GNOME 2.0. A not-so-visionary approachGiven the fact that we can not just "command" the contributor base to work on any direction a small team of people decide, and given the fact that as any other free software project we have a shortage of resources, I would like to suggest a conservative approach for attacking the problem.I believe that aiming for the Blue Sky scenario introduces a number of potential risks that we are better off not dealing with. The Gtk+ API changes are already big enough to force application developers to write against the 1.2 API or the 2.0 API with no way of using either one of the platforms. The blue sky scenario might lead to a number of problems:
We do have existing evidence from free software projects that the above might very well happen. Linux 2.4, KDE 2.0, Gtk+ 2.0, Nautilus 1.0, Evolution 1.0 have all slipped on their schedules as they were projects with more ambition than time on their schedules. Besides, GNOME 2.0 is not the end of GNOME. GNOME 2.0 is just the next major release of GNOME. There is always a chance for us to redeem our pride as programmers, hackers and architects with GNOME 3.0 and GNOME 4.0 The Blue Sky scenarioPlease continue at the "Blue Sky" document for a presentation of an optimal setup for gnome-libs 2.0. |