On GNOME and its Foundation: an interview with Luis Villa

Luis Villa: I've been involved with GNOME since I was Ximian's QA guy for the Evolution 1.0 release, which was 2001 but now feels like a million years ago. I was first elected to the board in 2003, and have served several terms since then. I took off a couple terms because of law school, but I was re-elected in early 2008 with a promise to focus specifically on legal issues. Since then I've also played grumpy old man from time to time, since I'm the only current board member who was actively involved in the 2.0 release.

We're the face and leadership of the GNOME Foundation, the organization which backs the GNOME community. The board's primarily roles mirror the roles of the Foundation - support and stewardship.

On the support side, we take a look at what our community and corporate partners are working on, and try to match people, projects, and resources. The biggest part of that, historically, has been getting everyone together at GUADEC. In the past few years we've been trying to expand that - we've done more events and hackfests; we've helped out with marketing; we've started giving grants for certain kinds of hacking (primarily a11y [accessibility]); and we've tried to make resources available to spur work on GNOME Mobile and other subprojects.

On the stewardship side, the Foundation owns the GNOME trademark, controls GNOME funds, and generally manages other resources (technically we own several servers, for example, though in practice they all live in other people's colos.) And technically most GNOME teams (like the release team) report to the board, though in practice we have a very, very light hand on the tiller.

One thing we don't do, very explicitly, is technical leadership. That comes from the community.

With all this under the Foundation's purview, the board ends up making a number of small decisions that matter to GNOME, and in practice, we do a lot of the work of the Foundation as well.

I think 'dire' is a stretch, because so far our fundraising base hasn't declined, it just hasn't increased as much as we expected. So we can get back to our previous stable state fairly quickly if we have to by cutting only 'new' expenses. That said, we like those new expenses - we think they make GNOME stronger. So we'd like to keep them if at all possible.

How it came to be is fairly straightforward. After we cut our last director's salary from the budget, we ran a large surplus for several years. It was hard for us as an essentially all-volunteer organization to actually spend this money - organizing events and doing coordination is really time-consuming, and frankly isn't something that we (as hackers) are terribly great at even if it were our full-time job. At the same time, we felt there was a need there for more events, resources, etc., and there seemed to be a willingness on the part of our corporate partners to invest even more if we could give them a way to do it.

So last year the board felt that it was time to expand. We grew our investments in things like hackfests. We also decided to hire a new ED who could help us do more for our developer community and for our users, and help us grow financially. We knew that this extra salary and extra spending would put us in the red for a few years. But we thought that this was a classic 'spend money to make money' situation- we thought the investment in events and in Stormy would allow us to reach more sponsors and would bring more value to our existing sponsors.

Our timing, obviously, couldn't have been worse - we hired Stormy in July, just as the recession began to break. So the investment hasn't paid off like we thought it would. We have increased the number of sponsors we've got, and many of our existing sponsors have increased their level of investment, so it hasn't been all bad, but definitely not enough. And obviously under the economic circumstances it isn't going to get any easier. Hence the message to our membership you referred to.

As I suggested in the last question, we need an ED because we think we can do more for the community than just host a handful of servers and run GUADEC. A good ED can do things themselves that help us grow; a great ED can be the organizer who motivates and organizes a lot of other people to get involved and help out.

We're seeing lots of the former and some of the latter already with Stormy, and I fully expect to see more of it. I won't bore your readers with the full list, but among other things she's helped us expand our fundraising, helped organize events (inc. GUADEC and hackfests), improved communications with our advisory board, helped restart our marketing group, dealt with some legal questions, helped broker a deal to upgrade our bugzilla, and worked on a plan to hire a sysadmin. So I think our initial decision to make this investment and take the risk was the right one. Of course, whether it makes sense long-term is still an open question - we will have to balance our budget eventually.

First? Right now, unfortunately yes. Only? Absolutely not. Obviously a large part of her job is, and always has been, fundraising. Her priorities and bonus structure have reflected that from day one, and under the circumstances we've obviously urged her to focus even more on it. But if all Stormy does is fundraise, unless she is *spectacularly* successful, she'll still be a net drag on our resources and we won't be getting anything else out of her time and abilities. In other words, we'd be happy to go from our previous surplus to break even (so that financially, Stormy is a net 'negative' for the budget) if it means we get to benefit from Stormy's efforts in other areas.

I think both GNOME 3 and KDE 4 are showing a fair amount of promise these days. For either desktop to actually make an impact on the broader world, we have to be able to give a compelling answer to the user question of 'why should I use this?' 'New' and 'shiny' aren't good answers for that anymore. And it can't be a scattering of little tweaks to the old model. That was all Vista had, so it sank. KDE 4.0, frankly, did not have a good answer to that question - there was a lot there for developers, and a scattering of new things for users, but there was no single, compelling story for users. Every single version of OSX, in contrast, has had at least one and often three big, compelling new 'why should I use this?' features as well as all the little polish.

I think GNOME 3 ran the same risk as KDE 4 when we were focusing on gtk 3 as the driver behind GNOME 3. But we're focusing now on what users are going to see - on the new Shell, and on Zeitgeist. I don't think either of those are perfect, by any stretch, but I think they have at least the potential to offer a really compelling answer to the question of 'why should I use this?' The KDE team, by the way, is moving in that direction as well - I think their social desktop work, for example, has the potential to offer a very compelling story for users. If I were them, once that is mature and well-integrated I'd go ahead and call that KDE 5. Whether GNOME or KDE, that kind of user-focused, problem-solving feature is way more important than what version of the toolkit you build on.

As you can imagine, having been deeply involved since the first time this came up (around GNOME 1.9x), I'm pretty sick of this question. ;) The short answer is that, since we are Free Software, all of our users have access to the ultimate configuration tool - GCC. :) And we've made it easier to maintain those kinds of 'options' since we've switched to git.

The long, and more serious answer is, well, long. There are a couple aspects of our philosophy that cause this problem:

(1) One aspect of our philosophy is that we always prefer to fix underlying problems instead of papering them over in the UI. As someone put it c. 2001, 'many options in a lot of our tools are really a switch that means 'work around this bug.'' Our philosophy is that you should fix the bug instead of adding the option. As a result, some of our software, particularly when it is very new, can be a real pain if it turns out you were relying on those bugs or on workarounds for those bugs.

Network Manager was like that for a long time - it worked on the majority of hardware and use cases, but certainly not all of it, so people kept screaming for new options. But the developers stuck with it, introducing new features only when they were sure they could do it as automagically as possible, and fixing bugs at lower levels instead of hacking around them at the UI level. And the entire Linux platform - for GNOME users and for non-GNOME users - is better now because we've forced wireless drivers to fix their bugs instead of providing workarounds in the UI. As a result, we've now got a tool that is reliable for virtually everyone and simple to use. Still not perfect, but I think comparable in ease-of-use and power with anything on any OS. I think the volume control will eventually be the same way, though admittedly it seems rough enough that I'm not sure I would have shipped it quite yet if it were my call.

(2) Another aspect of our philosophy is that options have a cost. For developers, they have a cost in QA; they have a cost in debugging; they have a cost in maintenance. Everyone who has done QA in free software has piles of stories about the horrors of debugging something because all the options weren't set just right. So we think that overall we make more software, and better software, by focusing in this way. More importantly, for users, options have a cognitive cost. It takes time and mental effort to figure these things out; time and effort that could be better spent doing the things you use a computer for - working on projects; talking with your friends; or whatever. You or I, who are experts and have used Linux as part of our day job every day for over a decade now, don't notice this cost. But for people who view Linux as a means to an end - getting their other work done - these costs are present every time they try to mess with the system. Again, why does my girlfriend want to see 8 volume switches when she goes to play her music? She just wants one, just like she just wanted her networking to work - and now it does.

(3) Finally, we believe that you can't make software that pleases everyone. You can make software that pleases experts, but most of the time non-experts hate that software. (Office, for example, was like this for a long time.) We're unabashedly trying to make software that works well for average users and not experts. We hope, obviously, that experts will use it, like it, and help us make it even better. (For example, you could help us work on a better plugin infrastructure so that we could move more options into plugins, like Firefox does ;) But if you like spending hours tweaking things so that you feel like you have more 'control', then yeah - it might be better for everyone if we just agree to disagree.

Obviously, I think these are all reasonable and important parts of our software philosophy; I think it means we make better software. If everyone understood them, we would still have some disagreements, but the disagreements would be made on more substantive grounds, with better understanding of the tradeoffs involved. We'd really want to see people criticize us on solid grounds - like, did we switch to the new volume control too early? how can we enable experts in ways that don't have big costs? - rather than on what we think of as fairly unreasonable grounds like 'I want my switches back.' For those who do want to understand this philosophy better, I'd recommend reading chapter five of the 37 Signals book 'Getting Real' - I don't agree with all of it, but that's the best reference I can think of for how we feel about features.

Support LWN, because it rocks - it does the most substantive reporting on Linux that there is.

Past that... I'm sure I'll think of something about an hour after the article goes up ;)