23 July 2008

Symbian, just for fun

Filed under: CIX, developer experience, fun, OPL, Python — David Wood @ 9:21 pm

“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.


  1. As someone who has done Symbian development commercially since 2002, and does actually get some fun out of it, though admittedly more often from seeing my application run on a mass-market device rather than from the act of writing code itself – a few moments of awe about the design of the Symbian class libraries notwithstanding, here is my 0.02 (euro)cents of ranting:

    One thing that I believe gets in the way of Symbian “for fun” programming very much is the frequent lack of “instant gratification” – in practice, whenever I tried to embark on some parallel “fun” projects of my own, there were always some stumbling blocks before there was anything truly impressive to show for. And this was for someone with an All-TCB certificate, occasional Platinum Partner and FN Pro access, and years of experience.

    However, I think not all of the blame for this should be laid at Symbian’s door – 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.

    I believe there are two main factors contributing to this:

    – 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.

    – The lack of API support for “interesting” features of a phone. 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?

    As a practical example, I considered two “fun” projects in recent months, both of which fell through due to lack of the necessary APIs in S60:

    – A monitor for prepaid charges that periodically uses USSD to query the balance. Failed due to lack of an API for cleanly intercepting USSD responses, and due to high capability requirements even for what is there.

    – A camera app for rapidly taking bracketed shots for HDR composition. Failed due to lack of documentation (and probably functionality) for setting exposure compensation values in the camera API.

    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.

    As a C++ developer, I personally don’t believe that the answer to this lies only in adding more parallel runtime environments (Widgets, Python, Ruby, Flash, Java), since many of these still end up being constrained the underlying “native” APIs and/or never quite achieve parity with native apps in usability terms.

    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 – for example, releasing several SDK updates over the years with the same incorrect documentation, while at the same time trying to paper over the cracks exclusively with FAQs and Knowledge Bases without the commitment to ultimately fixing the base document itself.

    ciao marcus

    Comment by mgroeber — 24 July 2008 @ 8:33 am

  2. I completely agree that as Symbian goes open source, you need developers who want to hack it “just for fun”. However, I would add PlatSec/Symbian Signed to the list of items that often criticized about Symbian development.

    In my oppinion its an often misunderstood technology+process so some of the criticisms you read are just plain wrong. Having said that, there is no doubt that it is an extra hurdle for developers and in some cases a time-consuming or even costly one.

    I think it’s a necessary and perhaps even desireable system to have but it is also something that is quite alien to developers from other open-source platforms and could therefore be a turn-off for them.

    Comment by James — 24 July 2008 @ 8:38 am

  3. 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.

    Comment by puterman — 24 July 2008 @ 5:11 pm

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Blog at WordPress.com.

%d bloggers like this: