GNOME Integration with Online Services

While deciding about libgdata inclusion in GNOME 2.28, we (Release Team) somehow considered it didn’t make much sense to have libgdata in the desktop suite. So, one thing that came to my mind was that we need some space to aggregate development efforts aiming to integrate online social services in GNOME. Also, it seems that we need to highlight those modules in a more clear way as it seems that just a few people are aware of those GNOME-based technologies. In order to get “something” started before I forget it, I created this wiki page:

http://live.gnome.org/OnlineIntegration

I tried to include all the cool modules I know about that aim to integrate with online social services in some way: from instant messaging to maps, from Google apps to CouchDB. I tried to draft some proposed guidelines for the modules so that we can (maybe) define cross-module goals in the short-term. Providing GObject Introspection support could be one. Proving new plugins to Mojito could be another. Or maybe covering more online services. My impression is that Mojito brings a nice way to integrate data from different social services behind a simple API. Maybe a mid-term goal could be to thing about ways to integration online services in GNOME Shell?

Anyway, comments and suggestions are welcome!

Notes on the Future of GNOME: The Great Achievements

I promissed myself to write this series of blog posts a long time ago but now that Andy talked about GNOME’s decadence just before GUADEC, I thought it’s the right time to write this. :-)

I totally agree with Federico when he wrote on our Annual Report 2007 that GNOME has achieved its original goal. We reached a point where we have a desktop environment that “Just Works” for most of common tasks on a personal computer. However, it’s been some time already that having a desktop environment that just works is not being “enough” for our community and GNOME as a project. The symptoms of this collective “agony” show up every now and then in form of a bunch of random ideas about how to re-think the whole interaction model of GNOME, endless discussions about our 6-month development cycles, the urge to deprecate certain jurassic libraries, long conversations about the definition of GNOME itself, harsh comments about GNOME not having a clear direction, lack of leadership inside the community, and many many others. Those topics have been around for a long time (just Google them and you’ll find quite a lot of old threads on GNOME mailing lists) but we haven’t been able to translate them into a clear direction for the project. In my opinion, this has a strong relation with how we’ve been organizing ourselves since GNOME 2 release and the more fundamental goals of the project.

So, is GNOME in a state of decadence? Yes! Is it a bad thing? Not necessarely. It depends on how we react to this situation from now on. Why? Because what is in decadence is not GNOME itself (we are a great project with the coolest community!) but the current form of GNOME. Before going straight to the nasty problems and some of the core aspects of the current situation,  I’d like to first talk about the most important achievements of our community so far which, in my opinion, we should be really proud of and try to keep in some way. Those achievements are beyond the more obvious one of having developed a great desktop environment and development platform. They have more to do with the way we do things.  They might be obvious for a lot of people in GNOME but I think it’s important to mention them anyway.

The first and more important achievement of GNOME is our community. We managed to agregate, through the more than 10 years of project, hundreds of extremely talented and generous contributors. Not only that, we have also consolidated a very positive and welcoming atmosphere inside the community which makes it a very nice group to belong, have fun and hack on cool software. Another important aspect of our community is its diversity. We have volunteers, employed developers, companies and non-profit organizations from all around the world, working together in the same ecosystem. Additionaly, we have a relatively large user base which helps us to improve our software everyday. We gained trust from highly relevant stakeholders who use, develop, extend and deploy our software stack in contexts ranging from social inclusion projects to large public/private corporations. From my perspective, our community managed to grow and mature so much through the years because of our development process and the some fundamental principles that tacitly (and sometimes explicitly) defines GNOME software. That brings me to the next two important achievements of GNOME: development process and usability culture.

Even though I wasn’t there (I started to contribute to GNOME in 2004), it’s pretty clear that the GNOME 2 release was a moment of important changes in the community and the development process itself. The release team was founded to coordinate the development process and turn the collective work inside GNOME into a saner thing. Since then, we’ve learnt a lot. The general guidelines have evolved in such a way that nowadays we have a mature, stable and predictable development process which is relatively easy to understandefficient on the coordination of contributors with different levels of engagement and availability and scalable enough to deal with hundreds of software components. The efficiency and scalability doesn’t come from nowhere: they come from the fact that we develop software in a distributed way. GNOME developers dedicate their time to improve specific domains inside the project. Our collaboration dynamics is set in such way that individuals can have a lot of influence in GNOME in relatively short time. Unfortunately, the same development process and collaboration dynamics that bring so many benefits to GNOME also have some serious drawbacks (which I’ll talk about later).

Lastly, in my opinion, the usability culture inside GNOME is one of the most important assets of our community. We care about the users. There’s an implicit urge (explicitly expressed in our UI guidelines) among contributors that every piece of user interface should be as much intuitive as possible. We can easily recognize what has been done in a GNOMEy way or not. There’s a relatively clear understanding inside the community of how things should be done that is passed forward to new contributors everyday. Considering the distributed nature of our development process, having stabilished such a culture in GNOME is a great achievement! Even though this usability culture is something that strongly defines the way we do things everyday in GNOME, I think we haven’t taken full advantage of that as a way to re-define the direction of the project. Again, more on that later. :-)

I’m sure people will have different opinions about those achievements, what’s more relevant, what’s irrelevant, etc. That’s great. The bottom line here is to recognize that we’ve been doing a great job. Really. Those are achievements that we should try to maintain, improve and adapt depending on our needs. There are big challenges ahead though. Next post: the nasty problems and the urgent need to change.

GNOME 2.24 Roadmap Released

The GNOME Roadmap for 2.24 (and partially for 2.26 and future 2.x releases) is available at:

http://live.gnome.org/RoadMap

The GNOME Roadmap is a big-picture view of functionality we expect GNOME to include in short-term and long-term future. The roadmap is based on feedback from current GNOME developers and other community members.

We hope this roadmap increases the awereness about the future steps of the project inside and outside the community and helps us to look forward and plan where we want to go.

To have access to the Roadmap of previous stable releases, go to:

http://live.gnome.org/RoadMap/Archive

To know more about our Roadmap process, go to:

http://live.gnome.org/RoadMap/Process

Big thanks to everyone who contributed with information and reviews!

We need more Roadmap info

The deadline for replying the roadmap info request is today and there are still quite many modules without fresh roadmap. I decided to wait on more week for the replies before starting to prepare the first draft.

Maintainers and developers, wake up! Reply today and win a nice trip to the moon! Just let me know if you haven’t seen any roadmap request in your inbox.

GNOME Roadmap – Information requests for 2.24 sent!

As part of our roadmap process, we’ve sent the roadmap information requests to all module maintainers/developers. If you are a maintainer/developer of a GNOME official module and haven’t received the cited message, just let us know about which modules we’ve missed.

As usual, as soon as we have a first draft of the GNOME 2.24 roadmap, we’ll heat up some discussions in desktop-devel-list about this and the future stable releases of GNOME in order to get feeback about the roadmap, discuss about potential cross-module plans, and so on.

On 2.22, we’ve made important changes in our Desktop and Platform. The upcoming 2.24 release has an important role on consolidating those changes and preparing the ground for pushing the project to new directions. Let’s make it happen!

GNOME 2.22 Roadmap Released

The GNOME Roadmap for 2.22 (and partially for 2.24 and future 2.x releases) is available at:

http://live.gnome.org/RoadMap

The GNOME Roadmap is a big-picture view of functionality we expect GNOME to include in short-term and long-term future. The roadmap is based on feedback from current GNOME developers and other community members.

We hope this roadmap increases the awereness about the future steps of the project inside and outside the community and helps us to look forward and plan where we want to go.

To have access to the Roadmap of previous stable releases, go to:

http://live.gnome.org/RoadMap/Archive

To know more about our Roadmap process, go to:

http://live.gnome.org/RoadMap/Process

Big thanks to everyone who contributed with information and reviews!

GNOME Roadmap – Information requests for 2.22 sent!

As part of our roadmap process, we’ve sent the roadmap information requests to all module maintainers/developers. If you are a maintainer/developer of a GNOME official module and haven’t received the cited message, just let us know about which modules we’ve missed.

As usual, as soon as we have a first draft of the GNOME 2.22 roadmap, we’ll heat up some discussions in desktop-devel-list about this and the future stable releases of GNOME in order to get feeback about the roadmap, discuss about potential cross-module plans, and so on.

Fortunately, quite many modules have been proposed for GNOME 2.22 and some interesting and challenging discussions have already started in desktop-devel-list.

One of the major community goals for 2.22 is to have as many people as possible reminding Vincent Untz about his thesis! Go, Vincent, Go! :-P

GNOME Roadmap – Call for Update

As you probably know, according to our development schedule, we are officialy feature-frozen now. Therefore, it’s time to cleanup and update our Roadmap to reflect the actual result of our development work in the 2.19/2.20 feature set.

We kindly ask you check the roadmap[2] of the modules you maintain. If there are features that were not implemented for 2.20, please move those to GNOME 2.22 section accordingly. In case there are some features missing there, please add those to the respective section.

You can either directly edit the wiki page or reply us with the new roadmap information.

It’s very important to cleanup and update the GNOME Roadmap as soon as possible so that it can be used as a reliable source of information for writing the GNOME 2.20 release notes.

Update: If you want to update your module-specific roadmap wiki page as well, feel free to do so. This will save you some time later for sure.

On GNOME 2.22: the rise of a revamped platform and desktop

We’re now in the middle of the development cycle for GNOME 2.20 and our plans were already published in our RoadMap page. Of course, there are some very nice stuff coming for the next GNOME stable release as you can see there.

I’d like to bring some attention to an important thing that can make a lot of difference for GNOME next year. We have a very good opportunity to make big, necessary and important changes in our desktop and platform in the 2.22 release. Why am I saying that?

From the roadmap process we’ve kicked off in the 2.20 development cycle, it’s perfectly clear (to me) that several important changes are coming (potentially for 2.22). Here are some of them:

  • Revamped session management: headed by Dan Winship. Recently, a branch has been created with the new code.
  • Next iteration of the GNOME Configuration system: headed by Emanuelle Bassi. Possibly, an initial code will be shown and discussion on this topic will happen at GUADEC.
  • Revamped VFS API: it’s called GFVS and is being headed by Alex Larsson. Current code resides on a git repo. For a good overview on GVFS, read this message Alex to gtk-devel-list some time ago. Current status and discussion will be take place at GUADEC.
  • New documentation technologies: it’s called Mallard and is being headed by Shaun McCance and Don Scorgie. Current code resides here (Mallard) and here (Rarian, replacement for scrollkeeper). We have 2 Summer of Code projects for the development of a documentation editor for GNOME which uses the new infrastructure. Some of the new stuff will probably be used in 2.20 already. Talks about related topics at GUADEC.
  • New applets API: developed by Ryan Lortie. Current code resides on git repo (I don’t remember where it is). Talk and discussions on this topic will happen at GUADEC.

There are others: GTK+ additions and more widgets consolidation (Project Ridley), SoC projects (some of them could possibly land in GNOME 2.22), Bugzilla 3.0, and so on. Also, there are some important topics which needs to be seriouly and objectively discussed like web services integration, better desktop integration with instance messenging and voip, search engines and metadata, and others. A combination of effort, time, manpower, good communication and community cohesion will decide if those goals will be achieved or not.

Let’s keep those goals in mind for 2.22 and try to stay focused as much as possible so that we can make them a reality. GUADEC will be a wonderful time to discuss those topics.

GNOME 2.20 will rock a lot! Let’s make 2.22 a 23 release!

Attribution-NonCommercial 3.0
This work is licensed under a Attribution-NonCommercial 3.0.