dw2

6 March 2010

Fragmentation beyond good

Filed under: architecture, developer experience, fragmentation — David Wood @ 6:53 pm

Hmm, I thought I’d finished writing about mobile fragmentation, but the topic keeps rumbling on.

Some comments from distinguished industry colleagues prompt me to address this topic one more time.

My fellow Symbian co-founder Juha Christensen suggests “Fragmentation is good“:

I believe that already in 2011 we will see smartphones outsell “lesser” phones. By the end of 2012, there will be an installed base of over one billion smartphones. That year along, over 600 million smartphones will be sold worldwide.

One of the things that makes phones so different from PCs has to do with micro-segmentation. Like we’re getting used to hearing “there’s an app for everything,” we are a year or so away from “there’s a phone for every person”. Sony Ericsson’s newly released XPERIA 10 Mini, is a good examples of what’s to come. Intense segmentation of the market, opening up thousands of niches. Just like we all don’t drive the same car, the days are over where everyone in Silicon Valley either has the same BlackBerry, iPhone or Nexus One.

With over a billion people using smartphones, we will see thousands of micro-segments being serviced by thousands of different designs and usage model…

So far, I fully agree with Juha.  However, micro-segmentation doesn’t need to imply platform fragmentation.

With a good architecture, users can get lots of choice, even though there’s an underlying commonality of developer APIs.

As far as users are concerned, the platform supports multiple different interfaces – even though, as far as developers are concerned, there’s a single programming interface.

But Juha continues:

And this is where the goodness of fragmentation comes in. An operating system design comes with inherent restrictions. There is a need to make sure apps run the same way on all devices, that aspect ratios are more or less the same and a ton of other restrictions aimed a making the experience really good.

If one operating system was going to serve all form factors, all market segments, all use cases and all price points, the market would start trending towards a lowest common denominator…

This is where I disagree.  A well-designed mobile operating system can support a vast range of different kinds of devices.  There doesn’t need to be a “lowest common demoninator” effect.

There are, of course, some important benefits of competition between multiple different mobile operating systems.  But it’s a matter of degree.  If there’s too much competition or too much fragmentation, chaos ensues.

That’s why I prefer to say that the amount of fragmentation we have today, in the mobile space, is “beyond good”.

Sebastian Nyström also commented on the previous discussion, via Twitter:

Again we see the theme: fragmentation is part of a chain of cause and effect that has good results for consumers.  And, to an extent, I agree.  But only to a degree.

If the current amount of fragmentation is good, does that mean that twice as much fragmentation will be twice as good for consumers?  Or that ten times as much fragmentation will be ten times as good for consumers…?

If fragmentation is unconditionally good for consumers, should the designers of Qt (to pick, as an example, one important intermediate mobile platform) deliberately fragment it, into several different incompatible versions?

Clearly, it’s a question of degree.  But what degree is optimal?

Bruce Carney – former head of the Symbian Developer Network – raised the following points:

My $0.02 worth: don’t disagree that the industry should invest energy in standardization, but just cannot see the set of circumstances (or benevolent dictatorship) that will drive it as the value chain is too complex and fragmentation is a nice control point for too many actors…

So, I agree with Richard’s article. I have spend 10 years listening to developers bleet on about fragmentation, and if I could give them a simple message it would be “deal with it”, it allows you to find a niche and exploit it. Without fragmentation there would be a small number of winner-take-alls and most of you wouldn’t exist.

Yes, there’s good sense in telling developers to “deal with it”.  But there’s danger in that approach, too.

I’m reminded of an ongoing discussion that recurred time and again about strategy towards developers in Symbian:

  • Should we try to minimise compatibility breaks (such as between Symbian OS v8 and v9), or should we just tell developers to “deal with it”?
  • Should we try to minimise platform fragmentation, or should we just tell developers to “deal with it”?

The argument that developers should just accept things is that, after all, there was a big market awaiting them, with Symbian devices.  The pain of dealing with the inconsistencies (etc) of the Symbian world would be worth it.

However, history threw up new competitors, who had significantly simpler development systems.

And that’s a reminder, at a different level, for everyone preaching complacency about today’s mobile developer systems.  We need to remember that developers have choices.  Instead of working on mobile projects, they may well choose to work on something quite different instead.  The mobile opportunity is huge, but it’s by no means the only opportunity in town.  Those of us who want the mobile industry to thrive should, therefore, be constantly looking for ways to address the pain points and friction that mobile developers are experiencing.

4 March 2010

Coping with mobile fragmentation

Filed under: applications, developer experience, fragmentation, runtimes, smartphones, standards — David Wood @ 10:21 pm

My recent article “Choosing intermediate mobile platforms” appeared on the same day as the TechCrunch article by Rich Wong, “In Mobile, Fragmentation is Forever. Deal With It“.  Despite the different titles, the articles covered many of the same topics.

Rich and I were fellow jury members at the Emerging Startups Mobile Premier Awards in Barcelona last month.  The discussions of the jury room ought to be kept confidential, but I’m not revealing too many secrets if I say that the topic of de-fragmentation magic bullets came up during our deliberations.  So it’s no coincidence that we both have something to say on the topic!

Even though I’ve written about mobile fragmentation many times in the past, Rich’s article has spurred me to put pen to paper one more time.  Mainly I agree with what he says, though there are a few additional points that deserve to be stressed.

Points of agreement

  • Mobile data is on fire. Despite a few false starts, we are now in the midst of a transformative “Open Mobile 3rd Wave” … We are just in the early swell of the wave … thanks to continued improvements we’re now seeing in smart phones, mobile OS platforms and 3G/4G networks, the raw ingredients are just getting better every month.
  • There is an alphabet soup of protocols, standards, and regional differences by country which can be daunting for any entrepreneur. Just look at the range of technologies on handset platforms alone…
  • Anyone who is waiting for a single silver bullet to solve fragmentation issues in mobile will be waiting a very long time, especially if they want to go after the global mobile opportunity…
  • Sadly, whether or not there is an elegant technical answer, it will be hard to drive any single set of worldwide standards given the different economic incentives of the many players, however good it would be for developers…
  • Get a guide.  It is difficult to explain the subtleties of the mobile ecosystem without a longer dialogue, but the good news is that there are quite a few battle-scarred mobile veterans around that can help you with the Cliff Notes on the industry. Find one to help you.
  • Don’t wait.  There’s an incredible startup and wealth-creating opportunity in this new arena of Open Mobile. The smartest entrepreneurs will not wait for these fragmentation issues to be solved but are figuring out now how to pick a use case, a core platform, and geography to bound their problem and get going. Once you have initial momentum, you can pick through these fragmentation landmines, and make a 2nd and 3rd step. Don’t wait for the unifying technology to solve these issues before diving in. It’s going to be an exciting time to build great mobile companies this next 5-7 years.

Next, let’s extend the discussion:

Some developers can find a magic bullet

It’s true: there won’t, in the foreseeable future, be a single platform that all developers can use to solve all their mobile needs.

However, platforms and tools are appearing which can address all the mobile needs of some developers.  I tried to give some examples of these potential solutions in my previous article.

I’m far from being an expert in any of these systems, so I risk being completely wrong in my assessment.  However, it does appear that at least some of these emerging solutions can remove a significant part of the technical pain from a developer who wants to deploy a particular kind of solution across a wide range of mobile devices.

Depending on the kind of application the developer has in mind, a different intermediate platform may be needed.  So, no single magic bullet.  But there are plenty of smart solutions that deserve a hearing.

Before trying to roll their own mobile solutions, developers should, therefore, take a look at what’s already available.

New intermediate platforms for old phones

Rich makes a good point when he notes,

One of the worst myths floating around the blogosphere is the wait by some for a “unifying technology” that will make things “simpler and easier” to develop services and apps for the global mobile market.  At times, some have claimed that Java (J2ME) was the answer, then Flash Lite, then Webkit browsers, and most recently HTML5. While each solution has its merits, there will not be any unification anytime soon. Even as HTML5 richness has improved substantially, browser support will still vary and many, many phones will not support HTML5 for 7+ years.

In other words, even if new devices contain a powerful new intermediate platform (such as HTML5), this will leave the vast majority of existing phones in the cold.

However, this dynamic can change, to the extent that new platforms can be installed on existing phones.

For example, Qt Labs have recently described a “smart installer” that is now available for beta testing:

Qt 4.6.2 is released, and in addition to all the bug fixes in it, we’ve also snuck in a feature or two, especially for the Symbian platform. One of interest is the ability for Qt to make use of the beta version of the Nokia Smart Installer, which makes it easier to deploy your Qt application to Symbian phones…

When the user now installs yourapp_installer.sis on their phone, the Smart Installer will go on-line and get all the dependencies that your Qt application requires, typically Qt and QtWebkit + Open C. If these packages are already installed on the phone, the Smart Installer does nothing. So, it is a little bit like an “apt-get for Symbian” has been wrapped around your application.

In other words, the Qt environment will be automatically installed onto the phone, if it’s not already present.

The drawbacks with this, of course, include the facts that upgraded new intermediate platforms can:

  • Have heavy hardware requirements – for example, they may use up a considerable portion of the available memory on older phones;
  • Be difficult to install on simpler phones (the above “smart installer” depends on the Symbian software installation system being present on the phone).

However, we can see these points as challenges rather than dead ends.  And it’s handy that there are a considerable number of intermediate platforms under development, adopting different approaches.  It’s reasonable to expect that at least some of these platforms will find ways to reach out successfully to older devices.

An imperative to solve the fragmentation problem

It’s true that developers need to make progress in the existing, heavily fragmented mobile world, without waiting for the fragmentation to be solved.

However, this doesn’t mean the mobile industry should stop worrying about the drawbacks of excess fragmentation.  The effort that people have to put in to bridge different fragments of the mobile world is effort that would be better placed providing direct benefits to users.

  • For example, suppose that a developer puts 40 units of effort into the platform-independent logic of an application, and then another 30 units of effort for each adaptation of the application to a different mobile operating system platform.  To cover six different mobile platforms would require a total of 220 units of effort.
  • Imagine, instead, that the developer could use an intermediate platform that would cover all these operating systems.  Suppose in this case that the adaptation to the single intermediate platform consumes 30 units of effort (on top of the 40 units for the platform-independent logic), and then the developer prefers to add a little polish for each of the different operating systems.  If the intermediate platform is doing its job well, this final polish ought be require something like just 5 units of effort each time.  That makes a total of 100 units of effort.
  • The net saving of 120 units of effort can then be applied to developing v2 of the application, or to some other quite different project, rather than wrestling with different mobile operating systems.

So whilst we advise developers that their approach to fragmentation should be to “Cope with it”, we should be vigorously campaiging at the same time for rapid progress towards meaningful standardisation of fit-for-purpose intermediate platforms.

The problems that need to be solved

I’ll end with some remarks about the main issues that this standardisation process (whether formal or informal) needs to solve:

  1. Performance – especially battery usage.  This includes coping with applications that want to run in background (potentially draining batteries).
  2. Functionality – so that the intermediate platform provides access to the really interesting parts of the functionality of the mobile device and the mobile networks.
  3. Security – to avoid applications wreaking havoc with user data (especially when these applications have accesss to advanced functionality of the device and network).
  4. Device reconfiguration – to cope with the fact that the “one box” design of most smartphones today is going to be replaced by “multi-component” designs over the next 3-7 years, with new roles for detachable screens (and more).
  5. Business models – to ensure that there are enough ways for applications to be economically viable (rather than just technically viable).
  6. Speed of standardisation – so that the big picture of “a rising tide lifts all boats” prevails, rather than the process becoming bogged down in smaller scale turf wars and filibustering.

On the last point, history might just show that the single most significant announcement at Mobile World Congress was about the formation of WAC – the Wholesale Application Community:

A number of the world’s leading telecommunications operators and device manufacturers are launching an open global alliance, that will establish a simple route to market for developers and provide access to the latest and widest range of innovative applications and services to as many customers as possible worldwide.

Together, we have signed a memorandum of understanding with the aim of building an environment or ’wholesale applications community’ where innovative applications can be developed irrespective of device or technology.

The new alliance, which represents more than three billion customers worldwide is inviting players from across the ICT industry, not only operators and developers, but also handset manufacturers and internet players to join forces to create an initiative based on openness and transparency. We believe this model presents the most compelling format on the market where developers will thrive and customers will reap the benefits of greater choice.

The mobile industry doesn’t have a great track record for working together quickly in this way.  However, more people than ever before in the industry are aware of the likely price of failure.

Choosing intermediate mobile platforms

Filed under: applications, developer experience, fragmentation, runtimes, smartphones — David Wood @ 12:55 am

Over the last few months, one thing I’ve noticed is the increasing number of companies who are offering mobile intermediate platforms and tools, that are designed to hide differences between underlying mobile operating systems.  For example, I heard about several new ones (that is, new for me) during Mobile World Congress at Barcelona.

I’d like to mention some of these companies.  But first, here’s some context.

People who want to develop applications (or provide content or services) for mobile devices face two levels of decision about platform choice.

The first decision is: what should developers do about the fact that different mobile devices run many different mobile operating systems (such as Symbian, BlackBerry, iPhone, Android, Palm webOS, LiMo, Maemo, Series 40, Bada, Windows Mobile…)?

In other words, should developers:

  1. Prioritise one operating system platform above all others, and attempt to become an expert in that?
  2. Try to become experts in all the major operating system platforms (including different UI families and other platform sub-variants)?
  3. Rely on third party experts who can deliver “mobile applications as a service” across a wide range of relevant operating systems?
  4. Try to find an intermediate platform and/or tool, that will hide the differences in underlying mobile operating system?

The first of these approaches has the merit of simplicity, but cuts off large numbers of devices.  The second of these approaches is particularly hard to achieve: it requires wide-ranging knowledge.  The third is what I advocated in an earlier blog post, “A strategy for mobile app development“: it involves building a relationship with an external company which maintains up-to-date knowledge about changing mobile operating systems.  The fourth is a variation on the third.  Rather than rely on paying a third party to use their own systems to develop apps for each different platform, it relies on finding an intermediate platform and/or tool, to achieve the same end.

That takes me to the second decision about platform choice: what should developers do about the fact that there are so many different intermediate platforms available?

In one way, this second decision is harder than the first one.  That’s because the number of intermediate platforms available seems to be larger even than the number of different mobile operating systems.  Therefore the choice is larger.  (And it seems to be getting larger all the time, with the emergence of new intermediate plaforms.)

But, thankfully, in another way, this decision is easier.  That’s because there may well be more than one “right answer”.  Depending on the type of applications being developed, various different intermediate platforms are well-suited to distributing the application acrosss a wide range of mobile devices.

I’m not expecting a consolidation, any time soon, down to just a few intermediate mobile platforms.  Developers’ needs are too varied for that.  But I am expecting at least some of these platforms to become better and better, as their owners respond smartly to the evolving needs of the growing number of developers who want to bring applications to ever larger numbers of mobile devices.

Here are just four of these platforms which have caught my eye recently.  As I said, different platforms are appropriate for different kinds of developer needs.

1. JumpStart Wireless BusinessSuite

JumpStart Wireless has a solution for enterprises that want to improve how they interact with their mobile workforce.

A special feature of this solution is that no “programming” in a traditional sense is required: no C/C++, no Java, no HTML.  Instead, I heard the solution described as “you fill in a spreadsheet” giving details of an existing paper-based system that you’d like to replace by a version that runs on mobile devices – a paper-based system for work orders, time cards, daily reports, punch lists, inspections, sales orders, and so on.  The architect and founder of JumpStart Wireless, Dr. Jeffrey Bonar, observed many similarities between systems used by different companies, and captured the similarities in the engine that lies at the heart of the JumpStart Wireless BusinessSuite platform.  The platform generates versions of the application that can run on a wide variety of different mobile devices.

Their website states:

Problem: Mobile Employees Typically Waste Hours Per Day With Paperwork and Communicating to Headquarters

Time and money wasted:

  • Driving to pickup/drop-off paperwork, filling out paperwork and excessive phone calls.
  • Chasing down missing paperwork, correcting errors and dealing with illegible paperwork.
  • Dealing with backlogs of completed work waiting to be closed out and billed.
  • Manually entering field data

Solution: JumpStart Wireless™ – One Tenth the Cost of Conventional Wireless Approaches

  • Leveraging JumpStart Wireless’s patent pending artificial intelligence technology, your customized wireless applications are one tenth the price of conventional approaches to wireless software.
  • Your forms and mobile employee process is automatically transformed into a wireless device application

Works with Normal Cell Phones and PDAs

  • JumpStart Wireless applications work on normal, off-the-shelf cell phones and BlackBerrys.
  • You do not need an expensive ($700-$2000), complex, custom device

2. The MoSync Mobile Development SDK

The MoSync Mobile Development SDK takes a different approach. It provides access to a wide range of underlying device functionality, via a C/C++ SDK.  As such, it requires a greater degree of software skill from the developer, and in principle can enable a rich variety of different kinds of application.

MoSync were one of the finalists in the Mobile Premier Awards at Barcelona, where I had the chance to meet a couple of their founding team.

Their website states:

Mobile cross-platform done right

Today’s mobile device market is more fragmented than ever.  New platforms are introduced every year.  Dozens of new devices arrive from manufacturers every month.  Sometimes it can seem that writing your application is the easy part: the real headache is tailoring it for all those different platforms and devices, and trying to keep up with the ever-changing marketplace.

We think that mobile application development is hard enough without having to worry about porting issues. That’s why we’ve created MoSync — a truly open-source solution for today’s fragmented mobile market.

MoSync’s fully-featured software development kit helps you develop anything from simple programs for basic mobile phones to advanced applications that exploit the full potential of the latest intelligent smart phones and mobile devices.

And with MoSync you can adapt, build, and package your application for hundreds of different mobile devices in a few clicks – all from the same code base! That means huge savings in development costs, faster time-to-market, and wider distribution and revenue possibilities…

Most approaches to cross-platform software development involve

  • either manual brute-force porting (in essence rewriting the application for lots of mobile devices)
  • or the use of virtual machine runtimes that need to be installed on the target devices.

MoSync does neither — instead it gives you the best possible solution: Symbian, Windows Mobile, j2me, Moblin, and Android built from a single source…

3. The Airplay platform from Ideaworks Labs

The Airplay platform from Ideaworks Labs has particular strengths for high-performance rich-media mobile applications – including graphically-intense mobile games.

Their website states:

Airplay is a native mobile application development and deployment solution that overcomes many of the major problems faced by developers and publishers of mobile games today.

The Airplay SDK comprises a set of powerful and extensible tools and technologies within a framework of processes and workflow best practices. This combination of technology and know-how delivers massive cost savings during both development and deployment and enables a much faster time to market.

This solution is the unique result of a 7-year symbiotic relationship between Ideaworks Labs and Ideaworks Game Studio divisions, and it is through building many of the most innovative mobile games in the world that our solution has been fine-tuned and thoroughly battle-tested.

Key Features:

  • Single Binary: Airplay combines the platform-specific execution environment implementation with a single binary for each game or application. The key advantage of this is there is no need to embed software on the handset, no dependence on manufacturing supply chain, or individual manufacturer or operator deals.
  • Open Platforms: All applications built using Airplay run on all “open” platforms, such as Symbian, BREW, Windows Mobile, Linux, and can be embedded on “closed” platforms, such as RTOS.
  • Scalable Graphics: Fully scalable graphics pipeline optimized to support all leading semiconductor architectures…
  • OpenKODE compliant: Ideaworks Labs was co-spec lead in Khronos on OpenKODE Core API, committed to standards-based portability of native applications.

4. EZMobile from 509inc

509inc have a solution which may appeal to developers who already have a web service, which they want to connect to mobile devices in such a way that it takes advantage of mobile device features such as location.

Their website states:

5o9 EZMobile uses Web standards to simplify development and the support of mobile users. 5o9 EZMobile works with existing Web servers, most HTTP mobile browsers and any network. 5o9 EZMobile can reduce the time and cost to mobilize by 2 to 10 times that of cross-platform mobile application development and support…

5o9 EZMobile software enables enterprise-level Mobile SaaS by delivering contextual data to your Web Apps. It provides a cost-effective alternative to cross-platform mobile application development.

Now you can extend your existing Web services to mobile users by leveraging the power of the Web. Your Web apps can access real-time who, what and where data about your mobile users, letting you personalize services via customized menu-based navigation. Standardize delivery, via the browser, across multiple mobile platforms. You determine the data you need. You control your data security and privacy  policies. You choose the appropriate level of personalization for your mobile employees, customers and partners.

Experienced cross-platform mobile developer Simon Judge recently looked more closely at 509inc and wrote some of his findings in a blog post “509 Bridges the App Web Gap“:

Last year I mentioned how 5o9 had developed a solution that allowed BlackBerry and Windows Mobile device location to be made available to web sites. Since then, things have progressed and they now offer a range of multi-platform tools for mobile developers.

5o9 told me that their view of the future is that for mobile to really take off the web has to know the end-user better. This means that web browsers need better access to phone features.

If you go to the 5o9 web site you can learn more. However, what it doesn’t say is how this technology works and how it might be integrated into your mobile solution, so I dug deeper

The 5o9 solution is a simple mobile application that can share critical meta data (without the need to type it in) with any web app in the world. It works by extending the HTTP protocol with new customizable HTTP_X headers….

Some people think that the future of mobile is the web. Until such time, technologies such as those offered by 5o9 can be used to bridge the gap.

This is just to scratch the surface…

Above, I’ve provided brief details of four attractive intermediate mobile platforms, but there are probably at least five times as many more that could be added to this list (I apologise for the highly selective nature of my list).

And that’s without covering the better known intermediate platforms such as Qt, Java, HTML5, Adobe Flash/AIR, and Microsoft Silverlight.  It would take a long time to fairly compare and evaluate all serious players in this space.

One conclusion that can be drawn from this multiplicity of offerings is that there’s wide perception of the need for such solutions, driven by the combination of two observations:

  • The mobile opportunity is huge, and demands attention
  • Mobile development is still generally seen as unnecessarily difficult.

26 November 2009

Forthcoming speaking engagements

Filed under: Bangalore, Cambridge, developer experience, openness, presentation — David Wood @ 8:50 pm

Cambridge Wireless, 3rd December

Next Thursday, 3rd December, I’ll be participating in a meeting of the Software & Open Source SIG (Special Interest Group) of Cambridge Wireless.  Cambridge Wireless is a community of companies in and around Cambridge with the following declared ambition:

Our objective is to establish Cambridge Wireless as the leading wireless community in the world and where we are at the leading edge of thought, leadership and wireless technology discussions

Symbian Software Ltd was one of the founding members of Cambridge Wireless, and the Symbian Software Ltd office on the outskirts of Cambridge hosted several Cambridge Wireless events over the years.  The ones I attended provided excellent networking and stimulating conversation.

Cambridge Wireless organise a series of SIGs – such as the one on Software & Open Source.  Next Thursday, this SIG will be gathering to review a set of presentations addressing the topic,

Open handset ecosystems – can they deliver handsets that consumers want?

My own presentation at this event has the title,

Open Ecosystems – a Good Thing?

Here’s the abstract for my presentation:

David will look at the various ways in which openness is changing the way that handsets are being developed through the use of open ecosystems, how developer ecosystems are transforming the way that applications and services are being created, and give his view on the impact of this on consumers. Openness brings challenges as well as triumphs. Done right, however, the open community approach will (over time) generate better solutions than any system of tight control – and consumers will reap the benefits.

The other speakers at the event will be:

  • Alberto Bonamico of Symsource – talking on “Adapting to the Open Source Ecosystem”
  • Andrew Savory of LiMo Foundation – talking on “Open Apps – Good, Bad or Ugly?”

There will be a panel discussion after the talks, with plenty of opportunity for Q&A from the floor.

Registration for this event is still open, via the Cambridge Wireless website.

Special thanks are due to Peter Montgomery of Ogma Solutions and Phillip Burr of Octymo, the champions of this SIG.

Forum Nokia Developer Conference, Bangalore, 7th December

The following Monday, 7th December, I’ll have the privilege to join another illustrious panel of speakers, at the Forum Nokia Developer ’09 conference in Bangalore, India.  This conference has the theme,

Unlock Star within you

(Anyone familiar with the UI on Nokia phones will appreciate the double significance of this name.)

As stated on the event website:

Unlock possibilities!

A world of infinite possibilities is waiting for you. It opens up when you press the Unlock Star keys of a mobile phone!

Discover the amazing new ways in which Mobiles are simplifying life, helping people to connect, communicate and access information at Forum Nokia Developer Conference ’09, the biggest forum in India for mobile application developers. See how everything anyone can imagine can be possible, at the touch of a fingertip and from the top of the palm.

Unlock Learning!

Get the right inputs, insights and network at Forum Nokia Developer Conference ’09. Access all the resources you will ever need to turn your ideas into reality. Get insights from industry leaders. Learn tricks and tips to create applications, faster. Explore the value OVI store has to offer to you as a developer. And more…

You and your mobile application is all it takes!

Your innovation can play a key role in shaping the future and enabling people. Create it to run on hundreds of millions of mobile phones and transform yourself into a global star.

Keynote speakers at this event include:

D. Shivakumar, Managing Director, Nokia Mobile phones and Vice President, Nokia

Purnima Kochikar, Vice President, Forum Nokia and Developer Community

On this occasion, I’ll be speaking on the topic

Winning habits of star developers

People interested to attend can register via the conference website.

15 December 2008

Symbian Signed basics

Filed under: collaboration, developer experience, operators, Symbian Signed — David Wood @ 9:19 am

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.

5 December 2008

All Carbide C++ editions are now free of charge

Filed under: Carbide, developer experience, Nokia — David Wood @ 2:35 pm

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.

3 November 2008

Mobile 2.0 keynote

Filed under: developer experience, fragmentation, integration, Open Source, vision — David Wood @ 11:32 pm

Earlier today, I had the privilege to deliver the opening keynote at the Mobile 2.0 event in San Francisco. This posting consists of a copy of the remarks I prepared.

The view from 2013

My topic is Open Source, as a key catalyst for Mobile Innovation 2.0.

Let’s start by fast forwarding five years into the future. Imagine that we are gathered for the 2013 “Mobile 2.0” conference – though the name may have changed by that time, perhaps to Mobile 3.0 or even Mobile 4.0 – and perhaps the conference will be taking place virtually, with much less physical transportation involved.

Five year into the future, we may look back at the wonder devices of today, 2008: the apparently all-conquering iPhone, the Android G1, the Nokia E71, the latest and greatest phones from RIM, Windows Mobile, and so on: all marvellous devices, in their own ways. From the vantage point of 2013, I expect that our thoughts about these devices will be: “How quaint! How clunky! How slow! How did we put up with all the annoyances and limitations of these devices?”

This has happened before. When the first Symbian OS smartphones reached the market in 2002 – the Nokia 7650, and the Sony Ericsson P800 – they received rave reviews in many parts of the world. These Symbian smartphones were celebrated at the time as breakthrough devices with hitherto unheard of capabilities, providing great user experiences. It is only in retrospect that expectations changed and we came to see these early devices as quaint, clunky, and slow. It will be the same with today’s wonder phones.

Super smart phones

That’s because the devices of five years time will (all being well) be so much more capable, so much slicker, so much more usable, and so much more enchanting than today’s devices. If today’s devices are smart phones, the devices of 2013 will be super smart phones.

These devices will be performing all kinds of intelligent analysis of data they are receiving through their sensors: their location and movement sensors, their eyes – that is, their cameras – and their ears – that is, their always-on recording devices.

They’ll also have enormous amounts of memory – both on-board and on-network. Based on what they’re sensing, and on what they know, and on their AI (artificial intelligence) algorithms, they’ll be guiding us and informing us about all the things that are important to us. They’ll become like our trusted best friends, in effect whispering insight into our ears.

We can think of these devices as like our neo neo-cortex. Just as primates and especially humans have benefited from the development of the neo-cortex, as the newest part of our brains in evolutionary terms, so will users of super smartphones benefit from the enhanced memory, calculation powers, and social networking capabilities of this connected neo neo-cortex.

In simple terms, these devices can be seen as adding (say) 20 points to our IQs – perhaps more. If today’s smartphones can make their users smarter, the super smartphones of 2013 can make their users super smart.

Solving hard problems

That’s the potential. But the reality is that it’s going to be tremendously hard to achieve that vision. It’s going to require an enormously sophisticated, enormously capable, mobile operating system.

Not everyone shares my view that operating systems are that important. I sometimes hear the view expressed that improvements in hardware, or the creation of new managed code environments, somehow reduce the value of operating systems, making them into a commodity.

I disagree. I strongly disagree. It’s true that improvements in both hardware and managed code environments have incredibly important roles to play. But there remain many things that need to be addressed at the operating system level.

Here are just some of the hard tasks that a mobile operating system has to solve:

  • Seamless switching between different kinds of wireless network – something that Symbian’s FreeWay technology does particularly well;

  • Real-time services, not only handling downloads of extremely large quantities of data, but also manipulating that data in real time – decompressing it, decrypting it, displaying it on screen, storing it in the file system, etc;

  • All this must happen without any jitter or delay – even though there may be dozens of different applications and services all talking at the same time to several different wireless networks;

  • All this rich functionality must be easily available to third party developers;

  • However, that openness of developer access must coexist with security of the data on the device and the integrity of the wireless networks;

  • And, all this processing must take place without draining the batteries on the device;

  • And without bamboozling the user due to the sheer scale and complexity of what’s actually happening;

  • And all this must be supported, not just for one device, but in a way that can be customised and altered, supporting numerous different form factors and usage models, without fragmenting the platform.

Finally, please note that all this is getting harder and more complex: every year, the amount of software in a top-range phone approximately nearly doubles. So in five years, there’s roughly up to 32 times as much software in the device. In ten years, there could be 1000 times as much software.

Engaging a huge pool of productive developers

With so many problems that need to be solved, I will say this. The most important three words to determine the long-term success of any mobile operating system are: Developers, Developers, Developers. To repeat: the most important three words for the success of the Symbian platform are: Developers, Developers, Developers.

We need all sorts and shapes and sizes of developers – because, as I said, there are so many deep and complex problems to be solved, as the amount of software in mobile phone platforms grows and grows.

No matter how large and capable any one organisation is, the number of skilled developers inside that organisation is only a small fraction of the number outside. So it comes down to enabling a huge pool of productive and engaged developers, outside the organisation, to work alongside the original developers of the operating system – with speed, creativity, skill, and heartfelt enthusiasm. That’s how we can collectively build the successful super smart phones of the future.

Just two weeks ago, the annual Symbian Smartphone Show put an unprecedented focus on developers. We ran a Mobile DevFest as an integral part of the main event. We announced new developer tools, such as the Symbian Analysis Workbench. We will shortly be releasing new sets of developer APIs (application programming interfaces) in new utility libraries, to simplify interactions with parts of the Symbian programming system that have been found to cause the most difficulty – such as text descriptors, two phase object construction and cleanup, and active objects.

The critical role of open source

But the biggest step to engage and enthuse larger numbers of developers is to move the entire Symbian platform into open source.

This will lower the barriers of entry – in fact, it will remove the barriers of entry. It will allow much easier study of the source code, and, critically, much easier participation in the research and creation of new Symbian platform software. We are expecting a rapid increase in collaboration and innovation. This will happen because there are more developers involved, and more types of developers involved.

That’s why the title of my talk this morning is “Open Source: Catalyst for Mobile Innovation 2.0”. The “2.0” part means greater collaboration and participation than ever before: people not just using the code or looking at the code, but recommending changes to it and even contributing very sizeable chunks of new and improved code. The Open Source part is one of the key enablers for this transformation.

Necessary, but not sufficient

However, Open Source is only one of the necessary enablers. Open Source is a necessary but not sufficient ingredient. There are two others:

  1. A stable and mature software base, with reliable processes of integration, which I’ll talk more about in a moment;

  2. Mastery of the methods of large-scale Agile development, allowing rapid response to changing market needs.

Fragmentation inside an operating system

Here’s the problem. Fragmentation is easy, but Integration is hard.

Fragmentation means that different teams or different customers pull the software in different directions. You end up, in the heat of development in a fast-moving market, with different branches, that are incompatible with each other, and which can’t be easily joined together. The result is that solutions created by developers for one of these branches, fail to work on the other branches. A great deal of time can be wasted debugging these issues.

Here, I speak from bitter experience. During the rapid growth days of Symbian, we lost control of aspects of compatibility in our own platform – despite our best efforts. For example, we had one version called 7.0s and another called 7.0, but lots of partners reported huge problems moving their solutions between these two versions. Because of resulting project delays, major phones failed to come to the market. It was a very painful period.

Nowadays, in the light of our battle-hardened experience, Symbian OS is a much more mature and stable platform, and it is surrounded and supported by an ecosystem of very capable partners. In my view, we have great disciplines in compatibility management and in codeline management.

The result is that we have much better control over the integration of our platform. That puts us in a better position to handle rapid change and multiple customer input. That means we can take good advantage of the creativity of open source, rather than being pulled apart by the diverse input of open source. Other platforms may find things harder. For them, open source may bring as many problems as it brings solutions.

Fragmentation across operating systems

This addresses the fragmentation inside a single operating system. But the problem remains of fragmentation across different operating systems.

Although competition can be healthy, too many operating systems result in developers spreading their skills too thinly. The mobile industry recognises that it needs to consolidate on a smaller number of mobile operating systems moving forwards. The general view is that there needs to be consolidation on around three or (at the most) four advanced mobile operating systems. Otherwise the whole industry ends up over-stretched.

So, which will be the winning mobile operating systems, over the next five years? In the end, it will come down to which phones are bought in large quantities by end users. In turn, the choices offered to end users are strongly influenced by decisions by phone manufacturers and network operators about which operating systems to prefer. These companies have four kinds of issues in their minds, which they want to see mobile operating systems solve:

  • Technical issues, such as battery life, security, and performance, as well as rich functionality;

  • Commercial issues, such as cost, and the ability to add value by differentiation;

  • Political issues, in which there can be a perception that the future evolution of an operating system might be controlled by a company or organisation with divergent ulterior motivations;

  • Reliability issues, such as a proven track record for incrementally delivering new functionality at high quality levels in accordance with a pre-published roadmap.

A time for operating systems to prove themselves

Again, which will be the winning operating systems, over the next five years? My answer is that is slightly too early to say for sure. The next 12-18 months will be a time of mobile operating systems proving themselves. Perhaps three or four operating systems will come through the challenge, and will attract greater and greater support, as customers stop hedging their bets. Others will be de-selected (or merged).

For at least some of the winning smartphone operating systems, there will be an even bigger prize, in the subsequent 2-3 years. Provided these operating systems are sufficiently scalable, they will become used in greater and greater portions of all phones (not just smartphones and high-end feature phones).

Proving time for the Symbian Foundation platform

Here’s how I expect the Symbian platform to prove itself in the next 12-18 months. Our move to open source was announced in June this year, and we said it could take up to two years to complete it. Since then, planning has been continuing, at great speed. Lee Williams, current head of the S60 organisation in Nokia, and formerly of Palm Inc and Be Inc, has been announced as the Executive Director of the Symbian Foundation.

The Foundation will make its first software release midway through the first half of 2009. Up till that point, access to internal Symbian OS source code is governed by our historical CustKit Licence and DevKit Licence. There’s a steep entry price, around 30,000 dollars per year, and a long contract to sign to gain access, so the community of platform developers has been relatively small. From the first Symbian Foundation release, that will change.

The source code will be released under two different licenses. Part will be open source, under the Eclipse Public Licence. This part has no licence fee, and is accessible to everyone. The other part will be community source, under an interim Symbian Foundation Licence. This is also royalty free, but there is a small contract that companies have to sign, and a small annual fee of 1,500 dollars. I expect a large community to take advantage of this.

This interim community source part will diminish, in stages, until it vanishes around the middle of 2010. By then, everything will be open source. We can’t get there quicker because there are 40 million lines of source code altogether, and we need to carry out various checks and cleanups and contract renegotiations first. But we’ll get there as quickly as we can.

There’s one other important difference worth highlighting. It goes back to the theme of reducing fragmentation. Historically, there have been three different UIs for Symbian OS: S60, UIQ, and MOAP(S) used in Japan. But going forwards, there will only be one UI system: S60, which is nowadays flexible enough to support the different kinds of user models for which the other UI systems were initially created.

To be clear, developers don’t have to wait until 2010 before experimenting with this software system. Software written to the current S60 SDK will run fine on these later releases. We’ll continue to make incremental compatible releases throughout this time period.

What you should also see over this period is that the number of independent contributors will increase. It won’t just be Nokia and Symbian employees who are making contributions. It will be like the example of the Eclipse Foundation, in which the bulk of contributions initially came from just one company, IBM, but nowadays there’s a much wider participation. So also for the Symbian Foundation, contributions will be welcome based on merit. And the governance of the Foundation will also be open and transparent.

The view from 2013

I’ll close by returning to the vision for 2013. Inside Symbian, we’ve long had the vision that Symbian OS will be the most widely used software platform on the planet. By adopting the best principles of open source, we expect we will fulfil this vision. We expect there will in due course be, not just 100s of millions, but billions of great devices, all running our software. And we’ll get there because we’ll be at the heart of what will be the most vibrant software ecosystem on the planet – the mobile innovation ecosystem. Thank you very much.

25 October 2008

"Symbian too old" – a mountain worth climbing

Filed under: Cringely, developer experience, E71, smartphones — David Wood @ 2:03 pm

In case I had forgotten how little mindshare Symbian has in many parts of North America, the recent Robert X. Cringely piece “Why Windows Mobile will die” contained yet another stark reminder.

As usual with Cringely, the piece mixes potential insight with a lot of conjecture and then some fancy. Most of the article discusses Windows Mobile, iPhone, and Android. But it squeezes in a dismissive paragraph about Symbian:

…donning flameproof clothing: Symbian is simply too old. The OS is getting slower and slower with each release. The GUIs are getting uglier and are not user-friendly. The development environment is particularly bad, which wouldn’t hurt if there weren’t others that are so much better. Symbian C++, for example, is not a standard C++. There is little momentum in the Symbian developer community, maybe because coding for Symbian is a pain. Yes, there are way more Symbian phones in circulation, but those phones will be gone 18 months from now, probably replaced by phones with a different OS. Lately, Symbian’s success has been primarily based on the high quality of Nokia hardware, on the loyalty of NTT DoCoMo, and now on the lure of being recently made open source and therefore free. But if open source developers don’t flock now to Symbian (they aren’t as far as I can see — at least not yet) then the OS is doomed.

And if that weren’t a sufficiently strong reminder of Symbian’s lack of mindshare, I found scant encouragement in the 65 comments posted (so far) to Cringely’s piece.

Allow me a few moments to respond to individual points in this paragraph, before I return to the bigger picture.

“Symbian is simply too old” – but it has been undergoing a constant internal renewal, with parts of the architecture and code being refactored and replaced with each new point release. Just a few examples: we introduced a new kernel in v8.1b, a new security architecture in v9.0, new database (SQL) architecture in v9.3, new Bluetooth in v9.4, substantially revised graphics architecture and networking architecture in v9.5, and so forth.

“The OS is getting slower and slower with each release” – on the contrary, many parts of the operating system are humming much quicker in the newer releases, as a result of a specific and pervasive focus on performance across the whole system. Deliverables include speed ups due to smart incorporation of demand paging, file system caching, data scalability improvements, and wider adoption of separation of activity into three planes (data plane, control plane, and management plane).

“The GUIs are getting uglier and are not user-friendly” – but the UI system is increasingly flexible, which allows customers to experiment with many different solutions (whilst retaining API compatibility). New developments such as the S60 Fifth Edition touch interface, and the recently announced support for Qt on Symbian OS, take things further in the user-friendly direction.

“The development environment is particularly bad” – but documentation and tools for Symbian OS have markedly improved over the last two years.

“Symbian C++, for example, is not a standard C++” – but watch out for our forthcoming annoucements about EUserHL that go a long way to address this particular gripe.

“There is little momentum in the Symbian developer community” – but that’s not the impression given by the media reports from people who attended the Symbian Smartphone Show last week.

“Yes, there are way more Symbian phones in circulation, but those phones will be gone 18 months from now, probably replaced by phones with a different OS” – but I beg to differ, based on my knowledge of development projects underway at phone manufacturers across the world. For just one example, consider the recent remarks from Li Jilin, Huawei Communications Vice President (note: Huawei has previously not been a user of Symbian OS):

“Huawei is excited by the plans for the Symbian Foundation. We look forward to participating in the work of the Symbian Foundation and using the foundation’s platform to deliver a portfolio of devices for mobile network operators around the world. We believe that the Symbian Foundation ecosystem will enable innovation which will benefit users and drive increased customer satisfaction.”

“If open source developers don’t flock now to Symbian (they aren’t as far as I can see — at least not yet) then the OS is doomed” – but this is far too impatient. It’s too early to make this judgement. You can’t expect the open source developers to flock to us before more plans are published for the roadmap to put our source code into open source.

As for the bigger picture: despite the above individual points of fact, I don’t expect significant changes in mindset (except among the far-sighted) until there are more Symbian devices in the hands of North Americans.

It was the amazing array of devices at the partner showcase stands at the Smartphone Show last week that caused the biggest buzz of all – bigger than the announcements from the keynote hall next door. Thankfully, AT&T have publicly mentioned their “plan to introduce more Symbian phones“. North American users shouldn’t have too long to wait. And there are encouraging signs of independently-minded North American writers actually (shock horror) liking the latest Symbian phones. For example, the renowned software essayist Joel Spolsky called the Nokia E71 “the best phone I’ve ever had – I’m loving it“.

In the meantime, the Symbian Foundation has a big mountain to climb, in public perception. But it’s a mountain well worth climbing!

9 October 2008

In search of software glamour

Filed under: developer experience, FOWA, passion — David Wood @ 8:51 pm

I keep running into the “glamour question”. Scott from Mippin raised it again the other day, in a shrewd comment in response to Roger Nolan’s recent analysis “Symbian’s open source challenge”:

I think that one inherent disadvantage for Symbian compared to Apple and Android is the glamour factor. This can be demonstrated by looking at the comments stream to this excellent post. If it had been talking about Apple or Android it would have people crawling over themselves to comment. Symbian just does not elicit the same excitement. This means – more meaningfully perhaps – that developers gain more kudos for developing for one of the glamour platforms than for Symbian (despite its market share).

Scott suggests that one reason for the reduced excitement over Symbian lies “the complexity of Symbian. It is just too complex and developers stay away“. Previously, I’ve offered my own list of “Symbian passion killers” that can hinder developers from becoming fully inspired (and therefore fully productive) about creating software for Symbian OS. As I’ve said before, the plans for “Symbian 2.0” in the wake of the creation of the Symbian Foundation include several important projects to address passion killers.

I heard quite a lot more, today, about developer passion. I was attending Day One of FOWA – the Future of Web Apps expo, taking place at London’s ExCeL conference centre. I experienced considerable déjà vu at this event, since the annual Symbian Smartphone Shows were held there from 2002 to 2007. The layout of the keynote hall and the so-called “university sessions” reminded me a lot of similar layouts from bygone Smartphone Shows. The audience seemed of comparable size too. But whereas the motivation of many who attend the Smartphone Show is to make business connections and to promote the success of their companies, the motivation I sensed from many of the FOWA attendees was rather different: it was to explore new technologies, and to exult in new products and new processes.

For example, Edwin Aoki, AOL Technology Fellow, included the following remarks in his keynote speech “Web apps are dead, long live web apps”:

What drives developers? It’s not just money. It’s building out communities. It’s building pride. It’s dedication and passion, not dollars and pounds.

And I couldn’t help noticing how frequently speakers used words like “amazing”, “exciting”, “awesome”, “kickass”, and “cool”. At first I wondered if they were joking or being ironic, but then I realised they were un-selfconscious. They were simply being enthusiastic.

Blaine Cook, ex Chief Engineer at Twitter, and Joe Stump, Lead Architect of Digg, performed a dynamic two-hander on the subject of “Languages don’t scale”. Taking turns, they ripped into features of programming languages that, in their words, made the languages “suck”. Thus “here’s why PHP sucks…” and “here’s why Ruby sucks…” and “Python sucks as well…”. But this was just a prelude to their main theme, which is that you should beware asking committed developers to switch from one language to another. Language choice is often personal – and often heartfelt. According to the speakers, scale performance issues that sometimes bedevil web applications, only rarely come down to language issues; instead, they usually depend on hardware architecture or network architecture. Hence the advice:

Value happy coders! Happy coders are productive coders. Let them work with the languages they love!

Many of the speakers oozed passion. I was particularly impressed by Francisco Tolmasky, co-founder of 280 North. His presentation title hardly sounded earth-shattering: “Building Desktop Caliber Web Applications with Objective-J and Cappuccino”. However, the delivery was captivating and uplifting. (And the technology of their product does look attractive…)

All this brings back to mind the glamour question: To what extent can Symbian’s developer events match this kind of enthusiasm – an enthusiasm driven by love of product and love of technology, rather than (just) love of market opportunity and commercial reward? To what extent can Symbian OS become viewed as glamorous and exciting, rather than just some kind of incumbent?

Happily, there’s a lot of fascinating technology on Symbian’s roadmap. There are also new tools that should appeal to various different kinds of developers. For those who value choice of languages, there’s a growing range of language options available for Symbian OS. For those who are interested in the hardware, there are literally scores of new phone models in the pipeline. Some of this will fall under public spotlight in under two weeks’ time at the 2008 Smartphone Show.

This year, the show has moved from ExCeL to Earls Court. The more significant change is that, this year, there’s a “Mobile Devfest” which is running alongside the main show:

Mobile DevFest is Symbian’s premier conference for developers and has been designed to provide developers with deep technical training and information on building mobile software solutions for the next generation of mobile phones powered by Symbian OS.

Mobile DevFest is the ideal developer event for anyone engaged in building, or interested in building mobile applications on Symbian OS.

Mobile DevFest is the best way to stay ahead of today’s mobile technologies. It provides in-depth technical sessions, delivered by industry experts in the mobile development space.

I’m eagering looking forward to taking part – and to gauging the degree of passion at the show. And in the meantime, if you think your own new product or solution for the Symbian space is particularly exciting, I’ll be pleased to hear about it!

26 July 2008

Naming the passion killers

Filed under: developer experience, fun, open phones, Symbian Signed — David Wood @ 6:06 pm

Passion makes a big difference. Posters all over Symbian premises (and on our websites) boldly declare that we “are at our best when we… love working for Symbian, drive to succeed, believe in ourselves, and take pride in what we do…“

That’s the Symbian description of the practical importance of passion. Along with people, collaboration, integrity, collaboration, and excellence, passion is one of Symbian’s six declared corporate values.

Like many other companies, Symbian each year carries out an internal employee satisfaction survey. The survey is conducted by an external agency, who provide us with information on how our results compare with broadly similar surveys held by other high-tech companies. In the most recent survey, aggregate Symbian employee views demonstrated strong Passion (80% positive rating). Of the six values, this one had the strongest support of all. The score also came in notably higher than the benchmark. In general, our employees enjoy working here, and put their hearts into their activities.

In some ways, “passion” is a longer word for “fun”. The good news is that, on the whole, Symbian employees enjoy and value their work. The bad news, however, is as I covered in my previous blog posting, “Symbian, just for fun“: many developers outside the company have a less positive feeling about working with Symbian OS software. They may persevere with writing Symbian OS software because their employer pays them to do so, and because of the somewhat attractive prospect of a share in a growing 200M+ unit market, but they often lack the kind of inner motivation and satisfaction that can put them into a super-productive state of “flow“.

The encouraging responses I’ve received to that posting (both via email and online) stengthen my view that it’s vitally important to identify understand the inhibitors to developer flow – the killers of Symbian passion. That’s a big topic, and I suspect I’ll be writing lots more on this topic in the months ahead. But let’s make a start.

Lack of clarity with Symbian Signed

The experience of my correspondent ilgaz is probably quite common:

I think the issue here is , we (even technical users) don’t really get what should be signed, what shouldn’t.

Ilgaz wanted to use a particular third party application (Y-Tasks by Dr Jukka), and thought that it would first need to be signed with a developer certificate. That proved to be an awkward process. However, it turns out that the application is ready to use (for many purposes) without any additional signing. So the attempt to get a developer certificate was unnecessary.

Some might say that Symbian Signed itself is intrinsically a passion killer. I disagree – as I’ve argued elsewhere. But what does kill passion here is the confusion about the rules for Symbian Signed. You can’t expect flow from confusion. I see six causes for this confusion:

  1. Different devices implement Symbian Signed in different ways. Some devices helpfully support a setting to allow the installation of self-signed apps, as well as Symbian Signed ones. Others do not;
  2. Different operators have different views about what kinds of applications they want to allow on their phones;
  3. The subject of permissions for the different capabilities of different pieces of software is intrinsically complex;
  4. The operation of Symbian Signed has changed over time. It’s great that it has improved, but some people still remember how it used to work, and that confuses them;
  5. “Once bitten, twice shy”: past bad experiences sometimes over-colour present views on the topic;
  6. A small number of people seem to be motivated to spread particularly bad vibes about Symbian Signed.
In this situation, we can’t expect to reverse all the accumulated mistrust and apprehension overnight. But the following steps should help:
  • Continue to seek to improve the clarity of communications;
  • Be alert to implementation issues (eg an overworked website – as experienced some months back) and seek to address them quickly;
  • Avoid a divergence of implementations of different application approval schemes by different network operators.
It’s my profound hope that the attractive statements of common aims of openness, made by the various parties supporting the Symbian Foundation, will translate into a unity of approaches towards application approval schemes.

Lack of reprogrammable devices

Another correspondent, puterman, points out:

Getting people to develop apps just for fun is one thing, but getting them to hack the actual OS is another thing. For that to be of interest, there have to be open devices available, so that the developers can actually see their code running.

I agree with the importance of quick feedback to changes made in your software. If you change the lower levels of the software, you’ll need to be able to re-program an actual device.

The Linux community shows the way here, with the Trolltech Greenphone and the FIC OpenMoko Neo1973 and FreeRunner devices. It’s true that there have been issues with these devices. For example, Trolltech eventually discontinued the Greenphone, and the FIC devices have proved quite hard to purchase. However, as the Symbian Foundation software becomes increasingly open source, we can reasonably expect the stage-by-stage appearance of phones that are increasingly end-user re-programmable.

Lack of well-documented API support for “interesting” features of a phone

Marcus Groeber makes a series of insightful points. For example,

One of the main things mobile developers would want to do is make use of the unique features of a mobile phone (connectivity, built in camera, physical interaction with the user). However, it is those area where documentation is still most patchy and API support is erratic (CCameraAdvancedSettings anyone?).

In my view, this aspect of mobilie development should be acknowledged to a much greater degree, and the documentation efforts focused accordingly: If there is a feature in a built-in app of the phone, chances are that a developer will want to try and improve on that. Can s/he?…

I believe that these moments of frustration – finding an API that looks useful in the SDK docs, then spending an evening writing an application that uses it, only to get KErrNotSupported in the end – is probably among the chief reasons for people abandoning their pet projects…

True, many “fun” programmers (me included) don’t want to wade through tons of documentation and whitepapers before writing their first proof-of-concept – but to me this makes it even more important that the existing documentation is streamlined, accurate and compact.

Improving our developer documentation remains one of the top-priority goals at Symbian. In parallel, we’re hoping that additional publications from Symbian Press (and others) will help to guide developers more quickly through the potential minefields of APIs for the more interesting functionality. The book “Quick Recipes on Symbian OS” (which I mentioned at the end of an earlier posting, “Mobile development in a hurry“) is intended to address this audience.

Of course, as Simon Judge points out, sometimes it’s not a matter of improving the documentation of existing APIs. Sometimes, what’s required is to improve the APIs themselves.

API awkwardness across the UI-OS boundary

The last passion-killer I’ll mention for now is another one raised by Marcus Groeber:

most of the “interesting” bits of developing for devices actually come from the licensee’s layers of API (in my case, mostly S60), and I believe it is here where there is most work to be done, as well as the interface between the two…

The ad-hoc-ish nature of the S60 UI, which seems to require a lot of experimenting and guesswork for developing even very simple screen layouts that mimic closely what is already present in the phone in dozens of places. Even after years of development, I still consider the CAkn and CEik listbox classes a jungle.

As one of the original designers of the CEik listbox class hierarchy (circa 1995-6) perhaps I should keep my head low at this point! (Though I can claim little direct credit – or blame – for the subsequent evolution of these classes.)

However, the bigger point is the following: both Symbian and S60 have recognised for many years that the separation of the two software development teams into two distinct companies has imposed drawbacks on the overall design and implementation of the APIs of functionality that straddles the two domains. Keeping the UI and the OS separate had some positives, but a lot of negatives too. Assuming the acquisition by Nokia of Symbian receives regulatory approval, the resulting combined engineering teams should enable considerably improved co-design. The new APIs will, hopefully, inspire greater fascination and approval from those who use them!

Older Posts »

Blog at WordPress.com.