I have been thinking a lot recently about the flow of ideas in and around Open Source projects. A few days ago [I asked for feedback](https://archivedblog.jonobacon.com/?p=1424) about how we can better structure interaction ideas. The blog entry gathered some great feedback: thanks to everyone who contributed. With this work I am keen to understand the bottleneck between a well researched, well specified and documented interaction concept and its ultimate implementation. It is this contention between walled designers and walled developers that causes so many great ideas to be lost, never seeing the light of day.

Understanding and resolving this contention is important for GNOME. If we compare and contrast the KDE and GNOME approach to revitalised desktop interactions (read: KDE 4 and GNOME 3), we see two very different approaches. The KDE team discussed, designed and documented a *big picture approach*. They mapped out a design of what they wanted to see and then encouraged the community to implement said vision. And you know what, they did a damn good job. Although still a touch rough around the edges, KDE 4 is a huge achievement of defined direction and coordinated implementation.

But that approach is not the GNOME approach. GNOME is a playground for experimentation and ideas. We need to stop trying to take the KDE approach of mapping the big picture and rallying the troops to implement it. It just isnt going to work that way: we have tried to do this for the last three GUADECs and have produced relatively little.

But look at what innovation we *have* produced. Tomboy. GNOME Do. Beagle. Empathy. Abiword. The Slab. The new FUSE applet. Deskbar. Gimmie. Dashboard. F-Spot. Banshee. The list is endless. The GNOME community has a history and culture of experimenting with ideas and approaches. Some of them sink, some of them swim, but there are two important attributes in each of these ideas – they are *small, self contained units* and *code is available*. Just look at [Owen’s recent post](https://blog.fishsoup.net/2008/11/22/gnome-shell-status/) as an example. We had all read [Vincent’s post](https://www.vuntz.net/journal/2008/10/22/494-desktop-shell-from-the-user-experience-hackfest-general-overview) with interest, but when Owen showed us some code that we could check out and play with, the idea really started to develop legs. Another example is [GNOME Do](https://do.davebsd.com/). I think most of us were a bit sceptical of the idea of GNOME Do at first, but the subsequent implementation and positive reported workflow experiences has made people sit up and not only take notice of GNOME Do, but its primary interaction characteristics.

So, it is clear that the GNOME community is an incubator for lots of small experiments and ideas, some of which work well and some of which don’t. Our challenge is in how we continue to encourage the flow of ideas and how we merge the flow of successful ideas into the central body of what we call GNOME

If we decide this is the right approach, we need to not only foster an open environment that encourages experimentation, but we also need to foster an environment that encourages *useful experimentation*. We want to ensure that successful experiments can be merged easily and quickly at a technical level. One potential approach to this is to encourage uses of popular and agreed infrastructure. We have this to a degree in the project already (languages, toolkits, source control systems etc), but I suspect this will shake out naturally and we will continue to see dominant technologies such as Python, Mono and C being used, and increasingly new technologies such as Clutter and Telepathy.

For this approach to succeed we need to think carefully about the workflow of an idea moving from the functional experimentation phase to the merged phase – the technical implementation and maintenance, the politics we want to avoid, the decision making process of how we evaluate ideas etc. This is where I feel we should be focusing our debating glands. Lets flesh out these processes and encourage this environment of experimentation and exploration, Just imagine what we could achieve if we could figure out effective methods for communicating interacting concepts effectively to developers, developers hacking on small implementations of those ideas and the those ideas garnering popularity and being merged into the desktop. In many ways this is a very Free Software approach – scratch an itch, refine it with collaborative development and then merge. If we can figure out these questions together, our new GNOME could actually happen.