Ok, that’s the part I don’t quite understand. I understand that OAuth support is a major advantage in protecting users from rogue applications. More importantly, as a practical matter it allows users to more seamlessly change their Gmail passwords, something we should all do more regularly. But this all does come at some expense to app developers; just look at how many Twitter apps still don’t support OAuth.

But Gizmodo and others seems to be implying that OAuth will enable application capabilities that are not possible today. Can anyone think of any examples of this?

Or are people just thinking that better security will lead to more people adopting more third party apps? I don’t know about that, since most users still don’t know or care about OAuth, and the OAuth experience for native mobile apps still leaves much to be desired.

So what am I missing?

This blog post which is making rounds on Twitter tonight highlights a problem with FourSquare, which sounds pretty scary. But if that’s scary, you should see many of the other APIs that mobile apps use — including many apps you probably use every day. This problem is a lot more common than people may realize.

In fact, it affects most Twitter apps that we use on our phones. Twitter realizes this, and has tried to phase out the use of Basic Authentication in their API. At one point they even announced an end to Basic Auth for all new apps, but had to reverse that decision because of developer resistance. Their official policy now is they really want this to go away some day:

“OAuth is the Twitter preferred method of authentication moving forward. While we have no plans in the near term to require OAuth, new applications should consider it best practice to develop for OAuth.  We eventually would like to suspend Basic Auth support. However we realize that Basic Auth has been a large part of the API’s success, and that the barrier to entry if OAuth is the only solution is substantially higher.”

OAuth is, of course, the right answer to this issue. But it can be tricky to implement (for developers) in native apps. And, perhaps more significantly, it can be a little confusing (arguably even a little disconcerting) for users as they get kicked out to the Twitter site to “approve” access for this new application they just downloaded. If you understand OAuth, it’s easy to see this is more secure than giving some app your Twitter password, but explaining that to a user and having them go through the process is often difficult.

So, yes, FourSquare and Twitter and everyone else should implement and require OAuth (and deprecate HTTP Basic), but it’s not their fault that this is not really feasible yet. One thing that I think would really help is OS level support, especially in the user experience for OAuth. I would envision something similar  to how Apple implemented seamless login to restricted WiFi hotspots. If OAuth can be seamlessly weaved into the OS like that (with direct API support), then I’m sure most mobile developers and web services would leverage that quickly. Nobody likes Basic Authentication, but right now it’s just the easiest way to do things.

But when you look at the Android ads and billboards and particularly the Verizon Droid ads, is it any wonder more young men buy them? Who else would be attracted to a phone that is used by robots?

and one that can apparently punch a hole in your wall if you should need that:

Of course, for all that great engineering, things haven’t quite gone according to plan for our friends at PALM. Lots of people have piled on in the past couple of days, some looking at where Palm goes from here, some looking at how they got to this point (for example, did Palm get here because they don’t have Steve Jobs?).

Well, as much of a fan of Apple (and Jobs) as I am, I’m not sure I subscribe to the idea that a mobile electronics company simply cannot succeed without Steve Jobs at the helm. For me, I keep coming back to two big mistakes that helped to throttle what should have been the best competitor Apple has:

1. The launch date

Palm launched the Pre in Sprint stores on June 6, 2009 (a day that will go down in infamy?). This was on a Saturday, two days before the keynote at WWDC, where Apple introduced the third generation iPhone. Two days. Zero business days. So on Monday the news was all about Apple’s impending announcement, the keynote, and then reaction to the keynote, then reactions to the reactions, and so on. The entire news cycle that you would expect if you’ve ever heard of Apple. Or if you, for example, had worked there.

So, of course, the innovative and very interesting new Palm Pre wasn’t even the first headline in mobile phones, let alone gadgets, for the whole week. And Palm got not nearly the coverage they would have had two weeks later after everyone had come to terms with the fact that the iPhone 3GS didn’t cure cancer. So why release a phone two days before the hottest company in your segment? I presume it was a statement that this phone was so great that it could actually drive the 3GS off the front page. If that’s so, someone should have run that thought by someone outside of Palm. The reality is the public release ended up being entirely forgettable (and forgotten).

(Actually, there is a 1b here, which is Palm’s obsession with Apple. That’s understandable given the history of the people working there. But still probably not smart, given that even as WebOS is arguably better than iPhone OS, it totally blows away other mobile OSes. Perhaps their energy would have been better directed at those other competitors.)

2. The development environment

This is where I think Palm had a great idea that was probably better on paper than in practice. The idea was that if the development environment was Javascript and CSS, then there would be millions of potential WebOS developers, immediately leapfrogging the small number of experienced Objective C developers. In theory, that makes sense. In practice, though, I think what people realized is that most CSS and Javascript work in the world is simple little tricks in webpages. A lot of that work is copy/pasted and evolved from scripts and stylesheets borrowed from around the web. And, so, as a result most web developers have never done anything as complicated as building a full app and don’t even know Javascript to that kind of depth that you need to work with something like Mojo.

So what happened in practice is that Mojo development actually ended up being more daunting for web developers (the target market) than Android development, for example, is to Java developers (their target market). Or that Cocoa development is to someone who knows C. And that’s hard to overcome when you’re competing with the AppStore gold rush. I wonder how this story would have played out if Palm had offered a native kit from the beginning that allowed the easy port of some popular OpenGL games. Or a new framework that looked and felt a lot like Flash, with the target being Flash developers rather than general web developers.

Again, the good news is that the Palm team built a very nice OS, at least from the user’s perspective. And the UI is so much better than the iPhone knockoffs. Licensing WebOS to other handset manufacturers may be a challenge against the essentially cheaper than free Android. But becoming part of Nokia could really save Palm (and probably Nokia as well in the smartphone market).

What do you think? What’s your theory on how such a great smartphone sold so poorly when everyone is talking about and buying smartphones?