During the first few months of 2008, a few Release Team members
discussed here and there about the state of GNOME. This was nothing
official, and it could actually have been considered as some friends
talking together about things they deeply care about. There were
thoughts that GNOME could stay with the 2.x branch for a very long time
given our solid development methods, but that it was not the future that
our community wants to see happening. Because of lack of excitement.
Because of lack of vision. Slowly, a plan started to emerge. It evolved,
changed, was trimmed a bit, made more solid. We started discussing with
a few more people, got more feedback. And then, at GUADEC, the Release
Team proposed an initial plan to the community that would lead the
project to GNOME 3.0. Quite some time passed; actually, too much time
passed because too many people were busy with other things. But it's
never too late to do the right thing, so let's really be serious about
GNOME 3.0 now!
Let's first diverge a bit and discuss the general impression that GNOME
is lacking a vision. If you look closely at our community, it'd be wrong
to say that people are lacking a vision; but the project as a whole does
indeed have this issue. What we are missing is people blessing one
specific vision and making it official, giving goals to the community so
we can all work together in the same direction. In the pre-2.x days, the
community accepted as a whole one specific vision, and such an explicit
blessing wasn't needed. But during the 2.x cycle, with our six months
schedules, it appeared that everything (community, development process,
etc.) was just working very well, and as the vision got more and more
fulfilled, the long-term plans became less important as we focused on
polishing our desktop. But we've now reached a point where our next
steps should be moving to another level, and those next steps require
important decisions. This is part of what the Release Team should do.
Please note that Release Team members don't have to be the ones who have
the vision; we "just" have to be the voice of the community.
(As a sidenote, the roadmap process [1] that we tried to re-establish
two years ago was a first attempt to fix this. Unfortunately, it turned
out that we were missing the most important side of things: a
project-wide roadmap. This is because a collection of individual
roadmaps isn't enough to create a project-wide roadmap.)
So let's go to the core topic and discuss what the GNOME 3.0 effort
should be. We propose the following list of areas to focus our efforts
on:
- Revamp our User Experience
- Streamlining of the Platform
- Promotion of GNOME
There are also other potential areas that are worth exploring if there
is enough interest from the community.
From a release management perspective, there are various questions that
are raised in the GNOME 3.0 context. We definitely need a plan to
organize the development (see below for details on it), but we might
also want to take this opportunity to rethink how we ship GNOME: are the
module sets still the best way to deliver GNOME? There is no obvious
answer to this, but the way we will present GNOME in the future will
certainly have an impact on this.
Revamp our User Experience
============================
When talking with some great people at GUADEC about GNOME 3.0, one
concern that came more than once was that it would be an error to do
GNOME 3.0 without any big user-visible change. While some of us didn't
necessarily agree with this concern, it was still a fairly valid one.
But it turns out that if you tell the community that there's something
after 2.x, then the community will stop vaguely thinking about future
ideas and start working on concrete plans.
It seems pretty clear now that there are two important ideas that can
have a real positive impact on the user experience:
- GNOME Shell [2]: the shell idea is not just about changing the panel
and the window manager. It's about changing the way you start an
activity and how you switch between two different activities. Or more
generally, how you manage your different activities on the desktop.
- Changing the way we access documents (via a journal, like GNOME
Zeitgeist [3]): having to deal with a filesystem in their daily work
is not what makes users happy -- on the contrary, they generally just
want to access their documents and not to browse their hard disk.
Providing new solutions to this problem (using timelines, tags,
bookmarks, etc.) is something that has been of interest in our
community for a long time, but we never completely jumped in. We
simply should.
These two ideas can form the basis of an overhauled GNOME user
experience; they are not the only changes that we can and will do, but
they definitely are the most advanced projects to help us move forward
in terms of user experience. The GNOME Shell and the GNOME Zeitgeist
projects are indeed already well underway, with working code and strong
development going on for nearly six months. This means the effort is not
about starting those projects, but about first completing them so that
people can work daily with them, and then polishing them.
There's one obvious question related to those potential changes: what
will happen to the old way of doing things? For example, will we still
make the GNOME Panel available if, for some reason, people are not
immediately happy with GNOME Shell? There's no obvious answer to this,
and this will have to be discussed. Some of us believe that it would be
a good thing to keep providing the old elements for a limited time, to
ease the migration. That being said, doing that would obviously take
some development resources and slow down work on what should be the
future. Not an easy choice, of course. However, it's worth noting that
distributors and other community members using GNOME to build enterprise
products will most certainly help maintain the GNOME 2.x shell for quite
some time, and the project will support that to the greatest reasonable
extent.
Streamlining of the Platform
============================
Since GNOME 2.0 was released in 2002, there have been quite some changes
in our developer platform: new APIs have landed and some other APIs have
been deprecated. There are even some platform libraries that are now
nearly unused. This just creates some confusion and does not make the
life of developers easy. Since we want applications to be developed for
GNOME, this is an issue that we should fix.
Hence, it makes perfect sense to rework our platform and try to clarify
it for newcomers. Here are some steps that should be considered:
- move all of the deprecated libraries out of the platform, so people
stop using them in new code;
- create a staging area in the platform for libraries that aim to be in
our platform but do not offer enough guarantees at the moment (like
GStreamer): this will send a clear message on what should be used;
- include new exciting technologies that we're starting to see used in
our desktop. Some obvious examples are 3D effects (with Clutter) and
geolocalization (with GeoClue and libchamplain).
- rework the way we present the platform to also integrate some of the
external dependencies: while, say, D-Bus or Avahi are external
dependencies, they are definitely what we want developers to use. And
it's easy to be more explicit about this.
- move the bindings closer to the platform when we talk about bindings,
to make them even more visible and attract developers from all
languages.
The work that has been done on GObject introspection [4] will also
deeply change the way GNOME development can be done; we've already
started to see how it can be leveraged in GNOME Shell, and the fact that
it can bring new popular languages like Javascript to GNOME is a huge
benefit.
All this has of course an impact on our applications: we will have to
port the code away from all deprecated APIs, but also prepare our
applications to be ready for forthcoming changes, like GTK+ 3.0. This is
luckily a task that we can easily quantify and the progress can be
tracked on a simple web page.
Promotion of GNOME
==================
Our community has historically been strong on the development side, but
we have always struggled to promote GNOME. That's because this is
certainly no easy task. Our user base has however grown significantly
since our project started, and we failed to recruit people that could
have helped here. GNOME 3.0 is an opportunity to change this and attract
contributors that can help forge the communication around the GNOME
project. The promotion of the project is definitely part of what makes a
good release, and the Marketing Team can contribute a lot to the success
of 3.0.
Of course, an obvious goal for the promotion of GNOME in this context
would be preparing the 3.0 release and the messaging around this
release. After highlighting the changes done specifically for 3.0, one
other immediate idea is to simply show the progress the GNOME project
has made since GNOME 2.0: GNOME 2.10 could arguably have been named 3.0
when compared to 2.0, and the same goes for 2.20. This could serve as a
basis for work on explaining why our evolutionary approach in
development works well.
One common issue that often came up when discussing how to promote GNOME
was that promoting the desktop as a whole is difficult. But there's no
need to do that. We can instead focus our messaging around the GNOME
experience: the basic GNOME experience simply is the GNOME Shell; but
users actually do not use just the basic desktop, and they use
applications. We've never explained why the applications developed for
GNOME are good; we've never really put those applications under the
spotlight. For instance, why shouldn't we put on the front page of the
GNOME website a clearly labeled message about a good music manager? We
wouldn't have to choose between Rhythmbox or Banshee: we can promote
both, since both are good in different ways, and both are good examples
of the GNOME experience.
This leads us to a third item: relaunch our website. While our current
website is known for being broken in various different ways from a
communication point of view, we've not been able to deliver the new
version that would fix things. Fixing the website is a large task, but
we should not give up on this: the GNOME website is a core part of the
GNOME identity, and we cannot ignore the current issues. This happened
because of lack of manpower, but the good news is that there are web
developers that are fond of GNOME and just don't know they can help the
project.
And the fact that web developers can play an important role is also
valid for all of our users. As of now, we are not really empowering
users to promote GNOME: what should a user do if he wanted to do so? We
all know how some viral communication can benefit a project like ours,
so the solution is simple: let's give ourselves a chance to make this
happen!
Other Potential Areas
=====================
The areas presented above are actually not a big surprise to anybody
following the GNOME development and are fairly obvious choices. However
there are other candidates that would help make GNOME 3.0 a success.
Those potential focus areas simply need people to step up so we can be
sure expectations can be met.
- Desktop Testing [5]: with the recent creation of the Desktop Testing
Team, this topic becomes more and more visible. We can innovate
there, and we actually should: we helped show the way in the free
software world when it comes to usability and accessibility, and
there is no reason for us not aiming at a similar experience for
desktop testing.
- Art: a GTK+ Theming API hackfest was held in February, where some
good consensus was reached on how theming should be done in the
future. This gives us a new opportunity for an updated look and feel.
This can happen with the help from artists: if we have artists and
coders working together, with the coders knowing the needs from
artists, then there is no doubt that the result will simply rock.
- People: the telepathy framework has nicely progressed over the last
few years and it's offering great perspectives to integrate instant
messaging, and more generally, interaction with people in other
applications. With some focus, it could contribute to make GNOME a
social desktop where you do not only work on documents, but where you
also really interact with your friends.
- Mobile: the GNOME Mobile platform was first introduced in GNOME 2.24,
and it helped make our presence in the mobile world visible. A lot of
the changes that are planned around the platform are of direct
interest to the Mobile Team.
Organizing the Development
==========================
We need to define a clear timeline for the development, with a schedule
that will let us check that the development is on the right path. The
end goal is simple: we want to deliver GNOME 3.0 by the time of 2.30
release. This makes sense for various reasons: from a technical
perspective, the timing is good for the integration of new technologies
or projects (GNOME Shell, for example); from a messaging point of view,
the evolution from 2.30 to 3.0 is logical and easy to understand. It's
worth pointing out that if you compare GNOME 2.26 with GNOME 2.0, it's
actually quite surprising to see that we have still kept a 2.x version
numbering while we could be at 3.x, or even 4.x. Making GNOME 2.30 a 3.0
version is of course still an ambitious goal, but we can achieve it
thanks to what we learnt in the past.
The development methods we have adopted during GNOME 2.x are overall
good methods and the community has become used to them. For example,
contributors understand the reasons behind the freezes we have and try
their best to respect those freezes. This is not something that should
be changed because we now have an opportunity to try something else; on
the contrary, those methods will make our path to 3.0 easier. Some
regressions were pointed out during the past few cycles: those should
not be ignored and we believe part of the reasons why they happened is
that only a subpart of our community was trying to move forward, which
created some controversy; having a community-wide focus should limit
those controversies, and hence the regressions as felt by the community.
The six months cycle is now part of our culture and has an impact on the
free software ecosystem, with distributions basing their schedule on our
schedule. Trying to change this crucial element of our release
management, which works quite well, would certainly not help us in any
way. Therefore, we will keep six months-based schedules. But having
project-wide and long-term goals require some adaptation. GNOME 2.28
will not be an independent release or a destination in itself, but it
will be a logical step towards GNOME 2.30, and therefore GNOME 3.0.
Of course, we should be prepared to consider the fact that GNOME 2.30
might not be good enough for us to call it 3.0. All of our time-based
releases are also quality-based releases: if the QA Team feels a release
should be delayed, then it will be delayed. In the context of 3.0, this
is something that we should be ready to diagnose early on during the
2.29 development cycle and we should not be afraid of keeping GNOME 2.30
as 2.30 and waiting for GNOME 2.32 for the 3.0 release, for example.
That being said, we want the community to try as hard as possible to
make "GNOME 2.30 = GNOME 3.0" a success.
On a more general note, overlaying a long-term development cycle (3
years for example) with project-wide goals, on top of our six months
development schedules is something we want to keep after GNOME 3.0.
Conclusion
==========
You can already check out the schedule for the 2.27 and 2.29 development
cycles [6]: it contains some concrete steps and deadlines that will help
keep our work focused to make GNOME 3.0 a reality.
As already mentioned, this is an ambitious plan and it will only be
realized if everybody comes out and helps. Companies can contribute a
lot -- for instance, the GNOME Shell effort is doing great thanks to Red
Hat's involvement. But GNOME wouldn't even exist without all of the
volunteers who are passionate about the project. It's because this
passion is so strong that we can build such a plan!
We're getting there. We strongly believe that all this can make a good
plan for GNOME. Sure, it's not perfect. And there will be disagreements
and issues along the road. But it is the way forward.
The GNOME Release Team,
[1] http://live.gnome.org/RoadMap/Process
[2] http://live.gnome.org/GnomeShell
[3] http://live.gnome.org/GnomeZeitgeist
[4] http://live.gnome.org/GObjectIntrospection
[5] http://live.gnome.org/DesktopTesting
[6] http://live.gnome.org/TwoPointTwentyseven
--
Les gens heureux ne sont pas pressés.
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list gnome org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
