Canonical Voices

Posts tagged with 'article'

jono

Last week Benjamin Otte shared some thoughts about GNOME that were pretty stark. It gathered some steam and hit Slashdot and this all happened the week GUADEC was taking place in A Coruña. I wasn’t at GUADEC :-( but I can imagine there was some fervent discussion about the blog entry.

The gist of Benjamin’s blog was that people are leaving GNOME, that the project is understaffed, and arguably the reason for this is that GNOME has lost its direction and Red Hat have overtaken the project as the primary contributor-base. Of course I am summarizing, but check out the original post if you feel I am not representing Benjamin’s views fairly.

I wanted to share a few thoughts. To be clear: these thoughts are my own, and I am not speaking on behalf of Canonical, but I am speaking from my experiences as someone who has primarily been affiliated with Ubuntu and as a Canonical employee. My feedback is going to be frank but I really do care about GNOME as a project, and this feedback is intended from a position of love for the project and to be open and transparent about my own experiences as just one set of eyeballs in this story.

Actual eyeballs.

Fortunately, I think all of these problems are solvable, but for them to be solved GNOME is going to need to do a little soul searching to discover and focus on the right problems and explore and deliver the right solutions.

A Little History

To provide a little context, my interest in GNOME pre-dates my involvement in Ubuntu. I have worked on a few applications that use the GNOME platform (Jokosher, Acire, Lernid, and most recently Ubuntu Accomplishments) and I have had a long interest in where the project is moving forward and as a core part of Ubuntu. I used to go to GUADEC every year, and I consider many folks in the GNOME project to be good friends.

While I care about where the project moves forward I too have also become concerned about the direction it is going in, not in terms of the design and user experience of GNOME (there are other, better versed people to assess this work), but instead in terms of how the project works with others such as companies, developers, and other partners.

In my mind GNOME has become bittersweet. I remember back at GUADEC in Stuttgart in 2005, discussions started happening about what form GNOME 3 would be in. As the years progressed the project struggled to decide on a final vision for what GNOME 3 would look like. This is not surprising: GNOME 2 was such a smashing success that GNOME 3 was going to be difficult second album time. Ideas were shared and bike-shedding occurred, but ultimately it seemed that the project was lacking leadership to take take all of these ideas and flip the switch to a vision and design and move it forward.

Around this time Ubuntu had become arguably the most popular way in which people were consuming GNOME and we (Canonical) were hiring more and more people to perform this integration work (which is no light task, as any distro developer will tell you).

If all else fails, bribing people with bubble-wrap grows popularity.

Back then Canonical was taking quite a bit of heat for “never writing code and just shipping other people’s work” (which I always found a misguided viewpoint as integrating and delivering a solid Free Software Operating System is significant work and a great contribution to the wider Free Software commons).

We were starting to find though that there were areas of GNOME 2 that we felt could be improved and expanded (largely based on feedback from our users). We started growing a design competence and hiring developers to build new code to add improvements to the experience. Many technologies were created such as the messaging menu, notify-osd, dbusmenu and the global menu, control center improvements, and ultimately Unity as an additional shell for GNOME.

I remember this time vividly. I was in weekly discussions with Mark Shuttleworth, Rick Spencer (Ubuntu desktop team leader), Ivanka Majic (head of design), and David Barth (head of engineering these components). Our goal was simple: be able to showcase these technologies in Ubuntu and bring value to Ubuntu users, but to also ensure they were contributed to the wider GNOME project as technology that could help the general project in moving forward.

I personally saw this all boil down into pretty simple parts: Canonical and GNOME were partners and it was a mutually beneficial relationship – the GNOME desktop with barely any users defeats it’s purpose and Canonical was helping to deliver it to millions of users in Ubuntu, but Canonical could not build an awesome Ubuntu without the wonderful components in the GNOME desktop to fill in the many different pieces in an OS.

My simple philosophy was also marinaded in the gift culture of Open Source and Free Software: Canonical was paying designers and developers to produce new code that could be of value (and thus offered as a gift to the GNOME commons) and as with all gifts, while it may not be exactly what you want (and may need some adjustments and improvements), I presumed there would be a polite, respectful, and open discourse to take these contributions and bring them into the shared commons that was GNOME, particularly as they were created with GNOME in mind.

This was not my experience of what happened.

Partners

I was really disappointed with what resulted. After years of Canonical and Ubuntu being criticized for not contributing code, when we then engaged in writing code we were met with a frosty, suspicious, and at times, frankly entitled attitude from some parts of the GNOME camp.

Now, don’t get me wrong, Canonical was not perfect here either. I fully admit that some of this relationship could have been handled better (and I am partially to blame here). We made some mistakes early on in which code was released too late and there was sometimes not enough open discussion. Retrospectively, we could definitely have done better in being more pro-active in some parts of the relationship too. At the time we were still learning how to do this, and as such we made some mistakes too.

Canonical wanted to strike the right balance of bringing innovation to Ubuntu releases with new features, but to also openly engage and contribute that innovation to upstreams such as GNOME. My goal here is not to open up a blame game of who did what and when (I will leave that to the commentators ;-) ), but what disappointed me most about the whole situation was that from my personal perspective it seemed that some influential members of the GNOME project were treating Canonical’s contributions more critically and suspiciously than others.

Now I haver never subscribed to conspiracy theories, and I don’t believe that there was a shadowy GNOME Illuminati that was meeting together in a hollowed out volcano to plan how to keep Canonical and their contributions out of GNOME, but I was surprised and disappointed at the attitude that came out of parts of the GNOME project to us, when we were ultimately delivering GNOME to millions of users as well as writing new code that could enhance GNOME. It just seemed incredibly entitled.

The shadowy GNOME Illuminati

There were three things that really blew my mind about all of this:

  1. From my experience of working on volunteer Open Source projects, new volunteers and their code contributions are tremendously valuable. As an example, if someone comes to my current project (Ubuntu Accomplishments) and is willing to propose new, disruptive ideas, and willing to contribute chunks of code, I will treat those people with open arms. Being challenged is a good thing: it keeps us fresh, and a challenging, innovative idea followed up with running code is awesome. Now, of course, this is not to say that writing code automatically gets the contribution into the core project, but I would treat the entire social engagement with someone offering such a gift with positive open discussion to see how we could find a great solution that makes everyone happy. This seems an area where things could be improved with GNOME.
  2. If I was also running a project that was understaffed and struggling to define its direction (which I would argue was the case with GNOME at the time) I would treat such new contributions as wonderful ways of solving problems and building a new direction for the project, particularly if our major distributor was going to be delivering that technology anyway. Code is the currency of Open Source, and rejecting chunks of this currency because they don’t fit an as-yet incomplete jigsaw puzzle of a vision just doesn’t make sense.
  3. Without sounding egotistical from the perspective of an Ubuntu guy, I would argue that the vast majority of GNOME consumers were getting GNOME in Ubuntu. Of course, there was and continues to be the wonderful work going into Debian, Fedora, OpenSuSE and others, but it seemed that Ubuntu was the most commonly-used GNOME distribution (I suspect it still is). Again, I saw this as a partnership but from my perspective it seemed like parts of the GNOME project saw Ubuntu as fundamentally subservient to GNOME; as if we had an obligation to deliver whatever the GNOME project saw fit, irrespective of our own ideas and feedback from our users. In my position as an Ubuntu guy, I have always tried to treat our upstreams with maximum respect as they are a big part of who we are; Ubuntu is nothing without awesome apps, and a wonderful integrated experience. I guess I just expected a more positive and collaborative experience with GNOME than I experienced…the kind of collaborative experience that I had known and loved in the earlier days of GNOME.

Of course, it takes two to tango and we at Canonical could have no doubt done better to improve our relationship with GNOME, but I remember back then feeling like no matter what we tried to do, we came up against resistance from the GNOME project, and this was de-motivating and no-doubt added stress to our relationship.

GNOME 3

To shift gears a little, one of the points in Benjamin’s post was that GNOME 3 is a Red Hat project. To me this is a bit of a double-edged sword.

On one hand, the crux of his point is entirely valid: most people contributing to GNOME seem to be a clique of Red Hat folks. What concerns me a little are the concerns in parts of the community that Red Hat is “running the show” and that much of the decision-making has been private to Red Hat staff.

Here’s the thing: I don’t doubt that this is probably happening, but this is not necessarily a bad thing. These concerns again highlight what I think continues to be an unrealistic expectation in parts of the GNOME project with those who are willing to invest in the platform (in this case, Red Hat). If Red Hat have decided to invest in a team of developers to work on and bring value to GNOME, building Free Software that can be shared with everyone, these contributions should be received with open arms. Leadership is leadership, irrespective of the employer.

Of course, there needs to be a culture of openness and transparency, and I suspect a certain amount of internal water-cooler chat is happening in Red Hat, but you will find that with any commercial team that is actively engaged in a Free Software project; we just need to always try to keep things as open as possible. GNOME is definitely going to need to ensure that the openness and values of open collaboration are not compromised, and an open and frank discussion with the Red Hat team about resolving these concerns is no doubt the best step forward.

Pictured: a proven conflict resolution technique.

I personally think it is wonderful that Red Hat are investing so much in GNOME and they have arguably led in much of the direction and leadership in delivering GNOME Shell and the various other parts of the platform. What seems ironic to me is that the same criticisms that were thrown at Canonical with Unity (as a perceived competitor to GNOME Shell, which it was never intended to be) are now being leveled at GNOME Shell (“you don’t care about our needs”, “you are pushing your own agenda” etc).

Maybe a solution to this problem is to be open and frank about the relationship with Red Hat. As an example, we always try to be open about our relationship between Ubuntu and Canonical; there is no doubt that Canonical drives a lot of the development and innovation in Ubuntu, although this leadership and innovation is firmly rooted in expectations around openness and collaboration. We don’t try to hide the influence Canonical has on Ubuntu, and I wonder whether the wider GNOME community feels comfortable in accepting the influence Red Hat has on the project. This is always a delicate balance.

I would agree with Benjamin that GNOME is essentially a Red Hat project these days, but as I say this is double-edged: the wonderful benefits of the investment from Red Hat will be tinged with the challenges of how vendor-neutral the project wants to remain.

The Future

So what is the future of GNOME and how can these problems be solved? Can they even be solved in the first place?

I think so.

I love GNOME as a project, and I love the folks involved in it. While we don’t always agree, the core ethos and goal of GNOME is admirable: to bring an awesome Free Software desktop to everyone. While I personally prefer Unity as a shell, I think the work that has gone into GNOME Shell has been a wonderful rebirth of the motivation and focus of GNOME. The architects of this vision should be credited in getting GNOME out of the slump I mentioned earlier that seemed to stem from 2005. Of course, I will always be disappointed that GNOME seemed quite so resistant to much of the contributions we wished to make, and I think we could have helped to have moved things along a little faster, but I am delighted that GNOME 3 has got to the point it has got to.

As I mentioned earlier, my feedback here really has nothing to do with the design and technical direction of GNOME, and others can provide more insightful commentary than me. I do though think this people-problem issue of GNOME being a rather difficult project to work and interface with at times is a problem that has not yet been confronted and resolved. While this problem continues to exist, I worry that it will eat away at GNOME more and more.

GNOME is blessed with some wonderful leaders, and I hope that the content in this post can act as some food for thought: I am not expecting everyone to agree with me, but if this opens up a discussion about these topics I will be happy.

What is not a solution is for us to give up on GNOME. I know some folks are moving on from the project and moving onto other things, and we have more competition than ever for desktops, but I still see GNOME as an important foundational component of the Free Software and Open Source desktop today.

Now, I am sure this blog entry is going to result in some folks screaming from the rafters that I am misrepresenting GNOME and it is all Canonical’s fault, and you are entitled to your view. Traditionally I have not wanted to raise these concerns publicly as I didn’t want to cause any further harm in the relationship between Ubuntu and GNOME, but Benjamin’s blog post seemed to offer a good opportunity to throw out some feedback that might be helpful in constructing a solution.

While I don’t have much time to contribute to GNOME formally these days, I am more than happy to talk more, provide any further feedback, and help where else I can. I would love to see the GNOME project that we know and love be back in a healthier state. Thanks for reading.

Read more
jono

Those lovely people at ZDNet have let me write a guest post about community, and I have contributed an article called Failure as a springboard to success.

The article talks about how if we embrace our failures in our communities, it can help us become better community members, and provides a model for doing so. This is particularly important for leaders. In a nutshell (from the article):

Failure should [also] be embraced in your communities. We admire leaders who are humble, honest and frank, and we grumble about leaders who are defensive and abrasive. Be the former, and your community will love you for it.

If you are involved in a community, I recommend you give it a read. :-)

Read more