In this opinion piece, Seth Nickell discusses the culture surrounding GNOME, where the culture has been, where it is now, and where he thinks it should be heading towards.
”[KDE is developed in] a big room somewhere in Europe with lots of chrome and glass and a great big whiteboard in the front with lots of tiny, neat writing on it. There are about 50 desks, each with headphones and pristine workstations, also with a lot of chrome and glass. The faint sound of classical music permeates the room, accompanying the clicky-click of 50 programmers typing or quietly talking in one of the appropriately assigned meeting areas.”
”[GNOME] Development strategies are generally determined by whatever light show happens to be going on at the moment, when one of the developers will leap up and scream *‘I WANT IT TO LOOK JUST LIKE THAT’* and then straight-arm his laptop against the wall in an hallucinogenic frenzy before vomiting copiously, passing out and falling face-down in the middle of the dance floor. There’s no whiteboard, so developers diagram things out in the puddles of spilt beer, urine and vomit on the floor.”
I would argue it was already an in accurate caricature when it was written, but was spot on only a year or two before. When I first read that page, on balance, I thought it made it sound better to be a GNOME developer than a KDE developer. At least GNOME developers sounded creative and lively.
Today, I would argue that the caricatures are almost reversed. GNOME is a paragon of usable, restrained, unimaginative, corporate development. KDE is lively, nimble, cluttered, and a little crazy. What happened? How can we get the good aspects of “old GNOME” back without returning to diagramming in puddles of spilt beer, urine and vomit?
It was not so terribly long ago that GNOME was a bastion of unfettered development. We focused on possibility rather than our (at the time quite serious) inadequacies. And it was good for the project: GNOME was an enthused development community. Features were slammed out by the likes of The Dark Prince, seething pits of free software development, hyperactive Mexicans, and cowboys. Even her royal majesty the Queen of England got into the game by maintaining a module or two. Sure, Enlightenment came onto you like a drunken whore, her makeup blotchy and fluorescent, but man was it cool.
New applications were added by the crate load. Maintainers took almost any UI change, as long as it came with a patch and added a neat feature. Libraries were under constant churn as fresh widgets, features and utility functions were crammed into gnome-libs. Occasionally the features were completely broken, sometimes the new APIs were confusing or incomplete, and usually they had a host of egregious usability problems.
The result? GNOME was a great experience for developers and, at best, a chaotic experience for any hapless user who cared about getting something done. Having a motivated developer community is very important, particularly to a free software project. But if that community is not producing relevant, user-focused software its nothing more than a fun party, and we were falling short on this point.
A New Approach
In recognition of this problem we steered a new cultural course for GNOME. Restraint, thoughtfulness and usability were defining characteristics of this new culture. These are very important qualities for targeting desktop end users. Most of us didn’t (at least, I didn’t) think of it as building a new culture at this point, but simply as a new set of practices. But new practices tend to foster supporting changes in their host culture. I think there can be little doubt in hindsight that GNOME underwent a major cultural change.
We accomplished a major cultural shift in record time partly by open hostility toward the “old ways”. This wasn’t a planned thing just a natural reaction to getting past ingrained ways of thinking. Projects (and to a lesser extent, people) who didn’t get on board with the new agenda or represented the old ways of thinking were mocked. This is actually pretty typical of major cultural changes: “culture wars”. The only surprising aspect of our cultural revolution was that a great percentage of the old crew stayed with us – typically a major cultural shift represents a change in people.
Inconveniently, prior to the cultural revolution, we had picked up a following of users who themselves appreciated the fruits of the old ways: churn and toys to fiddle with. We learned to avoid the natural tendency to develop for these users by marginalizing them; ironically the users who were most enthusiastic and present on mailing lists, irc, etc. Its easier to avoid developing for somebody when you can call them a “crack smoker”. It protects you from the reality that you have dismissed the core interests of a person or group of people. Dismissing these “crack smoking” users hastened the transition, made it easier, and that’s a probably a good thing. The bad thing is that we perpetuate these irrational emotional responses, but more on that later.
On a more positive note, the new course wasn’t just a blood bath. In conjunction with these attempts to reject the old we were experimenting with new social infrastructure (e.g. the release team), equipping ourselves with new techniques (e.g. targeting classes of users and evaluating our software relative to them), and building tools to support our new methodologies (e.g. the HIG).
The results were good. Very good. Applications behaviors grew more predictable as they were standardised. Clutter and excess were trimmed down, making features available to a wider body of people. Releases came out with the regularity that can only result from a high-fibre diet. Development was user focused.
Somewhere along the line our process, usability and thoughtfulness constricted us such that we forgot how to appreciate new ideas. With it went a lot of our enthusiasm. When people come into a mailing list or IRC channel with a quick implementation of an off-beat idea, droves of righteous knights rise up to slash them down and set fire to their bodies. Their steaming corpses serve as a warning to others. Our knee-jerk reactions to protect ourselves from crazy features and unfocused development served a purpose in the glorious revolution. Their time is over, the revolution is over, we need to learn how to move on.
The original problem wasn’t the freedom to experiment. The problem was shipping all the experiments. How do we encourage wild ideas and interesting features without producing an incoherent overall product? Right now the badge of social approval in GNOME is “ships as part of the release”. We can, and should, value trying things out. They might work, they might need refinement, more often than not they won’t work at all all. So what? If you don’t do things wrong you’ll never do anything new. GNOME hackers seem to have developed a hesitance toward writing code they aren’t sure will pan out. We have this perfectionist streak that results in stagnance. Further, we as a community have become quick to discourage ideas or development that are slightly off. That means good things are often killed in infancy, rather than aiding in taking something that’s slightly off and making it work.
Its as if we fear cranky features appearing in our releases. No doubt, it is easier to kill an idea by being vocally and strongly against it. But perhaps we can we find a way to send this message instead: _“That is a really cool idea. Its definitely experimental, and I suspect it won’t make it into a release in that form, maybe not in any form, but its great you’re working on it and I’d love to help out.”_
This is not without precedent: most large companies do a lot of “research” (or more applicably, product prototyping). They don’t productize most of the designs coming out of research groups, but they encourage them, and ideally latch on to the viable ideas and push them into products. There’s nothing wrong with thinking something is an interesting idea, but still a stretch. Its not just encouraging other people (though that is important too). We, as a community, need to be more willing to prototype interesting concepts without an expectation or need for them to show up in a release.
This is not to say that we need to respect and treasure every idea that gets bubbled to the surface. Most ideas proposed by random people on mailing lists are still as questionable as they always were. We still need to keep the signal to noise ratio high. That means we still need social means to filter out the droves of unwashed who appear naked at our door with naught but a mad idea clutched in their fists. We would be swamped if we didn’t. Research doesn’t mean “anything goes”. It doesn’t mean you can’t separate crap from ideas that are based on good insights. It means you look for an interesting core in a troubled prototype. It means you dive ahead with something when not all the details are clear.
Its not like we aren’t doing some of this already. There are a number of interesting projects going on right now with various degrees of experimentation (beagle, luminosity, tomboy, gDesklets, etc, etc). Some of the related/peripheral communities in GNOME are already much better at this, notably the pygtk and gtk# communities. On the one hand, its easier to prototype software in python and C#. But another effect might be that by and large people writing in these areas aren’t thinking about “how do I get this in GNOME”, if only because of the still extant natural resistance to non-C applications in core GNOME. It leaves people more free to experiment. That in turn promotes a culture in these communities that is open and encouraging of experimentation.
We need to get back some of that old-school madhouse charm, not only for our own interest and sanity, but also for the good of the product. We need both offbeat experimentation and stodgy conservatism in order to improve. Right now we’ve got stodgy conservatism down pat, lets branch out and figure out how to appreciate both. Hug an inventor near you, especially if its yourself.