Ambushed

The invitation made good sense to me:

Apologies for the short notice but are you free tomorrow afternoon [Friday] after 3pm to meet with us to provide your feedback on MWC please? It should only take 30 mins or so.

It would be a chance to discuss with the Symbian Foundation marcomms team my reflections on our activities at the Mobile World Congress event in Barcelona the previous week: what had gone well, where there was room to improve, what we should try to do differently at future events, and so on. As a big fan of the practice of retrospection, I was happy to carve out 30 minutes in my diary for this purpose.

As I climbed up the stairs to the first floor of #1 Boundary Row - where the marcomms team sits - I briefly rehearsed my thoughts. I had many positive recollections of how everyone had prepared for and then supported the Symbian Foundation presence at Barcelona. (My main negative observation was that the music in the party was, at times, a bit too loud, and impeded networking conversations.)

But when I came into the room, Anatolie Papas asked me to review a press release. I could see there were lots of quotes on it. Then I noticed the title of the release:

DW 2.0 TURNS 5.0

SLIGHTLY BELATED BIRTHDAY PRESS RELEASE FOR IMMEDIATE DISTRIBUTION!

The man who helped put the ‘smart’ in ‘smartphone’ celebrates his half century and becomes a friendly spaceman

and I realised I was being ambushed - but in a very pleasant way!

Then a cake materialised, magnificently decorated with what is becoming an increasingly familiar picture:



A knife and forks appeared, and we collectively set to dividing up the cake and eating it. It was particuarly yummy! (The marcomms team get the credit for the design of the cake, but the manufacture was apparently by Konditor and Cook.)

The endorsements on the "press release" left me (unusually) lost for words. I won't repeat the endorsements here - that would be far too indulgent - but I do nominate Bruce Carney (from Symbian's Foster City office) as the provider of the geekiest quote:

“Congratulations on your 0x32nd birthday and thank you for your tireless contribution to get Symbian to where it is today; ready for the most exciting decade in all of our lives; the 'Internet without wires'”, said Bruce Carney, Symbian^h^h^h^h^h^h^h Nokia.

The upbeat creativity that shone through this "press release" gives me all the more reason to be confident that this team will continue to devise and deliver suberb market communications as the rest of the Symbian Foundation accelerates into top gear over the months ahead.

Naming the passion killers

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!

Symbian, just for fun

"There are two kinds of OSS developers: the guys who do things for fun, and the guys who do OSS because they are paid to do so. In order for an open source project to really flourish and take over the world, you need both."

These comments were made a few days ago by Janne Jalkanen of Nokia, speaking in a personal capacity. I think Janne is competely right. My own view is that the only reliable way for the Symbian Foundation software to become the most widely used software platform on the planet, is if that software also becomes the most widely liked software platform on the planet.

The two kinds of OSS developers aren't completely distinct. Ideally the ones who are paid by their company to work on the software should also have a strong inner desire to do that work - to go the extra mile out of the sheer enjoyment and fascination they get from that software.

I've seen that kind of deep enthusiasm for software many times in my life. I first ventured onto online community discussion groups in the early 1990s, using the login name "dw2" on the CIX (Compulink Information eXchange) bulletin boards. The Psion devices of that time - running a 16-bit precursor to Symbian OS - could be programmed using an interpreted language called OPL. Hobbyists made increasingly creative use of the possibilities of that language, creating some highly impressive games, serviceable business applications, alternative personal information management functionality, and lots more besides. I was drawn into providing support and encouragement to this burgeoning community. Plucking an example at random from September 1992 from my archives, here's a reply I posted to someone who had been pushing the envelope of OPL functionality:

Access to C routines from Opl

I don't suppose it'll cause any harm to pre-announce something that Psion will shortly make available to Series3 Opl programmers. Namely a mechanism to access functionality written in a C library, from Opl. What will be possible is as follows:

• Someone provides some C functionality in a so-called DYL library
• Opl programs can hook into this functionality by means of the LibSend operating system service (CALL ($cf)).

Psion will make some suitable DYLs available, and it will be up to third parties to provide other general or specific DYLs. For example, in a hypothetical company writing software for the S3, out of a team of say six programmers, only one would need to understand C. All routine coding could be done in Opl, with only the performance-critical parts being done in C (together with a few parts that are technically out of the reach of pure Opl).

Even before you (BobG) raised this subject, Psion were working on a specific DYL to quicksort the index of a DBF file.

Regards, DavidW

That was 1992, when many enthusiasts were happy to while away their free time programming devices powered by EPOC16. Fast forward again to 2008. Janne goes on to say,

The problem with Symbian is that very, very few people touch it for fun. So I believe that while we can open source it, it is going to be very difficult to get people participate out of their own free will, unless we are prepared to make very serious refactorings to the entire system.

My first instinct is to disagree with Janne here. I'd love to list lots of people I know who do seem to enjoy developing Symbian software, "just for fun". For example,

• Python on S60 can be a real joy to use - and supports lots of extensions. (In many ways, Python is for Symbian OS in 2008 what OPL was for EPOC16 back in the 1990s.)
• The forthcoming new Symbian graphics architecture ("ScreenPlay") and IP networking architecture ("FreeWay") are full of interesting software development opportunities
• The PIPS libraries hide away many of the idiosyncracies of native Symbian C++ development, and can increase the pleasure of porting certain types of applications to Symbian devices.

However, as Mike Rowehl rightly reminds all would-be Symbian blogging enthusiasts - like me! - the first duty of a blogger is to listen, rather than to speak:

I’m not saying that Nokia doesn’t have market share, I’m saying they don’t have developer mindshare and they haven’t captured the attention of new entrants. How often do you hear about people “fooling around with developing for Symbian” just for fun in their free time? I’ve attended developer focused events in a number of different areas and I’ve heard that very infrequently. Compare that to the number of times you run across people fooling around with iPhone or Android SDKs (or even Maemo for that matter). I’m filtering out all the Silicon Valley events cause we’re weird over here. But even of events in others areas - developers area paying way more attention to the other platforms. You can argue that all you want but it won’t go away, I’m just telling you what I hear. Do with it what you want. If you want to deny it though, you’ve already lost really.

And I can't deny that, as I search through the blogosphere and developer forums, I find the number of postings that are negative about the the developer experience of Symbian and S60 kits significantly exceeds those that express heart-felt enjoyment with the experience. As much as I can find reasons to discount individual postings, I can't discount the overall weight of comments by such a diverse group of writers.

So all I can say is the following:

• I see lots of API improvement projects inside the Symbian labs - such as the experimental forthcoming ZString class alternative to text descriptors, and the proposed RAll utility classes for simplified resource management - which should be warmly received by a wide audience
• I believe Symbian's developer tools and documentation have improved significantly over the last few years, and are continuing to make big leaps forward (but the impressions some developers hold towards these topics is unduly negatively coloured by their past bad experiences with older tools or documentation)
• A more transparent approach to planning and experimentation inside Symbian's development halls - as befits a switch to open source development - will generate more good ideas (and even some good will...)
• Experimentation and quick starts on Symbian development projects will become easier.

(I also believe, by the way, that developers' enthusiasm for their experience on other platforms will decline, unless these other platforms learn to cope with some hard disciplines like binary compatibility and SDK quality control, as their market success grows. For related comments, see "The emperor's new handset".)

I close by making a commitment: improved developer experience will be central to the goals of the Symbian Foundation. If the number of people who develop for Symbian "just for fun" doesn't increase substantially, the Foundation will have failed in its objectives.