The book was edited by Lydia Pintscher and includes essays from 42 authors, many of whom you'll recognize if you tend to go to FOSS conferences. The LWN book review concludes:

Open Advice is a book that will be helpful to those who are new to FOSS, but, because of the individual voices, styles, and tones, it doesn't read like a "how to". It could even be recommended to those who aren't necessarily interested in contributing, but are curious about what this "free software thing" is all about. It is, in short, a great book for a variety of audiences and the (mostly) two or three page essays make it easy to read, while the anecdotes and recollections personalize it. The authors, editor, and everyone else who helped should be very pleased with the result. Readers will be too.

I probably shouldn't give the ending away, but my essay on cross-project collaboration, a subject I've also blogged about, ends with:

Good luck with breaking down the project boundaries! In most cases it works if your ideas are good and presented with an open mind. But even if you do not find a common ground, as long as your implementation solves the use case for you it has not been in vain. After all, delivering software, and delivering great user experience is what counts.

The book is licensed under CC-BY-SA, and is available as free download in ePub, mobi and PDF formats, and as paperback from Lulu. The book sources are available on GitHub, patches welcome!

As my office is where my laptop is, none of this work is particularly tied to a physical location. And as much of the work is communicating, I end up spending quite a lot of time traveling between meetings and conferences.

For this my previous home town of Helsinki, Finland wasn't quite ideal. From an European perspective, Finland is an island. And so I've accumulated airmiles instead of being able to travel more comfortably (and productively) on the European railway network.

I've previously dabbled with living in other locations like Istanbul and Saint Petersburg, but this time I hope the move will be more permanent: in the beginning of this month we packed our stuff, got rid of the Helsinki flat and hopped on a plane to Berlin.

The modern world makes this easy: my whole library fits on a Kindle and music collection on Spotify, version control and testing happens in the cloud, and banking and invoices are on the web. And thanks to EU there is minimal red tape in setting yourself up anywhere in Europe.

My current setup is such: I'm traveling with about two weeks' worth of clothes, my trusty work laptop, and tablet with an amazing 18 hour battery life. Accommodation happens in furnished, short-term rental apartments, and Internet comes from an old N900 serving as a WiFi access point via prepaid 3G.

While Berlin has excellent co-working spaces, I'm currently sharing office with Content Control, the local Midgard shop. Though at the time of writing my office is temporarily relocated to the nearby Hasenheide park where there is a nice sunny spring day.

I'm still planning on popping into Helsinki every now and then. With Air Berlin, the travel cost and distance is almost the same as if I lived in the Finnish city of Tampere (yeah, VR is expensive). Once the snows there melt, I'll also ride my motorcycle over.

If things work out, I may be eventually able to say: ich bin ein Berliner. This city is quite amazing - the amount of cultural activities and hacker meetups probably beats any other place in Europe right now. If you're around, ping me!

And if Berlin doesn't work, then there are lots of other interesting places for a working nomad...

Our primary goal is to facilitate meetups, collaboration and awareness between different projects and communities within Open Mobile Linux and provide a place to present directions, ideas and your projects themselves.

By Open Mobile Linux we mean any open source projects revolving around typical non-desktop/server Linux, such as handsets, tablets, netbooks or other creative uses. Examples of such projects could be Qt5, Mer, MeeGo, Android, webOS, Plasma Active, Tizen, Boot to Gecko, SHR and other related efforts.

There are several exciting things happening in this space, including the recently announced Spark tablet, open sourcing of webOS's Enyo framework and continuing interest in the Maemo platform. Saturday's program includes:

• Mer ... and what you can do with it (David Greaves, 11:30-12:00)
• Openmoko Freerunner - Present and Future (Niels Heyvaert, 12:00-12:30)
• Towards Accelerated UI's on Mobile Linux With Power of Qt5 (Saija Eteläniemi, 12:30-13:00)
• Intro to Tizen and the Future of the Community (Dawn Foster, 13:00-13:30)
• buildroot: flexible building of a custom embedded system (Arnout Vandecappelle, 13:30-14:00)
• Deep Dive into KDE Mobile development on N9/N950 (Laszlo Papp, 14:00-14:30)
• Community Qt apps repository - way forward (Jukka Eklund, 14:30-15:00)
• Maliit - the open mobile text input project (Jon Nordby, 15:00-15:30)
• Nemo Mobile - How to contribute to the project (Marko Saukko, 15:30-16:00)
• Introduction to the QtOnPi project (Rajiv Ranganath, 16:00-16:30)
• An update on PIM storage and sync: SyncEvolution (Patrick Ohly, 16:30-17:00)
• OS in the Mobile App Stores (Thomas Bonte, 17:00-17:30)
• Rygel: Free and Open Mobile DLNA (Jens Georg, 17:30-18:00)

If there are any last-minute announcements or happenings that people want to discuss, we may be a ble to squeeze in a talk or two. Contact Carsten about this.

Also, if you want to chat other things (like PHPCR or CreateJS), I'll be around the whole weekend including the beer event. Drop me an SMS.

Looking forward to seeing as many of you there as possible!

# GObject Introspection APIs are available from imports.gi.Modulename
Gtk = imports.gi.Gtk

# For GNOME 3.2+ this should be Gtk.init null, 0
Gtk.init 0, null

win = new Gtk.Window
    type: Gtk.WindowType.TOPLEVEL
win.set_border_width 10
win.connect "destroy", (widget) ->
    Gtk.main_quit()

button = new Gtk.Button
    label: "Hello, world"
button.connect "clicked", ->
    button.set_label "Bar"
win.add button

button.show()
win.show()

Gtk.main()

Gjs doesn't run CoffeeScript directly, so you need to convert this before running:

$ coffee -c window.coffee 
$ gjs window.js

You should see something similar to:

Please send a short biography and an abstract for your talk to carsten.munk@gmail.com by Dec 31st 2011, and we'll get back to you at latest January 7th.

We're also grateful for volunteers helping to run the devroom. Contact Carsten if you're interested.

One option is to follow the lead of the big companies, hoping that Tizen works, or that Google again sees the benefit of working with others in the open.

The other is to take the matters in our own hands. There is precedent for this. Much of early Linux activity came from the efforts of the community, not on the initiative of corporate interests. And there have been OpenMoko and Mer, the latter an attempt to make a fully open version of Nokia's Maemo environment, suspended when MeeGo promised to bring the same benefits.

Well, now Mer is back.

The goals for Mer align pretty well with what the community would need:

• To be openly developed and openly governed as a meritocracy
• That primary customers of the platform are device vendors - not end-users.
• To provide a device manufacturer oriented structure, processes and tools: make life easy for them
• To have a device oriented architecture
• To be inclusive of technologies (such as MeeGo/Tizen/Qt/EFL/HTML5)
• To innovate in the mobile OS space

There have also been some other invitations to new potential homes for the community, ranging from openSUSE to Debian.

It will be interesting to see how this works out. But whatever we as a community do, we should ensure we look at more than just licensing.

node-gir has been written by Tim Caswell, with help from Sebastian Wick and Piotr Pokora.

I've been following the progress for a while, and today, during a flight from Helsinki to Salzburg, I was finally able to open a Midgard repository connection with it. The API still is a bit weird, and lacks support for the asynchronous nature of Node, but those will hopefully change soon. Quick example:

var Midgard, gir, config, mgd;
gir = require("../gir");
gir.init();
Midgard = gir.load("Midgard");
Midgard.init();

// Use a local SQLite database file
config = new Midgard.Config();
config.__set_property__("dbdir", __dirname);
config.__set_property__("dbtype", "SQLite");
config.__set_property__("database", "midgard");

// Open connection to the database
mgd = new Midgard.Connection();
if (!mgd.__call__("open_config", config)) {
    console.error("Failed to open connection");
    process.exit();
}

node-gir is being developed on GitHub if you want to lend a hand or try it out. To build it, run npm install and you should be able to run the code examples.

Having GIR support for Node would make it a full-fledged GNOME environment, and mean that there would be proper GObject Introspection in all three major JavaScript runtimes - SpiderMonkey, JavaScriptCore and V8. And this way GNOME JavaScript developers could also utilize the wealth of existing Node.js modules.

Many of their plans to make web competitive against native development environments are good, there is indeed much to improve in the stack. But what I'm uneasy with is the unilateral way they go about it, preferring "big reveals" and post-facto standardization instead of the open conversation that built most of the Internet we have today. This is not the way to collaborate.

Consider some of their recent efforts:

• SPDY, a protocol to replace HTTP which Web is built on. Currently only supported by Chrome, which uses it to talk to several Google services
• Dart, their JavaScript-killer which recently surfaced through a leaked email
• Microdata and Schema.org that seek to replace last ten years of semantic web development with a spec cooked up by couple of big vendors in secret

These - together with WebSQL, NaCl, WebM and WebP - mean that Google has active efforts to replace practically every layer of the web (except HTML itself) with something of their own design.

The way all of these were introduced bears strong reminders of how Microsoft tried to embrace, extend, and extinguish the web in late 90s. That period brought horrors like ActiveX and the awful, unkillable IE6. Though, for the sake of fairness, it also brought us XmlHttpRequest which was the enabler of the AJAX revolution.

Google's new technologies may end up being beneficial for web developers, but they also threaten to fragment the platform. After all, as the competition in the "post-PC" space heats up, the competitors are unlikely to embrace Google's extensions of the web stack. That would be a loss to all.

Brendan Eich, the original author of JavaScript comments on Hacker News:

So "Works best in Chrome" and even "Works only in Chrome" are new norms promulgated intentionally by Google. We see more of this fragmentation every day. As a user of Chrome and Firefox (and Safari), I find it painful to experience, never mind the political bad taste.

Ok, counter-arguments. What's wrong with playing hardball to advance the web, you say? As my blog tries to explain, the standards process requires good social relations and philosophical balance among the participating competitors.

Google's approach with Dart is thus pretty much all wrong and doomed to leave Dart in excellent yet non-standardized and non-interoperable implementation status. Dart is GBScript to NaCl/Pepper's ActiveG.

Disclaimer: I've been a long-time fan of many of Google's services, and have visited some of their offices a few times. I like the company. Which is exactly why I'm so concerned about this unilateral approach at standards. I am also involved in some standards processes through the IKS Project.

MG Siegler from TechCrunch has a great post on the subject:

...I’ve been trained over time to think that the traditional PC is the way to do these things whether it’s for work or play. That’s simply not true. The tablet form factor is so. much. better. when you don’t have to do an excessive amount of typing. And during downtime, when I use a computer like a more regular human being, I’ve found that’s often...

Computing is changing. That’s just about the most obvious statement ever. We’ve been seeing this for years with the rise of the smartphones. But traditional computing is changing as well. As in, people are abandoning PCs for these newer devices. And this will keep happening.

My experience conforms with this. I rarely use my laptop outside of the work context of writing code, instead preferring to use the tablet with its great ergonomics, portability and long battery life. On some of my previous trips I noticed that already more than half of people sitting in airport lounges use a tablet instead of a laptop. Not bad for a product category that has existed in a mainstream manner for less than two years. Nokia's internet tablets blazed the trail years earlier, but were never marketed outside the geekdom.

Now, much of the attention in the tablet world has been focused on the couple of platforms that are winning in popularity, and therefore have most of the apps. But regardless of how well Apple and Google play their cards, the post-PC world will be a multiplatform one.

About a week after I got my webOS-powered TouchPad, HP went and killed the product. Yet this hasn't made the device useless. As Paul Rouget recently found out, as long as you have a good browser, your device will be relevant.

Some people can't or don't want to use Native Apps. Because their phones don't have Apps, or because there is just no good Apps for what they want to do, or because, well, because they don't need to...

While in the Western world we were looking at Apple bringing pretty Apps in an expensive device, in the Eastern world, Opera was bringing a working web browser to all the existing devices.

This is the big opportunity for free software to remain relevant in an environment of highly-locked devices. Much of the web already runs on free components, and by using the web as a universal runtime we can bypass almost any platform restrictions. As Paul Graham wrote back in 2001, no one can break web applications without breaking browsing.

The world of publishing is starting to understand this. Their revenue models can't take the heavy control that vendors like Apple imposes, and so Amazon's Kindle is a web app, and so is Financial Times. That "Next year HTML5 will replace native apps" is the new "Next year will be the year of Linux on the desktop" is already a Twitter joke, but there is certainly some movement in this direction. And interestingly, the Linux desktop is actually becoming more web-savvy and touch-friendly.

There are clearly sweet spots for something to be a web app, or for it to be a native application. Similarly, there are different situations where tablets will be the appropriate tool, and where PCs are. The tablet context will be more like this:

Than this:

The heavy lifting is a better fit for a system designed for that. As Steve Jobs said, the PC will be the truck.

Even in the ten years of history of our company this is quite a significant move - it allows us to combine Nemein's traditional expertise on content management with Infigo's mobile offerings. As smartphones and tablets are becoming popular, more and more services we build will have a mobile element, which is now easier with lots of in-house expertise.

This also means more focus on the interplay between the Midgard content repository, NoFlo workflows, Node.js and Symfony web services, and mobile applications built in Qt.

Petri Rajahalme (with me in the photo) will be the CEO of the merged company, and I will focus on leading the R&D efforts.

While much of the corporate involvement around the desktops has evaporated through some recent events, this seems to have given the developers lots more creative freedom. I've seen many very promising concepts from both communities.

Here are some things that happened during the week:

• The roadmap for Midgard to become closer to the JCR specification solidified, including a reasonably good plan on backwards compatibility
• We published the first version of GICR, generic Content Repository interfaces for GObject. Midgard will probably be the first project to implement them, but we hope others will follow. It'd be a great fit for GNOME Documents, among other things
• The project to replace our own PHP frameworks with Symfony2 continued by implementing the MidCOM compatibility layer that will allow Midgard1 web applications to be run in the new environment
• My work on the NoFlo flow-based programming tool got some positive attention and interest. Still lot of stuff to do
• We at Nemein co-sponsored the GObject Introspection hackfest. GIR is important for bringing GNOME libraries to new environments like scripting languages and the web
• Lots of ice cream got eaten. I think it will be fair if I stay out of next year's deathmatch and focus on coaching ;-)

Tomorrow back to Helsinki for a week, then onwards to FrOSCon and Salzburg...

Now, one of the things I've talked about with people is NoFlo, my new tool that brings Flow-Based Programming to Node.js. What is that? Wikipedia explains:

Flow-based programming (FBP) is a programming paradigm that defines applications as networks of "black box" processes, which exchange data across predefined connections by message passing, where the connections are specified externally to the processes. These black box processes can be reconnected endlessly to form different applications without having to be changed internally. FBP is thus naturally component-oriented.

Basically the idea here is to simplify managing the control flow of software: what data goes where, what happens then, etc. with the goal of making software more understandable. With NoFlo you can go and peek under the hood of a running piece of software, see where data is going to, and even rewire some connections if you want to.

The project is still in reasonably early stages, but it is already used in at least one real-life deployment. Here are some sneak peeks:

:

If you're interested, follow the progress on my GitHub repo, or subscribe to the Flow-Based Programming mailing list.

In the spirit of Desktop Summit, it would be interesting to talk how these workflows would fit into the concept of a free software desktop.

Now I would like to bring GObject Introspection to PHP. Why?

For many years we in the Midgard community have been using GNOME infrastructure on the web server side, by building our persistence layer on top of GObjects, and providing D-Bus notifications when content changes. So far this has been done with our own custom PHP extension.

I believe a common PHP extension providing GObject Introspection support would make more sense, as it wouldn't just benefit our own community, but also support efforts like php-gtk.

Alexey Zakhlestin already started a project for this a while back, but unfortunately has been unable to finish it. Because of this, we would be willing to sponsor anybody interested in making the gobject-for-php extension work.

Benefits for the GNOME community:

• New supported development language and a large community of potential contributors
• The possibility of making the GNOME stack relevant in web space. Just think of Telepathy or GStreamer in a web app

Benefits for the PHP community:

• Access to the rich collection of GNOME libraries, many which may be useful when building web applications
• Being able to use your PHP skills to build GNOME applications and bring them to interesting environments like Ubuntu and Cordia

Benefits for the Midgard community:

• No need to maintain our own custom PHP extension
• A more generic GObject Introspection extension has better chances of being included into Linux distributions and being available on hosting providers

Let me know if you are interested. We're coming to the Desktop Summit with Piotras, so for example that is a great opportunity to talk more about this.

After the recent San Francisco MeeGo Conference there has been surprisingly much negative reporting about MeeGo, mostly centered at Nokia's MeeGo story. While Nokia's strategy changes are unfortunate, much of the reporting around it appears to come from misunderstanding what MeeGo is about.

Many see MeeGo just as Android without Java, but it is much more, as I'll explain here.

Industrial Linux

MeeGo is much more than just handsets or tablets. It is an attempt at creating a standardized industrial Linux distribution that can be used anywhere from in-vehicle infotainment devices to TVs to, indeed, handsets.

It is a true open and collaborative environment, managed by Linux Foundation. The governance model is there to ensure that MeeGo stays a vendor-neutral platform that anybody can build their products on top.

Many device segments have very long development, and especially usage times. For this MeeGo has a predictable release schedule of a major release every six months, and a roadmap kept by the Technical Steering Group.

If MeeGo succeeds in this, you will be using it in your TV, in your car stereo, and at the back of an airline seat. But in most of these situations you won't be able to know that it is MeeGo. It is simply there to make building products faster and cheaper for the manufacturer.

Openness

As I argued in my earlier piece Open Source? Free Software? What we need is Open Projects, being an open platform is much more than just the licensing terms of the code. There needs to be transparency into the development process, a clear procedure on how to participate and much more. And of course licensing has to be such that the participants can actually use the results in whatever they're doing.

For this, most of MeeGo is licensed under permissive terms, like the GNU LGPL and BSD-style licenses.

But indeed, the other aspects of openness are more important. With MeeGo you can see every commit happening on Gitorious, and you can see the bugs and features being worked out in a public Bugzilla.

MeeGo as a project is still quite young, and many participants are still learning how to work in the open. This has lead to some issues in project transparency. But hopefully those are now getting resolved.

User Experience

MeeGo allows anyone to build their own user experience on top of the platform. Actually, this is expected of any serious manufacturer. Sure, there are some reference UXs available, including Tablet, Handset and Netbook, but none of these are quite product-ready, and are not necessarily even intended to be.

Because of this it is quite funny to see reviews of the reference UXs. They're not the ones most devices will run, though obviously some manufacturers or community members are going to use them anyway. A full MeeGo product will look and feel like something completely different.

This is not like Android manufacturers adding their own skins. With MeeGo anybody has the full freedom to build a complete user experience that suits their device, branding and other goals. The whole platform has been built to allow this sort of differentiation, without a risk of fragmenting the ecosystem. I'll explain the fragmentation question soon.

Actually, the freedom of defining your own user interface is big enough that both Android and WebOS could theoretically be rebased on top of MeeGo to be just different MeeGo UXs. Obviously they would need to allow running MeeGo-compliant Qt applications in addition to ones written for them directly, but that is minor detail. WebOS already ships Qt, so it isn't even that far from this. Similarly, KDE or GNOME could run as MeeGo UXs.

Compliance

At the core of MeeGo there is a set of compliance rules. Being Open Source, anybody can take MeeGo, modify it, and run it on their devices. But only if their implementation passes MeeGo compliance it can be called MeeGo.

Device Compliance is a set of rules that ensures any MeeGo-compliant software can run on a particular device. Application Compliance similarly ensures an app can be installed and run on any MeeGo-compliant device.

Both of these sets of compliance rules have automated tests that anybody can run. So, between non-compliant MeeGo-related software there may be fragmentation, but anything branded MeeGo (and therefore compliant) must be fully compatible.

App Stores and business models

MeeGo is an open source project, not a company. This means it comes without strings attached, compliance rules aside. There are no limitations on the business model of a MeeGo device manufacturer, no mandatory online services or app stores to enable, and no royalty payments.

With this, each vendor can decide what they want to enable their users to do with the device. An embedded device might have no concept of installable applications, a tablet might come with the vendor's own app store.

For those who do not want to go through trouble of building their own developer ecosystems and app stores, there are some generic solutions available in the MeeGo sphere:

Intel's AppUp is a "white label" app store. This means that a device manufacturer, or even retailer or operator can get an instance of AppUp with their own branding and a revenue sharing deal with Intel. Developers submit software only once and it will be available on all the different branded AppUps.

On the more open side, there is also the upcoming MeeGo Community Apps, a fully community driven "store" of free software written for MeeGo. It comes with its own, OCS-compatible client application, a web frontend, and clear set of crowdsourced app quality assurance processes. The similarly handled Maemo Downloads has served over 80 million downloads for the Nokia N900, so the user and developer interest is clearly there.

The future of MeeGo

At this early stage of the project it is hard to make predictions, but there are many things MeeGo gets right. I think it has a bright future ahead of it, especially in more specialized devices. There the shared infrastructure and clear development schedule give manufacturers substantial advantages in both development time and cost.

Product development times in the embedded sector are quite long, and it may well take years before we'll see MeeGo in a airline multimedia system. But if the project shows the necessary durability and longevity, this will eventually happen. Now many of those systems run on customized Linux distributions that their manufacturers have to spend quite a bit of money to maintain. MeeGo removes that problem, and allows easier collaboration through the compliance rules.

As for consumer devices like tablets and handsets, that area mostly requires there to be a vendor that wants to properly differentiate itself from the grey masses of the Android ecosystem. MeeGo provides all the necessary tools on both systems side and user interface development to make that happen.

Currently there are many different ideas floating around on how to build user experiences on connected devices. There is the "wall of apps" approach of iPhone, there are the fully cloud-connected WebOS and Android approaches, and now Microsoft is also starting to enter the game with their own ideas.

I don't think the "post-PC" world is yet complete. What MeeGo gives is a fast way to build products differentiating from that crowd. It just needs companies who are willing to go for it.

The next couple of years will be quite interesting.

• MeeGo Conference, May 23-25
• Aloha Editor dev con, June 6-8

The old "open vs. proprietary" debate is over and open won. As IT infrastructure moves to the cloud, openness is not just a priority for source code but for standards and APIs as well. Almost every vendor in the IT market now wants to position its products as "open." Vendors that don't have an open source product instead emphasize having a product that uses "open standards" or has an "open API."

"Openwashing" is a term derived from "greenwashing" to refer to dubious vendor claims about openness. Openwashing brings the old "open vs. proprietary" debate back into play - not as "which one is better" but as "which one is which?"

Especially Google seems to be doing this quite a bit. If you want to be open, work in the open. This is the only way to ensure acceptance and sustainability for your code.

Simply put, the 11" MacBook Air is the best computer I've ever had. I've always appreciated small and light laptops as I travel quite a bit, but this one takes portability to a completely new level. The laptop weights only a kilogram, and is small enough to fit pretty much any bag. And it is pretty:

Funnily enough, it has a slower processor than my previous work laptop (1.4 GHz vs. 1.6 GHz), but the fast SSD makes a huge difference. Pretty much anything I do on the device feels faster. It appears Brooks Review agrees:

...my MacBook Air is the best Mac I have ever owned — hands down — no contest. I have had everything from the fabled 12″ Powerbook G4 to a pimped out Mac Pro — the MacBook Air takes the cake here. It is incredibly fast for 95% of everything that I do and the screen resolution is amazing give the small footprint of the machine. The size and weight of the machine still amazes me every time I touch it.

Battery life is also quite good, with Linux giving me about 3-4 hours per charge. This could obviously be better, and I dream of the 10+ hours an Arm processor would give.

Why Linux?

Why do I run Linux on the system? First of all, I appreciate the software freedom. I also love the predictable release cycles that Ubuntu and GNOME give me: every six months there is a new release with a set of features announced early on. And since we deploy our software on Ubuntu, my own development environment has automatically the same set of packages and versions available. Midgard, Node.js, etc. are all available from the repositories.

I also like GNOME's focus on simplicity. Unlike OS X, the user interface has very few unnecessary elements, and the desktop itself has been designed to let me focus on the task at hand, minimizing distractions.

Installing Ubuntu on the system is not exactly trivial, but after a bit of setup everything works as it should: suspending, wireless, webcam, everything. And boot times are also pleasantly fast. Compared to previous Ubuntu versions, network acquisition after resume is also very fast, comparable to OS X.

Gripes

As said, battery life could be better. Ten hours would give me trouble-free working environment when traveling, as now I often have to prioritize when to use the computer and for what in fear that no power outlet is available.

I also hate the display adapters Apple forces us to buy and carry around. I give a lot of presentations, and this is another piece of equipment to accidentally leave home. Why not just go VGA or HDMI?

In both of these aspects the similarly compact Nokia Booklet would've been better. Unfortunately it has been a while since that "business netbook" was released and there has been no word of newer versions.

Another gripe is related to the stability of the GNOME3 PPA release for Natty. There are some regressions compared to stock Ubuntu. I hope that will be eventually fixed now that Natty is officially out. Shame that Canonical wanted to do their own thing instead of going with GNOME.

As Ars Technica says, GNOME3 feels very solid for a first release. Some first impressions:

• Window management by dragging them to the edges is very handy
• Notifications allow me to focus on the things I'm doing at the moment, but still allow for easy conversations when I want them
• Finding, launching and managing applications is easy. Apple key -> type some characters -> enter starts an application
• Wake-up from suspend and acquiring wireless are very snappy, though I guess this is mostly thanks to Natty and not the desktop
• The monochrome top bar is beautiful and has the necessary functionalities. I don't really miss the panel applets
• In general the desktop stays out of the way and lets me focus on what I'm working on

• The window decorations are humongous, especially as they have very little use in the window management paradigm. This really hurts the usable vertical space
• I really miss the global menus from Unity. Though with modern applications I might be even happier with no menus at all
• The system font looks a bit squished, but I guess that is because of my X settings
• I haven't figured out how to remove the unnecessary accessibility menu from the top bar

Anyway, great work from the team! I hope the annoyances can be fixed in due course, and I'm looking very much forward to hacking with Midgard and the JavaScript-based desktop.

But there is one weakness in the JS ecosystem: as things are just now picking up, the amount of information on especially making larger applications is quite sparse. To help solving this issue, I decided to start a new blog dedicated to what I learn in that space.

Like my earlier piece on the importance of the language, the blog is called The Universal Runtime.

If you run into interesting tutorials on JavaScript, or are doing something cool in the space, let me know!

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.