Cost/Benefits of open sourcing for Symbian

Over at The Mobile Lantern, Fabrizio Errante raises the idea of open sourcing Symbian OS. This has been raised before, so I thought it worth addressing.

Many people seem to forget that open sourcing has costs as well as benefits. The question for any particular product/project is, do the costs of open sourcing outweigh the benefits, or vice versa?

Let's do a quick overview for Symbian:

Benefits

• Access to a bigger pool of developers to work on the codebase
• Access to niche-specialist developers
• Codebase becomes free (benefit to the customer)
• Buzz

Costs

• Codebase becomes free (cost to the provider, who can no longer make money from licensing)
• Loss of control of codebase
• Loss of control of developer quality (to be honest, much OSS is of very dubious quality, leading me to believe that either the developers don't have the time/energy to put in quality work, or there are few quality developers working on OSS)
• Product direction driven by niches, rather than mainstream

Analysis

I contend that the above costs and benefits (which are not exhaustive), apply to all OSS projects, not just Symbian. But the impact of these costs and benefits are different for different types of projects. So how do they affect Symbian?

Well, the main one bandied about is the codebase becoming free. I have seen quite a number of comments about how Symbian will eventually lose out to Linux due to the COG (cost of goods) pressures on phones. The most recent example is from a analysts at ABIresearch. This, of course, flies in the face of significant evidence that indicates otherwise: the continuing success of Windows as a desktop OS, despite intense pricing pressures on PCs. But then, analysts usually don't seem terribly connected to reality.

The problem with all of this is, ironically, exactly what MS argues: OSS software is only free in the sense that the codebase, as it is, doesn't cost anything. Of course, the chances that the existing codebase will be satisfactory are fairly slim. (The irony in MS pointing this out, in case you haven't guessed, is that MS's codebase is far from satisfactory, and MS seem incapable of rendering it so.)

So the TCP (Total Cost of Production; made that one up in lieu of searching for the real term) of a Linux based phone is likely to remain at least as high as a Symbian one. So there is no real benefit to the customer (i.e. the handset manufacturers), and a very real cost to Symbian (they can't get any licensing revenues if Symbian is OSS).

How about the access to more developers and niche-specialist developers? Well, this benefit is offset by the cost that these developers are a) relatively poor quality and b) relatively uncontrolled. For Symbian, these costs matter. Symbian is creating an OS, not some dodgy web 2.0 app. Quality is critical for this type of software, and so is tight control. A poorly controlled API leads to fragmentation (just look at Linux). As for quality, Linux has demonstrated that OSS can deliver quality, but it seems to come at the cost of fragmentation (again) and bloat (both of code size and app UI).

Don't get me wrong, I use Linux (Fedora), but only as servers, where bloat and fragmentation aren't as critical. But on a phone? Give me a break!

The problem is that these forces are a natural by-product of the OSS process. They can be fought, but not completely neutralised. And they are all inimical to Symbian's strengths.

So should Symbian consider OSS?

No way!

Should Symbian release source code via a free license to developers? Hey, that's a different (and great) idea. And so should Nokia (with S60) and UIQ. The old days of ER5's Eikon source being available in the SDK were both better (access to the source meant inheritance was a lot easier in some ways because you could see what you were inheriting) and worse (Psion was lazy with documenting the code, because you had the source). Heck, if MS can release source to some of its UI code, I'm sure Symbian can.

Carnival of the Mobilists #65 at Golden Swamp

Judy Brek, at http://www.goldenswamp.com/ has graciously included my previous post, Why the iPhone's UI won't scale in Carnival of the Mobilists 65. Check out the whole Carnival, there are always plenty of good posts to read, and make sure you have a look around Judy's whole site as well.

Contextuality on mobile devices

In my last entry I mentioned contextuality. What is it? Can it be precisely defined? Why is it important? Let's answer all those questions.

Well, it's a term that I coined, and it means:

Showing sufficient context for the information that the user is reading or editing.

If a UI lacks contextuality, it doesn't display the context of the information the user's interested in. Let's continue with the iPhone as an example:

In the calendar, editing an entry involves selecting the entry and going into an "entry edit mode" (in Symbian, especially UIQ, this is called the "edit view"). The problem with the entry edit mode is that you can only see information relating to the current entry. Unfortunately, for calendar entries, the relevant context includes the other entries in that day. Hiding the rest of the day from the user means that when they make changes to that entry, they don't know how that will interact with other entries. (Will it cause a conflict? Will it provide enough time to move from activity to activity?)

This is a common mistake, particularly on mobile devices because of their limited screen real estate. But it's a mistake that's often made even on the desktop. A good example of how it should be done is, again, provided by Mac OS X, with iCal. iCal has a slide out pane that provides edit controls for editing activities. This pane slides out from the day/week/month view, which stays visible, keeping the activities in that view updated with changes in the edit pane (and vice-versa).

This toolpane concept has been around for a long time. I first encountered it on Artworks running under RiscOS on Acorn's Archimedes machines (the first ARM-based computers) back around 1991. It still works brilliantly on Artworks' descendant, Xara Xtreme (my favourite drawing application, available here).

Most other tools, such as anything from Adobe, Macromedia, MS, etc. tended to violate contextuality by dumping you into a dialog to do anything, which robbed you of the context of what your changes did to your document. (Dialogs have another problem: preventing "direct manipulation", but that's a subject for another post.)

Fortunately everyone seems to be cottoning on to contextuality on desktop apps (although a lot of Web 2.0 apps, such as this one courtesy of Google, set us back several years). However, the same can't be said in the mobile world.

Because of the space limitations of mobile screens, it's very important to understand how much context is enough. Desktop apps can be profligate with their screen space, but we can't. So how much context is enough?

The minimal context for a piece of data can be found by
determining the smallest amount of surrounding data which cannot
be completely reordered without significantly changing its meaning.

So, for example, a single contact record is the smallest chunk of context for contact information. Whole contacts can be reordered without changing their meaning (and, indeed, all contact applications support this -- it's called changing the sorting order). But fields within a contact cannot be reordered to the extent that they end up in other contacts, because that would change their meaning. So a single contact is the context of contact information.

What about for calendar activities? Well, this one actually depends on the user's purpose, and that's why calendar applications (and, indeed, paper representations of calendars) have multiple types of views. But at it's most focused, a calendar activity's minimal context is a whole day of activities. If the activities are moved around in the day, they change their meaning.

(Sometimes users want to work on a larger scale, such as a week or month, and thus there are week and month views to calendars, but often a day is enough, and each day can be considered interchangeable or independent.)

Contextuality is important. Without it the user is robbed of important information about what they are viewing or changing. Yet how often is it considered? Indeed, the whole design of UI's like Series 60, UIQ, Palm OS, Windows Mobile, and iPhone seem designed to violate this concept.

Could this be one of the reasons why people are so reluctant to edit information on their mobile devices (even when they have perfectly adequate keyboards, and there are significant benefits to making updates on the run)?

Why the iPhone's UI won't scale

For all its beauty and elegance, the iPhone's UI, in the state demoed on Apple's website and at Macworld, has at least two fundamental issues, even disregarding the whole touch-screen/haptics debate.

These two issues are scalability and contextuality -- a lack of both. I'll address the first issue in this entry, and the second issue in a later entry.

There are two areas where the iPhone UI will fail to scale.

1. One-touch home page can't scale

The iPhone relies on being a feature phone (not a smartphone, see my previous entry) to implement Steve Jobs's vaunted two clicks from anywhere UI functionality. If you add extra apps, for example a pedometer, a finances app, a possessions (eg. books, CDs, etc.) database, an ebook reader, a word processor, a spreadsheet, a presentation app, a dictionary, etc. etc. you will quickly run out of screen real estate.

When that happens, you have two choices:

• Add a scroll bar, which makes some items three clicks away (tap the home button, tap the scroll bar or "flick scroll", tap the icon) or more
• Add folders, which makes items three taps away (tap home, tap the folder, tap the icon)

Basically, there's nothing magic about Apple's "two-clicks to anywhere". It's just a result of crippleware.

2. Flick-scrolling without context reduction only works for small datasets

This one is a bigger problem for Apple. Pay careful attention to the demo of the Contacts application on the iPhone (available at http://www.apple.com/iphone/phone/). Notice that the app has no search icon or text pane. All it has is a list of contacts and the alphabet down the side.

The demo shows how cool flick-scrolling looks. What it doesn't show is how painful it would be searching through a database of 400+ contacts (which is not a big database for many users, now that people sync with their PCs). Flick-scrolling is inherently imprecise, and thus a slow way to find a single item in a large dataset (which is mostly what you want to do with a contacts database on a phone).

What's the fastest way to find a contact? Well, iContacts on the Mac actually has it built in: a filter that narrows the contacts list. It's called Spotlight, and is available on virtually every window on the Mac. However, it is conspicuously absent from the iPhone.

(The reason it's absent from the iPhone is pretty easy to guess: Spotlight isn't much chop without a keyboard to enter text, but the iPhone doesn't have any ugly plastic buttons, so if you want to enter text on it, your usable screen space suddenly vanishes away, eaten up by an ugly onscreen keyboard -- have a look at the SMS demo at the iPhone site. So filtering a large list by entering text is not something that the iPhone's form-factor is very good at.)

Unfortunately, flick-scrolling really isn't a substitute for Spotlight-style filtering for two reasons:

1. Flick-scrolling is imprecise. I've already mentioned that this imprecision makes navigating to a single contact a pain. It's hard to describe, and, until I've played with an iPhone, I can't be sure just how painful flick-scrolling will be, but I'm pretty sure it'll be painful. Even if flick-scrolling is magically wonderful, there's still another reason why it's vastly inferior to filtering a long list. It is telling that the contacts list in Apple's demo is pretty small.
2. Long lists are hard to visually search. The item you're looking for just gets lost in the midst of the huge number of items you're looking through. Humans are very good at pattern matching, but even humans get overwhelmed if there are simply too many candidates to match against, and scrolling doesn't reduce the candidate pool.

This is where filtering really makes its money: it reduces the context to the minimal, useful context. If I'm looking for my contact in my database, all the other Lithgows overwhelm it. Even if I can tap on "L", I'm still faced with a lot of distractingly similar near-matches. But if I can filter for "Malcolm", then I can remove all of them with seven touches (in fact, I can remove pretty much all of them with three or four touches: "mal" or "malc"). Then I don't have to scour the list, I simply choose the only option.

The inherent lack of this capability in the iPhone's UI will make for a frustrating experience for people who have any significant amount of data. The iPhone thus limits itself to toy status (much as the Newton did up until it's swansong with the MP 2000).

Can Apple fix this? Yes, they can, but fixing involves moving back towards standard PDA interfaces, either providing a physical keyboard (unlikely), or providing some form of touch-input for letters (there are many innovative solutions out there, check out Ring-Writer, for example).

But there are other problems with the iPhone's UI that indicate that Apple has been thinking more about glamour than substance. The major one is the lack of contextuality, and I'll be talking about that next. Stay tuned.

What is a smartphone?

So, let's get started.

What is a "smartphone"? This is pretty important to get right in the first place.

My definition betrays my origin (as usually happens with definitions):

A smartphone is a phone that can have third party
software added by the user with native access.

Let's unpack that:

A phone

A phone is simply a device with voice communications as its primary purpose.

Third party software

Third party software creates an "ecosystem" around a device. Or, to put it another way, it transforms a device (or family of devices) into a "platform" for delivery of all types of services. Third party software is what has kept Windows (the PC/laptop version) so dominant. And MS's greatest strength is that they are well and truly aware of this.

Symbian, Palm OS, Windows Mobile, and one or two variants of Linux usually qualify for this requirement. However, most Japanese Symbian phones cannot be considered smartphones because they are locked down, and cannot accept native third party software. Most Linux phones are in the same boat.

RIM is a peculiar case because their API's and, supposedly, their own apps are coded in Java.

Added by the user

If third party software can only be added by the manufacturer or operator, it may as well not be third party software. The beauty of third party software is that it can do things that the manufacturer or operator may never even dream of doing. And these things may turn out to be things that the users never thought of, but suddenly discover they've always really wanted.

This is the key to the success of the PC.

With native access

What "native access" means, when applied to third party software, is that this add-on software runs with the same privileges and access (potentially) as the native software. In the case of Symbian, Windows Mobile, and Palm OS, for example, the native software is written in C++, and third party software can be written in C++ with access to the same API's.

There are some limits. For example, Symbian has a "Platform Security" framework, that requires special signing to allow applications to access certain API's. But this is applied to all Symbian software, including their own. Other exceptions include phone features that have private API's (such as the "magic word", or voice activation, technology on Sony Ericsson UIQ phones). However, so long as this is constrained to features on the periphery, it's unlikely to cause issues.

Why is this important?

This is important because it has a huge impact on the development of the phone. Feature phones (powerful, feature-rich phones without a native programming environment) are only able to do what their manufacturers equip them to do, or possibly do something dinky in a clumsy fashion via a Java applet. The user cannot almost transparently replace the calendar interface on their phone, for example.

This means feature phones are merely devices, not platforms. They are doomed to being constrained to their manufactured purpose, or at best, thin clients to the mobile web.

Smart phones, on the other hand, can potentially do anything.

The fact that most owners of smartphones aren't aware that their phone is a smartphone is, ultimately, irrelevant. Many people don't install software on their PC until there is suddenly a compelling reason (such as the invention of a new category of software, like a web browser, say).

Where does this leave someone like Apple, with their closed iPhone (which, by my definition, is merely a very high-end feature phone)? It leaves them hoping desperately that no-one makes a breakthrough app on other platforms, or that they can copy it in time if that does happen. Apple's used to this, though. Still, this limitation has firmly kept their products in a niche. A quite profitable niche, but a niche nonetheless.

Nokia, like MS, is not happy with being in a niche. They want to dominate. And they, at least, are giving themselves a chance to do that with their S60 smartphones.

-Malcolm.

Introduction to Smart Dreaming

Sigh, I've succumbed to blogitis...

Up front, let's define the purpose of this blog. It's pretty simple.

1. To comment on the Smartphone industry (and broader software industry), from the perspective of the owner of a small Independant Software Vendor (ISV) writing applications for Symbian smartphones (see http://www.dreamspring.com/).
2. To discuss the area that we're involved in (Life Management, using smartphones as a thick client).
3. To make snarky comments about the industry in general. :-)

I've found a lot of rubbish out there, and I'm sure you have too. So how do you know my stuff is worth reading? Well, you won't until I've written some, so stay tuned.

I'll be talking about stuff like why Palm is doomed (as if everyone didn't know that already - but I can at least claim to have held this opinion for at least five years), why the iPhone will be merely a niche success (like every other Apple product is or will end up being, which doesn't mean they're not good, BTW), why Symbian will win the smartphone wars (but MS won't lose), what's good and bad with UIQ 3 and S60, and so on.

Anyway, welcome on board and enjoy the ride.

-Malcolm.