I'm writing a CSS book

JavaScript archives Compatibility Thidrekssaga QuirksBlog Donations CSS book Politics Mobile About COH

contact

Twelve steps for saving webOS

I’ve been thinking a lot about the future of webOS, and have decided it does have one, maybe even a glorious one, provided the new owner or licensee reaches out to web developers, as Palm should have done back in 2009.

So here are twelve steps the new owner should take in order to get webOS to thrive.

Background

webOS is a high-end operating system, which means it must compete with iOS and Android. Thus it needs a well-filled app catalogue, but that is a problem right now: webOS is drawing relatively few developers.

Still, although the app situation is bleak, it’s not beyond recovery. After I switched to mobile two years ago I closely followed what web developers were saying about the various platforms, and I was consistently surprised at how much developer mindshare webOS was able to retain despite not having any market share whatsoever.

Sure, in the mind of web developers iOS comes first, and Android second. Surprisingly often, however, webOS comes third, even before Windows Phone. The reason is simple: webOS is web-based, something that none of the others are. Want to create a native app? Write some HTML, CSS, and JavaScript, and you’re there. Serious coolness factor.

This latent interest in webOS has never received the slightest support from either Palm or HP. When HP took over Palm I wrote a post discussing this odd state of affairs, and now that we’re fifteen months further we can conclude that HP didn’t do much.

The fundamental reason was that HP did not understand the mobile world. One member of the Palm team told me HP marketing people were mainly interested in putting webOS on printers (why the effing eff would you want that?!?), and that in the ex-Palm offices the expression “facepalm” had given way to “faceHP.”

Oh sure, some sponsored speakers were sent to conferences and a JavaScript framework was released, but the Palm developer relations management team did not succeed in entering the inner circle of web dev speakers. Part of the reason was HP’s idiotic sponsorship requirements (must have speaker slot, must have this, must have that), and more in general an insufficient conformity to the customs and habits of the web development world.

Besides, all their efforts were US-based. Europe, where interest in webOS is high, too, was a distinct afterthought. The fates of Motorola and of Palm itself show that the days of US-centric mobile strategies are over. The rest of the world matters more.

The twelve steps

So whoever buys or licenses webOS should do the following:

1) Reach out to web developers. Not mobile developers — they have enough platforms to worry about already. Not mobile web developers — they will be interested, but also have lots of other platforms to keep track of.

Instead, the proper target of a webOS developer marketing campaign should be the common, average desktop web developer who’s heard a lot about mobile in the past year but hasn’t committed him- or herself yet.

Desktop web developers have most of the required technical knowledge, are as yet unaligned in the mobile platform war, will certainly be interested in what webOS has to offer, and are still at liberty to make a choice. If they choose webOS ...

2) Realise that you need web developers far far more than they need you. Without web developers your platform will falter. Without your platform web developers will use another platform and prosper.

Everybody wants web technologies, nobody wants web developers. You must want web developers enough to be willing to approach them on their own terms.

Web developers built their ecosystem by the sweat of their brows back in the days nobody was interested in web stuff yet. Thus they acquired a rugged independence and react very badly to marketing nonsense. They are willing to listen to companies that have something interesting to offer, but object to being talked down to or just hearing marketing fluff.

Humility and openness are the key concepts here.

3) Give your devrels a free hand. For the love of God don’t try to manage them centrally or give them idiotic requirements. Marketing people should not have any power over developer relations. It just doesn’t work.

Hire devrels who are already in the right circles, let them pick the right conferences, back them up with sponsor money and devices, and allow them to talk openly and fairly about webOS’s shortcomings.

Trust me on this: admitting you made mistakes works better than highlighting the platform’s best features. Web developers are at their most receptive if you want to start a conversation about how to improve your platform. They’ll remember that, while some marketing fluff about features is forgotten almost immediately.

Read Chris Heilmann’s Developer Evangelist Handbook. It’s all in there.

4) Make a worldwide effort. No more US-only stuff. The US is too small a base to create a truly global mobile platform. Appoint devrels on all continents and back them up.

5) Add jQuery out-of-the-box. Ditch Enyo. No more messing around with your own frameworks and stuff. Writing them is fun, but web developers don’t want to learn yet another framework. The framework wars are over, and jQuery is the winner. So include it on all webOS devices and make sure web developers can access it from their apps. Also make sure it can be updated over-the-air, independently of the OS as a whole. Web developers want the latest versions.

Also, try to hire a few key jQuery developers, especially those already working on the mobile version. This grants you access to the inner circle of web development.

Finally, contribute back to jQuery. It’s a very important step, since it shows you aspire to be an upstanding member of the web development community.

6) Implement device APIs according to the standard. I admit I don’t like the style of the standard, but it’s what we have, and what we should use. Besides, careful conformance to W3C standards is very important in the eyes of web developers.

Device APIs are a powerful way of differentiating yourself, since the other platforms are a bit slow on the uptake. You can steal a march on your competitors here. And web developers love having access to exciting phone functionalities.

And hey, if you want to add a nice jQuery layer on top to make the syntax more palatable, be my guest. This is exactly the sort of initiative web developers love. Make sure to contribute the layer back to the jQuery community, and help them make it work on other platforms.

In fact, such a layer will be helpful in abstracting away changes in the standard. DAP isn’t stable yet, and I don’t doubt some modifications will occur. Be prepared.

7) Upgrade the browser — fast. One of my most curious findings is that the default browser of the single web-based mobile platform in the world is not very good. It’s not very bad, either, but the current Palm WebKit is a boring middle-of-the-road browser that can’t handle many exciting features. Add touch events. Add visual viewport size. Make sure animations are transformations can compete with the iPhone. (If you ask nicely I’ll provide you with a fuller list.)

Oh, and follow W3C specifications whenever they are available. Standards compliance is very important to web developers.

8) Don’t force bloody SDKs on developers. Really! This is not Java programmers we’re talking about, but web developers. Besides, creating a good SDK takes lots of time and money, and you don’t have the time.

Web developers hate being forced to use a piece of bloatware that doesn’t do what they want, has odd quirks, and takes bloody ages to start up. They use a text editor, a graphics program, and documentation and examples that you must provide. Don’t force them to develop in alien, buggy environments. They’ll just ignore you.

9) Allow web apps to be sent and received via Bluetooth. Forget the app store as a closed distribution channel. You can’t out-Apple Apple.

Having an app store is fine, but it should just serve as the main entrance to webOS-app-land. It should not be the only entrance.

Instead, make sure that enthusiastic users can spread your apps by themselves — directly from phone to phone without any centralised system. Besides being an interesting feature in its own right, it serves to emphasise that webOS is an open system. And openness counts in the eyes of web developers.

Of course this is tricky, because iOS and Android don’t support Bluetooth to a meaningful degree, and even if they did they wouldn’t know what to do with the received app. But having this feature available can’t hurt.

And it may be that you don’t need Bluetooth but, for instance, NFC. Whatever works for peer-to-peer sharing.

Incidentally, this will change the way people make money with apps. They don’t charge for the app any more, but for the data: articles, features, levels, whatever. But this change is going to come anyway, so you’d better embrace it.

10) Make sure that webOS apps can also run on other platforms. That’s in the browsers of that platform, of course. User has nice webOS app and shows it to a friend who uses Android. User sends app via Bluetooth, friend can open and use it straight away in the Android browser. That is the true strength of the web platform; a strength you should capitalise on.

In practice this means that you should forego weird dialects and make sure that everything works as it would in the major mobile browsers. (Remember: you’re a minor browser. If you do things differently, nobody will care and they’ll forget about webOS. You are the supplicant here.)

Especially make sure there’s interoperability with Opera’s widget system. Opera makes a likely ally: they, too, want to have interoperability.

11) Hand out devices. Lots of them. Some web developers will like webOS, but hesitate to commit to it because they cannot afford the hardware. Help them out.

If a webOS devrel visits a conference (even if he does not speak there) he should have a big bag of devices to give away. Not two or three, but dozens. Google did this with the Nexus, and it helped them gain developer traction.

12) Accept the fact that all this will cost lots of money. Gearing up a new mobile platform to compete with iOS is very expensive. Be prepared to spend millions and millions on devrel affairs only. If you want to do it on the cheap you’ll fail.