Putting the Network back into G(N)OME – An Interview with John Palmieri
Paul Cutler interviews John Palmieri to discuss network applications and innovation in GNOME, based on John’s recent talk at GUADEC 2009.
You recently gave a talk at GUADEC entitled: “Thinking Outside the Box: Bringing the Network Back into G(N)OME”. What was your inspiration for giving that talk?
Back when the Linux desktop’s biggest claim was that one could make it look like a Mac OS, Windows, Solaris (CDE/OpenLook) or even NextStep desktop, two contenders arose to lead the charge towards developing an actually viable Linux desktop operating system. Of course I am talking about KDE and GNOME, both of which I compiled and used since they initially showed up on the scene. I like to joke that I stuck with GNOME because one day KDE wouldn’t compile for me. Yhe truth, however, is that the GNOME Panel was probably my biggest source of frustration with it crashing all of the time.
The real reason I stuck with GNOME was that it had a vision or at least was very good at making me feel like it had a vision. In those days, G.N.O.M.E. stood for the GNU Network Object Model Environment, which conveyed a meaningful purpose of developing a system of small components that linked together to form larger programs. This was very much in line with the Unix principal of writing a program to do one thing well and pipe them together to solve complex problems.
Over time we realized that for a desktop environment, this vision was a bit too technical and G.N.O.M.E. became to be known as GNOME and our vision shifted to becoming a desktop that your grandmother could use. After working on D-Bus and OLPC and witnessing the work at Red Hat on Yarr!, Mugshot and Online desktop, I sort of realized that we don’t just want to be the desktop your grandmother could use – we need to be the desktop your grandmother, mother, sister, brother, niece, nephew and best friend, to name a few, WANT to use. People use computers for communications and community these days and the only way to achieve that is through the smart use of the network.
I have to admit I thought it was a pretty cheeky title. Since the N in GNOME used to stand for network and we had already done such a great job of networking inside the box with D-Bus, I thought, why not ask people to think outside their own boundaries by thinking about how we could harness applications running outside of the desktop to make the desktop a more compelling experience.
GNOME has had a number of technologies over the years such as CORBA and Bonobo (which was itself similar to Microsoft OLE) that have tried to focus on networked computers working together. What did these kind of technologies do well, and what opportunities did they have for improvement?
So, Microsoft OLE was one of the many inspirations that geniuses like Miguel De Icaza and Nat Friedman had in mind when starting GNOME. People knock Miguel because he went on to create Mono, a clone of another Microsoft technology, but the truth is his vision and ability to form large communities to execute that vision is something to praise. Without him there would be no GNOME.
Sometimes our vision was good but needed some tweaking. This was the case with CORBA and Bonobo. Instead of taking our vision and figuring out what we really needed, we got caught up in the hype that was CORBA. CORBA is a networked object model that allows you to write an object in any language and have applications piece these objects together to form a larger application. In this larger application, the pieces can run either in-process or out-of-process. The truth is, CORBA is highly tied to C/C++ and pretty overly complicated. We never even looked at the networking part where you could run objects across a network via CORBA.
Bonobo was an attempt to put a layer in between CORBA and the programmer but in the end, most of what we wanted to do was much simpler to do with GModules and GObjects directly. For any out of process interactions D-Bus’s communication bus model along with a pseudo object mapping layer was much easier to wrap ones head around than a full blown object model.
The idea of simplifying development by making applications concentrate on what they were good at was a great idea, but in practice, CORBA turned out to add more complexity than it was worth. In a world where you had most, if not all of the source code, it was much easier to achieve the same goals using pluggable libraries like gstreamer, in process widgets and an inter-process communications bus for the times neighboring processes needed to communicate.
You were a long time contributor to D-Bus, which eventually replaced Bonobo. D-Bus enables communication between desktop applications. In your opinion, what has led to the success and wide spread adoption of D-bus?
Well, many technologies replaced Bonobo, D-Bus just replaced the inter-process communication bits. We still don’t have a full blown object model but that is because we don’t need one. I attribute D-Bus’s success to a couple of factors. First is its simplicity. By adding routing, auto-discovery and native marshaling of data types to Unix domain sockets, and integrating the dispatching into both the glib and Qt main loops, we gave the developer all the power they needed without having to dive into the details of systems network programming. Furthermore, the native bindings and relative simplicity of recreating the D-Bus spec from scratch led to implementations that matched the work flow of each environment. Where CORBA meant adapting your programming experience to match the CORBA model, D-Bus language bindings meant developers got a much more familiar experience. You still need to know a few D-Bus’isms to produce effective D-Bus code, but the barrier to entry isn’t quite as high.
Yet another reason for the success of D-Bus was that unlike CORBA, which was re-purposed for the desktop, D-Bus was designed with the desktop in mind from day one. And then there is the community of applications that sprung up around D-Bus. Before HAL hit the scene, we were interacting with system services through setuid hacks and haphazard event systems which sometimes worked if the moons were aligned and your hardware configuration was correct. D-Bus gave us the ability to centralize event policy in a few compartmentalized applications which sped up the solving of issues such as desktop hot-plug and device configuration. Because we were able to see such large gains so quickly with D-Bus, more and more people turned to D-Bus as a new way to solve whatever programming issues they were working on. It open the floodgates of ideas on what is possible when communication becomes a central theme of application design.
What are some of your favorite applications that take advantage of D-bus and why?
It is hard to say, I love them all, even the ones which use D-Bus in a crackful way. That being said I like apps that get out my way and just do the job they are meant for. NetworkManager kicks butt. Chris Blizzard of Mozilla has to work with Mac and Windows. He also boots into Fedora to keep up with the progress the Linux desktop is making. Whenever I see him he extols the virtues of NetworkManager and how they are light years ahead of anything in Windows or even MacOS. Wireless just works, VPN just works. I also like the libraries like Mojito and Telepathy which use D-Bus to provide a standard API for anyone who wishes to use it. One of the most unique applications I have heard of was a guy on the mailing list who said he uses D-Bus with TCP/IP sockets to control those card reading systems some cities have installed in their subways. He didn’t say which city but it is kind of cool that people have found it useful for applications I would have never even imagined.
You made the arguement at GUADEC that GNOME desktop developers should also be web service developers. What are some of the opportunties in the GNOME desktop and web services GNOME developers could play a role in?
To tell you the truth I don’t even know of all of the initiatives out there. I came to GUADEC with my talk not to just say we should be doing this but to also say people are doing it and they need to be more public about what they are doing. Here are the key areas I think we need to expand on though:
- Data sharing – one place we can really give proprietary software a run for its money is to have our content creation tools make it easy to share data and to collaborate on creating content.
- Metadata – people forget that code is content too and we have a lot of metadata on that code that would make it easier and less error prone to develop GNOME. Metadata such as release history should be queryable and should hook up to some sort of notification system.
- Existing service connections – people put their lives in blogs and on facebook, etc. We need to provide easy access to those services. We also need to make it easy to move from say twitter to the more open indenti.ca.
My favorite quote from your presentation focused on what adding network technologies to GNOME applications means for GNOME’s end users: “Because meaningful connections turn consumers into producers!”
People who produce are the backbone of our community and most of us started as users. It is because of good experiences, these meaningful connections I speak of, that we decided to do more and produce content. If we can get more people producing content our numbers and influence grow. By adding networking, or in more social speak, communications to our applications, we increase the potential for meaningful connection to happen. The more people feel they are not stuck on an island by themselves but are instead part of a larger community, the more incentive they will have to start contributing content of their own in order to make the experience with that community richer. Just look at Twitter. Why do people take time to pull out their phone to write a short blurb about what they are doing or feeling? It is because they know they are potentially networking with millions of people who may end up learning a bit about the poster. The poster has now become a producer, not because they felt they should produce something but because the meaningful connections proved to be a powerful incentive.
You highlighted a number of GNOME applications that you believe are taking advantage of the network today. In your own words, can you describe what excites you about the following applications:
Most of us blog. Right now I’m writing you answers to your interview questions but it is all very deliberate. Tomboy is sort of quick, at this moment, stream of consonance writing medium. Soon we will be able to easily publish and sync those notes with snowy the web app component to Tomboy (or GNote if someone writes the functionality into it). Going further than that, what if the same publishing concept was extended to contextual situations such as reading documentation in DevHelp and then being able to upload notes on say a code snippet so others reading the same document can also read your notes.
Abicollab / OLPC:
Collaborative editing is just a great idea on many levels. Imagine a teacher tutoring a child without having to look over their shoulder or even having to be in the same room. Or, how about teams needing to put together a single report together. By making it real time collaborative instead of splitting up each section, the text will most likely flow better and mistakes can be caught and corrected in real time.
Rhythmbox and Banshee:
In the world of media players content is key. If I can’t get my hands on content they are useless to me. Being able to buy songs or listen to internet radio out of the box, without having to configure things makes these apps useful the first time I launch them.
One Laptop Per Child and Sugar:
I worked on these projects so I am a bit biased, but from the beginning the concept of the mesh network revolutionized how we thought of connectivity. It meant that every activity had to in some way give the ability for the user to produce something to share over the mesh. It could be simply bookmarks in the browse activity or pictures in the capture activity.
Going through the logs of a past conversation. Cost – a couple of minutes. Feeling “connected” to your friends – priceless
Seriously though, Empathy not only gives you chat functionality, it has widgets ripe for embedding in other apps.
What brainstorming ideas have you had for new features or new applications that can leverage the network and collaboration?
Right now I am working on developer tools in the guise of the Fedora Community portal. What I would love to see is real time communications between upstream and the distros where we get instant notice of releases and patches to the people who care. If we can make development more open and streamlined instead of behind walled gardens we can spend more time innovating instead of chasing bugs.