One of the most interesting aspects of Mono development from my perspective has been something Erik Dasque and I discussed last week. Namely, the charge that Mono’s put into a lot of the Linux desktop folks, resulting in a surge of nice little desktop related applications like Dashboard, F-Spot, iFolder, Muine, and Tomboy. To be sure, each new language/platform/environment that comes along is bound to enjoy a honeymoon where it’s the bleeding edge and everyone wants to have the latest cool hack.
Mono’s clearly setting the pace in the desktop space, however. I suspect it’s benefitting (relative to some prior platforms) from several tangential factors such as the more mature Linux desktop options and the transparency that blogs provide (some of its highest profile developers are solid bloggers), and the productivity of the environment doesn’t really hurt either. But at the end of the day, Mono’s providing me with the coolest kit mostly because I have it. Now.
As for Java, there are some great applications coming. But for the most part, developers and end users have to wait for it. The exception here is Looking Glass – the coolest UI I’ve seen by a large margin – although thus far I’ve had no success getting this one to build for Gentoo. The other really intriguing desktop projects like Karelia’s Watson or its Collaboration and Communication Project, however, are being developed behind closed doors. Why is that? As I mentioned here when comparing the beta experiences of OneNote and Tomboy, breaking down the boundaries between developer and users has immense benefits to both parties.
Extrapolating from all of this, here are the some of the keys as I see them to mobilizing developers and user in the desktop space:
1. Pick simple application types that are useful, but not overdone. Email clients and music jukeboxes, for example, have to be really exceptional to attract attention. Note-taking applications don’t, simply b/c they’re less common. And it’s a task that most people can relate to.
2. Open development as early as possible. See the OneNote/Tomboy post linked to above for more details, but even if you’re not going to open the source make the application available for download early and often, and expose the developers to real time feedback. Nothing gets a tester involved like getting feedback from the actual person working on the code.
3. Don’t lock in data. Udell talks about that here, but the point is that it’s difficult to test pre-production applications with data if you’ll have trouble getting it out. Tomboy, for example, stores notes as human readable XML, so that if worst comes to worst I don’t lose my notes if I ditch the application.
4. Tap into the “network motivation”. Whether it’s blogs, social bookmarking, or tagged photos, a lot of today’s hottest application categories exploit the “network motivation”, or the desire to realize the innate benefits of shared content. People who blog and get a response from others tend to blog more. Ditto for photos.
5. Keep it simple. An oldie, but a goodie. Part of the charm of some of the applications I’m using – like F-Spot – is that they are not trying to set the world on fire. The goals are modest, but the delivery is there. Too often desktop folks focus on getting every little widget in there, rather than how it functions. If the application fits a need and works, people will use it. You can always stuff the widgets in later.
Build it and they will come is always a problematic mantra, but for platform folks that’s pretty much the reality. The key, however, is knowing what to build and how to build it.
