Symbian Signed and control

My posting yesterday on "Symbian Signed basics" has attracted more comments (containing lots of thoughtful ideas as well as evident passion) than I can quickly answer.

For now, I'd like to respond to Ian, who raised the following point:

There is no need for signing to ensure safety from malware. That's what (platform) security is for.

Requiring signing without the option of user override is about control, pure and simple.

Can you give me a good reason why people should not have control of their property and why it should be in vendor's hands instead?

The first answer is that, when users purchase a phone, they typically enter into a contract with the supplier, and agree to be bound by the terms of that contract. In cases when the phone is being subsidised or supported by a network operator, the network operator only enters into the relationship on account of a set of assumptions about what the user is going to do with the phone. The network operator can reasonably seek to limit what the user does with the handset - even though the user has paid money for the device.

That's the reason, for example, why T-Mobile stipulated (and apparently received agreement from Google) that no application providing VoIP over cellular data could be installed onto the Android G1. Otherwise, the cost and revenue assumptions of T-Mobile would be invalidated. From Daniel Roth on Wired:

T-Mobile made a big deal about being one of the few carriers embracing open standards and open systems -- which is true. Yet just how open is a (sorry) open question. When I talked to Cole Brodman, the CTO of T-Mobile, after the event about what would stop something like Skype from designing a program that could run on the phone, negating the need for a massive voice plan, he said he had "worked with Google" to make sure Android couldn't run VOIP. "We want to be open in a way that consumers can rely on," is the way Brodman put it to me.

Here's another example. Suppose you spend a lot of money, buying a phone, and two months afterwards, you notice that the battery systematically runs down after only a few hours of use. You're naturally upset with the device, so you take it back to the shop where you bought it from, asking for your money back. Or you spend hours on the phone to the support agents of the network operator trying to diagnose the problem. Either way, the profit made by the handset manufacturer or the network operator from selling you that phone has probably been more than wiped out by the cost of them attending to this usability issue.

But suppose it turns out that the cause of the battery running flat is a third party application you installed which, unknown to you, burns up processor cycles in background. Suppose it also turns out that you have been misled as to the origin of that application: when you installed it, you thought it said "This application has been supplied by your bank, Barclays", but you didn't notice that the certificate from the supplier said (eg) "Barclys" instead of "Barclays". You thought you could trust the website where you found this application, or the people who (apparently) emailed it to you, but it turns out you were wrong. However - and this is the point - you've even forgotten that you installed this app.

The second answer is that, even when we own items, we have social obligations as to what we do with them. We shouldn't play music too loudly in public places. We shouldn't leave garbage in public places. We shouldn't broadcast radio interference over networks. We shouldn't hog more of our fair share of pooled public resources. And, we shouldn't negatively impact the wireless networks (and the associated support infrastructure) on which our mobile phones live.

Both these answers are reasons in principle why users have to accept some limits on what they do with the mobile phones they have purchased.

The more interesting questions, however, are as follows:

1. To what extent actual do application signing programs meet these requirements - and to what extent do these programs instead support other, less praiseworthy goals?


2. Could variants of existing signing programs meet these requirements in better ways?

For example, consumers are already familiar with the idea that, when they disassemble the hardware of a device they have purchased, they typically invalidate the manufacturer warranty. (On my Psion Series 5mx, there's still a sticker in place, over a screw, that says "Warranty void if removed".) Would it be possible to educate handset users in a similar way that:

• Their handsets start out in a situation of having a manufacturer warranty


• However, if they install an unsigned application (or something similar), they are henceforth on their own, as regards support?

Accelerating out of molasses

Michael Mace has posted a characteristically thoughtful article on his Mobile Opportunity blog:

Every time I think about Nokia and Symbian, I can't help picturing a man knee-deep in molasses, running as fast as he can. He's working up a sweat, thrashing and stumbling forward, and proudly points out that for someone knee-deep in molasses he's making really good time...

The posting is entitled "Nokia: Running in molasses". It arose from Mike reflecting on some of what he heard at the recent Symbian Partner Event (SPE) in San Francisco. The posting is well worth reading. I appreciate the issues that Mike raises. These issues are significant. But as you might expect, I have a somewhat different perspective on some of them.

Large software doesn't mean that software development has to go slow

Charles Davies, Symbian CTO, pointed out to us that Symbian OS has about 450,000 source files. That's right, half a million files. They're organized into 85 "packages"...

There are economies of scale as well as dis-economies of scale. The point of the careful division of the Symbian Platform software into packages is to enable each of the resulting packages to have greater autonomy - and, therefore, to progress more quickly.

There's one subtle point here. Many of the packages include teams from both Symbian and from S60. This applies to cases where the separation of functionality between the two formerly distinct companies resulted in sub-optimal development. Now that Nokia's acquisition of Symbian has completed, these boundaries can be intelligently re-designed.

Disruption, size, and organisational design

This brings me to a comment on the ideas of Clayton Christensen. Here's another extract from Mike Mace's article:

If the folks at Nokia really think they are well positioned to crush Apple, they need to go re-read The Innovator's Dilemma. Being big is not a benefit in a rapidly-changing market with emerging segments.

Agreed, being big is no guarantee of being able to respond well to changing market conditions. That's why I'm personally a big fan of Agile. Agile can help established companies (whether large or small) to launch and embrace disruptions. As Scott Anthony, one of Christensen's co-authors, has recently commented in his article "Can Established Companies Disrupt?":

The data suggests that it is increasingly common for an established company to launch disruptive innovations. More and more incumbents are learning how to embrace disruptive principles such as:

• Put the customer, and their important, unsatisfied job-to-be-done at the center of the innovation equation
• Embrace the power of simplicity, convenience, and affordability
• Create organizational space for disruptive growth businesses
• Consider innovation levers beyond features and functions
• Become world class at testing, iterating and adjusting

As I said, being big can have its advantages as well as its disadvantages, so long as individual parts of the company have sufficient autonomy. The hard part is knowing when to seek closer ties, and when to seek looser ties. One of Christensen's later books had some very interesting advice on that score. I can't remember for sure whether that book was "The Innovator's Solution" or "Seeing What's Next". The advice was that where performance remains a critical differentiator, you should look for a tight coupling. Where performance is already "good enough", you should seek a loose coupling - with open APIs and a choice of alternative solutions.

As soon as I read these words, some time around 2003-2004, I had a gut reaction that, one day, the relevant teams in Symbian software engineering and S60 software engineering ought to be combined. It took a long time for that insight to be fulfilled. But now that it's happening, there's plenty of good reason to expect the resulting combined company to start accelerating its development.

Development in parallel with change

Back to Mike Mace, commenting on the SPE presentation by Charles Davies:

Davies talked about the substantial challenges involved in open sourcing a code base that large. He said it will take up to another two years before all of the code is released under the Eclipse license. In the meantime, a majority of the code on launch day of the foundation will be in a more restrictive license that requires registration and a payment of $1,500 for access. There's also a small amount of third party copyrighted code within Symbian, and the foundation is trying to either get the rights to that code, or figure a way to make it available in binary format.

Those are all typical problems when a project is moving to open source, and the upshot of them is that Symbian won't be able to get the full benefits of its move to open source until quite a while after the foundation is launched. What slows the process down is the amount of code that Symbian and Nokia have to move. I believe that Symbian OS is probably the largest software project ever taken from closed to open source. If you've ever dealt with moving code to open source, you'll know how staggeringly complex the legal reviews are. What Nokia and Symbian are doing is heroic, scary, and incredibly tedious. It's like, well, running in molasses.

I have four comments on this:

1. Even though the full transition to open source may take up to two years from the initial announcement of the foundation (that is, until mid 2010), there are plenty of other things happening in the meantime - with a series of interim releases that progressively convert more of the software from the community-source Symbian Foundation Licence to the open-source Ecliplse Public Licence;
2. There will be new technologies and new UI features in these interim releases;
3. The interim releases should already achieve at least some of the considerable benefits of both open source and community source; the first packages which will become available under the EPL are being chosen so that independent developers can do useful things with some of them (including contributing back working code enhancements);
4. The legal reviews may initially seem daunting, but with the help of modern code-scanning tools and with the advantage of "practice makes perfect", the process is likely to speed up considerably along the way.

Cool stuff in the lab

Mike ends the main part of his article as follows:

Nokia still has a lot of time to get it right. But do they really understand what needs to change? I can't tell, because all I usually get from them is monologues on how big their business is and how much cool stuff they have in the lab.

I accept that analysts must inevitably hedge their bets, regarding the extent of future success of the main mobile operating systems, until a period of proving over the next 12-24 months has shown what these operating systems can actually accomplish. I eagerly look forward to the day when more of the Symbian and Nokia roadmap of stunning new technology, new services, and new user experience attains greater visibility. When that happens, analysts are likely to come down off the hedge.

My own expectation is that the moves to integrate Symbian and Nokia, and to create the Symbian Foundation, will see a substantial speed up of innovation over that time period. But I'm not taking this for granted. After all, I'm well aware of the original subtitle of "The Innovator's Dilemma": "When new technologies cause great firms to fail".

Symbian Signed basics

It's not just Symbian that runs into some criticism over the operation of application certification and signing programs. (See eg the discussion on "Rogue Android apps rack up hidden charges".)

This is an area where there ought ideally to be a pooling of insights and best practice across the mobile industry.

On the other hand, there are plenty of conflicting views about what's best:

• "Make my network more secure? Yes, please!"
• "Make it easier to develop and deploy applications? Yes, please!"

If we go back to basics, what are the underlying requirements that lead to the existence of application certification and signing schemes? I append a list of potential requirements. I'll welcome feedback on the importance of various items on this list.

Note: I realise that many requirements in this list are not addressed by the current schemes.

a. Avoiding users suffering from malware

To avoid situations where users suffer at the hands of malware. By "malware", I mean badly behaved software (whether the software is intentionally or unintentionally badly behaved).

Examples of users suffering from malware include:

1. Unexpectedly high telephone bills
2. Unexpectedly low battery life
3. Inability to make or receive phone calls
4. Leakage without approval of personal information such as contacts, agenda, or location
5. Corruption of personal information such as contacts, agenda, or location
6. Leaving garbage or clutter behind on the handset, when the software is uninstalled
7. Interference with the operation of other applications, or other impact to handset performance.

b. Establishing user confidence in applications

To give users confidence that the applications they install will add to the value of the handset rather than detract from it.

c. Reducing the prevalence of cracked software

To make it less likely that users will install “cracked” free versions of commercial applications written by third parties, thereby depriving these third parties of income.

d. Avoiding resource-intensive virus scanners

To avoid mobile phones ending up needing to run the same kind of resource-intensive virus scanners that are common (and widely unloved) on PCs.

e. Avoiding networks suffering from malware

To avoid situations where network operators suffer at the hands of malware or unrestricted add-on applications. Examples of network operators suffering from such software include:

1. Having to allocate support personnel for users who encounter malware on their handsets
2. The network being overwhelmed as a result of data-intensive applications
3. Reprogrammed cellular data stacks behaving in ways that threaten the integrity of the wireless network and thereby invalidate the FCC (or similar) approval of the handset
4. DRM copy protected material, provided or distributed by the network operator, being accessed or copied by third party software in ways that violate the terms of the DRM licence
5. Revenue opportunities for network operators being lost due to alternative lower-cost third party applications being available.

f. Keeping networks open

To prevent network operators from imposing a blanket rule against all third party applications, which would in turn:

• Limit the innovation opportunities for third party developers
• Limit the appearance of genuinely useful third party applications.
  

g. Avoiding fragmentation of signing schemes

To avoid network operators from all implementing their own application certification and approval schemes, thereby significantly multiplying the effort required by third party developers to make their applications widely available; far better, therefore, for the Symbian world to agree on a single certification and approval mechanism, namely Symbian Signed.

The starfish and the spider

In my quest to understand the full potential of open and collaborative methods of working, I recently found myself re-reading "The Starfish and the Spider: The unstoppable power of leaderless organisations" by Ori Brafman and Rod Beckstrom.

I found this book to be utterly engrossing. I expect that its metaphor of the starfish vs. the spider will increasingly enter common parlance - the same way as "Tipping Point" did. In short:

• A starfish has a fully de-centralised nervous system, and can survive and prosper when it undergoes an apparent "head-on" attack;
• A spider has a CEO and a corporate headquarters, without which it cannot function.

The examples in the book show why there's a great deal at stake behind this contrast: issues of commercial revenues, the rise and fall of businesses, the operation of the Internet, and the rise and fall of change movements within society - where the change movements include such humdingers as Slave Emancipation, Female Equality, Animal Liberation, and Al Qaeda.

There are many stories running through the book, chosen both from history and from contemporary events. The stories are frequently picked up again from chapter to chapter, with key additional insights being drawn out. I found some of the stories to be familiar, but others were not. In all cases, the starfish/spider framework cast new light.

The book contains many implications for the question of how best to inspire and guide an open source ecosystem. Each chapter brought an important additional point to the analysis. For example:

• Factors allowing de-centralised organisations to flourish;
• The importance of self-organising "circles";
• The significance of so-called "catalyst" personalities;
• How successful de-centralised organisations often piggy-back pre-existing networks;
• How centralised organisations can go about combatting de-centralised opponents;
• Issues about combining aspects of both approaches.

Regarding hybrid approaches: the book argues that smart de-centralisation moves by both GE and Toyota are responsible for significant commercial successes in these companies. EBay is another example of a hybrid. Managing an open source community surely also falls into this category.

The book spoke personally to me on another level. As it explains, starfish organisations depend upon so-called "catalyst" figures, who may lack formal authority, and who are prepared to move into the background without clinging to power:

• Catalysts enable major reactions to take place, that would otherwise remain dormant;
• They trigger the deployments of huge resources from the environment;
• They make things happen, not by direct power, but by force of influence and inspiration.

There's a big difference between catalysts and CEOs. Think "Mary Poppins" rather than "Maria from Sound of Music". That gave me a handy new way of thinking about my own role in organisations. (I'm like Mary Poppins, rather than Maria! I tend to move on from the departments that I build up, rather than remaining in place.)

Discovering the adaptive unconscious

Like most people, I sometimes behave in ways that surprise and disappoint either myself or other people who are observing me. I'm occasionally dimly aware of strong under-currents of passion, that seem to have a life of their own. Of course I wonder to mysef, what's going on?

The anicent Greek Delphic injunction is "know thyself". Modern writers use the phrase "Emotional intelligence" to cover some of the same ground. As these modern writers point out, people who are manifestly unaware of their own emotions are unlikely to be promoted to positions of major responsibility within modern corporations or organisations.

Timothy Wilson's fascinating 2002 book "Strangers to ourselves - discovering the adaptive unconscious" takes a slightly different tack. Reading this book recently, I quickly warmed to its theme that - as implied in its title - our attempts to perceive and understand our own motivations can be a lot more difficult or counter-productive than we expect.

Through many examples, the book makes a convincing case that, in addition to our conscious mind, we have a powerful, thoughtful, intelligent, feelingful "adaptive unconscious" that frequently operates outside the knowledge of the conscious mind. It can be just as inaccessible to introspection by the conscious mind as is the operation of our digestive system. Because it is inaccessible, we can often be misled about why we do things (subsequently "fabricating" reasons to explain our behaviour, without realising that we are deceiving ourselves in the process). We can also be seriously misled about what we're feeling, and about what will make us happy.

This adaptive unconscious can often be at odds with our conscious mind:

• Experiments described in the book show how people, who in their conscious mind are sincerely unprejudiced against (eg) people of other races, can harbour latent prejudices that result in significant discrimation against certain job applicants.
• These unnoticed prejudices can even have fatal effects - if, for example, policemen have to react super-quickly to a potentially life-threatening situation, and mistakenly infer that (say) a black person is reaching for a gun in his pocket.

Of course, psychologists such as Freud have written widely on this general topic already. But the great merit of this book is that it provides a very balanced and thoughtful review of experimentation and analysis that has taken place throughout the 20th century into the unconscious mind. It puts Freud's ideas into a fuller context. For example, it shows the limitations of the idea that it is "repression" that keeps the activities of the unconscious mind hidden from conscious reflection. Repression is indeed one factor, but it's by no means the only one.

This book contains lots of thought-provoking examples about people's attempts to understand the well-springs of what motivates them. Here's one, from near the end of the book:

"When Sarah met Peter at a party, she did not think she liked him very much; in many ways he was not her type. However, afterwards, she found herself thinking about him a lot, and when Peter telephoned and asked her out for a date, she said yes. Now that she has agreed to the date, she discovers that she likes him more than she knew. This looks like an example of self-perception as self-revelation, because Sarah uses her behaviour to bring to light a prior feeling of which she was unaware, until she agreed to go our with Peter...

"But another possibility is that Sarah really did not like Peter at all when she first met him. She felt obligated to go out with him because he is the son of her mother's best friend, and her mother thought they would be a good match. Sarah does not fully realise this is the reason she said yes, and she mistakenly thinks. 'Hm, I guess I like Peter more than I thought I did, if I agreed to go out with him.' This would be an example of self-fabrication: Sarah misses the real reason for her behaviour...

"The difference between self-revelation and self-fabrication is crucial from the point of view of gaining self-knowledge. Inferring our internal states from our behaviour can be a good strategy if it reveals feelings of which we were previously unaware. It is not such a good strategy if it results in the fabrication of new feelings."

Another issue with gaining greater self-knowledge is that it can damage our self-confidence. The author argues that it can sometimes be beneficial to us to have a slightly inflated view about our talents. That way, we gain the energy to go about difficult tasks. (However, if the discrepancy between our own view and the reality is too great, that's another matter.)

The book concludes by urging that we follow another piece of advice from ancient times. He quotes Aristotle approvingly: "We acquire [virtues] by first having put them into action... we become just by the practice of just actions, self-controlling by exercising self-control, and courageous by performing acts of courage". In short, "do good, to be good".

He goes on to say, "If we are dissatisfied with some aspect of our lives, one of the best approaches is to act more like the person we want to be, rather than sitting around analyzing ourselves."

The book has struck a real chord with me, but it leaves many questions in my mind. Next on my reading list on this same general field is "The Happiness Hypothesis: finding modern truth in ancient wisdom" by Jonathan Haidt.

All Carbide C++ editions are now free of charge

One of the persistent "niggle points" with Symbian OS C++ development has been that developers had to pay significant amounts of money to purchase those features of the Carbide integrated developer environment (IDE) which provided some highly desired functionality such as on-target debugging.

So there's great news today: Carbide v2 now has ZERO licence fee for all editions:

Carbide.c++ 2.0 is now available with support for the latest technologies based on Symbian OS, such as S60 5th Edition and the Qt platform, and it offers significant improvements throughout.

In addition to the technical improvements, Carbide.c++ 2.0 is now available free of charge.

This has already been picked up by various bloggers, including Lucian Tomuta - Carbide.c++ - new and free (yes, like in "free beer") - and Simon Judge - Carbide.c++ 2.0 Free of Charge.

The cost reduction isn't the only piece of good news about this new version. As the Carbide product pages emphasise:

Improvements throughout Carbide.c++ have been designed to make developing Symbian OS C/C++ applications quicker and easier. These improvements include speed and accuracy in code completion, faster response in the Performance Investigator reporting tools, and new connection management for on-device debugging.

This news deserves to run and run.

Accelerating the transformation

As noted by Tom Krazit of CNET News, there was lots more news from yesterday's Nokia World event than merely the buzz about the newly announced highly attractive N97. It was also announced that the acquisition of Symbian by Nokia has completed.

One practical impact of the completion of this deal is that preparation can now accelerate - for the forthcoming Symbian Foundation, and for the deep integration of the Symbian and S60 software engineering teams.

As Tom Krazit notes:

After entertaining the world press in Barcelona during the early part of this week, Symbian and Nokia executives will be in San Francisco later this week to discuss their plans for mobile computing and open source, and we'll have reports from the Symbian Partner Event on Thursday.

Personally, I'm about to board my flight to San Francisco for this event. I'm particularly looking forward to open and insightful discussion at this event - including the panel discussion on "Succeeding in the US: the key factors", where I'll be asking for comments and questions from the audience.

Just as I expect very significant amounts of wireless innovation to come from North America in the near future, I also expect very significant amounts to come, perhaps more in the future, from China. Later this month I'll be speaking at an event in Beijing, about "Symbian Platform Development". I'm looking forward to learning a lot - since I plan on listening as well as speaking :-)

In case anyone would like to try to meet up while I'm in San Francisco or in Beijing, please get in touch.

Footnote: There's still time to register for the Partner Event.