There is currently quite stern discussion going on between GNOME, Canonical and KDE about collaboration on the free desktop. Angry words have been written, and I believe much of the tension arises from the situation with MeeGo. Suddenly many developers and projects feel much more marginalized than what the future looked like, pre-112. Hopefully cooler heads will prevail before the Desktop Summit, and we can again have beers and discuss things together.

Cross-project collaboration is hard. I know. For many years I've been pushing for location-awareness across desktops, for using shared content repositories instead of application-specific file formats or databases, and most recently for having a common client-side data representation and manipulation layer on content management systems. Some of these ideas have moved forward. Some others, less so.

What is important to remember is that each project has their own use cases, user experience goals and set of selected technologies to build on. If a collaborative approach you propose doesn't fit those, it is highly unlikely that the project will adopt it. And there is nothing wrong with that.

Instead of looking at the failures, we should think of the ways cross-desktop collaboration has moved forward. Here are some examples:

• D-Bus is pretty much everywhere now. A common way to handle signalling and API calls between processes is a big step
• Telepathy provides a great real-time communications system on all desktops
• All projects seem a lot more UX-focused nowadays. Great examples are window management in GNOME Shell, web integration in KDE, and better handling of quitting applications and scrolling in them in Unity. These ideas are easy to transfer between projects
• There is work ongoing on unifying application installers between distributions. Open Collaboration Services is also useful here
• Wayland shows great promise for simplifying the graphics layer on Linux desktops

So, if you want to get a specification accepted between projects, how to go about it?

First of all, you should communicate early and clearly the use cases your specification aims for. And then there should be a reference implementation available, not only as a library, but also as something already integrated in your UX.

If you want projects to actually use your reference implementation instead of building their own, then it is important to remove as many obstacles from adopting it as possible:

• Use permissive licensing and try to avoid copyright assignments or other requirements potential users would find onerous
• Host the project on neutral ground. For web projects, Apache is quite a good home. For desktop projects, Freedesktop is probably the best option
• Use technologies that don't impose too many constraints. Libraries should be quite low-level, or provide D-Bus APIs that can be used with any system
• Avoid technology-specific dependencies. For example, KDE has found GeoClue hard to adopt because it uses GNOME-specific settings interfaces
• Talk with the other guys. If you're from the GNOME project, go to aKademy and give a talk, and if you're a KDE developer, go and talk in GUADEC. IRC isn't bad here either
• Finally, accept that not everybody will use your implementation. But if they at least implement the same ideas, then collaboration is still possible.

And even if your ideas haven't been adopted by other projects, as long as your implementation solves the use case for you it hasn't been in vain. After all, delivering software, and delivering great user experience is what counts.