How We Got Here: Part II of a Design History of GNOME 3 the Shell
Daf Harries continues his interview with Jon McCann and Jakub Steiner. Should we be treating code and design contributions the same, or differently? What pitfalls from GNOME 2 were designers trying to avoid? How do we deal with community indecisiveness?
(continued from Part I)
DH: What are some of the pitfalls you think GNOME 2 ran into? What are some of the things we did well?
JM: I think the people involved in the early days of GNOME 2 were very successful at instilling a design culture into the project. Nicely complemented by a strong get-things-done ethic. Many of us were attracted to GNOME because we identified with it, we demanded better, and we wanted to demonstrate that we could be better.
One of the problems in GNOME 2 was figuring out how to make decisions. The technology world’s magnetic poles starting changing on us, and the initial 2002 compass wasn’t helping us steer after a while. This led to lots of disagreement and ultimately to a kind of fatigue. We started making design decisions through a module acceptance process that rarely had anything to do with project vision or design. It was seen as fairness but unfortunately that isn’t the same as greatness. We became a little too milquetoast, tolerant, and accommodating. People started to realize that this mediocrity wasn’t what any of us really wanted, and started agitating for a shake up. Which eventually led to GNOME 3.
JS: I saw even GNOME hackers using add-on tools to help them do the basic tasks GNOME was supposed to do. To me, projects like gnome-do or docky did a far better job at launching and switching between apps and documents.
And to me, the upstream visuals weren’t convincing enough for distributions to build on top of it with their branding, rather that creating their own thing completely. GNOME 2 got really fragmented. There was no unified feel to it. GNOME was always a very striving community, but I don’t think people felt like it was a product.
DH: Do you think we’ve gotten past that indecisiveness? How did we get better? There was some skepticism in the community when the GNOME 3 process began, but we managed to build consensus that it was a good way forward.
JM: I think time will tell. I expect there will always be indecision, debate, and discussion. There is an element of human nature there. However, I think it is important for us to at least agree on some basic things. Without that, rifts form and can destroy a community. You really need to agree on your brand. That is: a) who you are; b) what you are doing; c) why it matters. I think once you reach a rough consensus on that, the rest flows. We’re clearly still working on it.
DH: Clearly there won’t be a GNOME 4 in the near future, but what are the things you would do differently in future projects?
JM: I think that once GNOME 3 is out the door we’ll have a chance to look back and second guess the process we used to get there, but for now I feel great about what we’ve managed to accomplish. We’re doing something that nearly everyone said we couldn’t do. Creating innovative, elegant, and coherent design in the open. Creating an operating system that we can be proud of. Creating a platform for participation in the future that we can share with anyone (not just the technical elite). I feel really good about that.
JS: Right now I’m just looking forward to tie up the loose ends and get GNOME 3 out the door. We have received some positive feedback so far but it will be interesting to see what the rest of the world has to say.
DH: There is a lot of experience in the free software community in organizing decision making and contributions around code, but we’re relatively inexperienced when it comes to design. Do you think code and design contributions can work in the same way, or do they need to be treated differently?
JM: A little of both, actually. I think there is something really amazing about the way a good open source project is maintained. A good maintainer, like any good leader, is responsible for making final decisions, accountable for those decisions and the decisions made by others in the project, consults with people in the project and people in the field, and keeps everyone informed of the project’s progress. This model has proven very successful with code. I think it applies equally well to design.
In GNOME Shell, for example, Owen is the maintainer and a very good one. He has delegated some of his duties in matters of design to me. I in turn delegate as much of that as I can 🙂 Owen reserves the right to make executive decisions but only exercises it in rare occasions in order to maintain a healthy mutual trust relationship.
Where things differ quite a bit between code and design maintenance is in how contributions are handled. Code contributions usually take the form of problem reports (bugs) and/or suggested code changes (patches). These are usually pretty easy for the project developers to evaluate, based on the known sensibilities and tastes of the code maintainer. There is usually some value of correctness involved that is rather apparent and involve small deltas to the current project baseline. This is less the case with design contributions. For sure, there are simple design bugs and even sometimes patches, but just as likely, if not more likely, are contributions of an entirely different vision. That would be equivalent to sending a code patch that refactored and replaced the entire project. That isn’t something that a maintainer can really do much with and so it turns out to be not that valuable.
Another difference, which has been covered elsewhere in great detail, is the effect known as bikeshedding, where the more superficial the issue, the more fierce the discussion. This seems to occur less frequently in code contributions. But it does occur. Tabs versus spaces anyone?
JS: For graphic design it is absolutely a case of everyone feeling competent to add to a discussion, even if the first thing they do is mention “Well I have the graphic skills of a 4 year old, but…”.
DH: Does that mean you do think there needs to be a different approach for graphics contributions?
JS: Probably not, it’s just that the ratio of useful feedback to noise is probably even lower than in technical discussions. People who actually do contribute artwork are usually willing to iterate and investigate a different path.
DH: Do you think that good design stems from a clarity and unity of vision? If so, how can we reconcile this with wanting to keep our projects non-hierarchical and open to contributions?
JS: The project lacking a vision is clearly not getting us anywhere. You don’t want to get people involved with the preemptive promise of including the design of a particular bit. The primary focus needs to be a good product rather than growing a fellowship. Sure it is necessary to investigate many options, but it’s just as necessary to kill off most of them. That process becomes close to impossible without a vision.
JM: As I mentioned earlier, I don’t think the clarity and detail of vision is always that important. You can be too certain of things and get trapped. You need to have room to wiggle, to play, to dance and be creative. But you need a structure and a direction too or else you’re just careering.
Being open to contributions is not opposed in any way to having good leadership and being able to make difficult decisions. You need both. You can’t evaluate contributions without the ability to decide. You won’t invite contributions if you show an inability to choose among them. You need to be able to communicate to the world: “Here’s where we want to go. Won’t you meet us there?” If you can do that effectively you’ll have the right kind of contributions and be even more open and transparent than before – with less discord and more harmony. And that’s the type of world we want to help create.
Daf Harries is a GNOME developer.