20 December 2009

Integration is hard

Filed under: integration, Linux — David Wood @ 5:29 pm

One phrase which I’ve uttered on numerous occasions in the last two years is,

Fragmentation is easy, integration is hard

Recently, I’ve taken to putting more emphasis on the “integration is hard” part of this phrase.  I keep seeing evidence, everywhere I look, of the importance of skills and systems that allow different variations and innovations to be easily incorporated back into wider systems.  A new technology, by itself, is generally insufficient to make an impact in society.  Lots of time-consuming system changes need to happen as well, before that technology can deliver “end-to-end” results.

In a small way, I’ve been seeing more evidence of this same point in the last few days, as I’ve been struggling to assemble a system of software to support a new application.

The application I’d like to support is the “IdeaTorrent” that powers, among other things, the Ubuntu Brainstorm site.

This software is an open source (free of charge) implementation of a voting and review system for ideas.  I’d like to provide a version for my own purposes.  The Ubuntu site helpfully has a link to the providers of the software, IdeaTorrent.

In principle, the installation instructions look simple enough:

  1. Use a webserver with PHP installed
  2. Install the database software PostgreSQL (v8.3)
  3. Install Drupal (content management software)
  4. Install IdeaTorrent
  5. Do some configuration.

In practice, things are proving tougher.  The word “however” appears quite a few times in what follows…

The first webserver I obtained had a different database installed, MySQL.  Although I heard from many people that, by various criteria, MySQL is preferable to PostgreSQL, the IdeaTorrent installation notes were clear that the system would work only if PostgreSQL were present.

However, with this webserver, I failed at the first hurdle.  I found I couldn’t install any new software, since it was a “shared” server that other people were using too.  That environment (not unreasonably) prohibited any user from gaining “root access” security permissions.  If I wanted to change the components, I would need a different working environment.

I therefore purchased a more expensive hosting system.  (I am hopeful of a refund for the first one – from the same supplier, GoDaddy).  This system does allow installation of new software.  And, to make things easier, it comes with PostgreSQL already installed.  That took me to the task of installing Drupal.  That task ended up taking me more than 24 hours elapsed time, as I went along a crash learning course about Linux file permissions, the BASH command shell, PHP, and Drupal itself.  So far, so good.

Finally I installed IdeaTorrent, and reconfigured Drupal so that it recognised the IdeaTorrent modules.

However, lengthy error messages started getting displayed.  Various functions were missing, so the system would not work.  The functions in question were meant to be supplied by PostgreSQL.  At this stage, I paid more attention to the part in the IdeaTorrent installation instructions that said “PostgreSQL 8.3 (Important! Won’t work below 8.3)”.  On checking, I found out that the system provided by GoDaddy has PostgreSQL 8.2.9.

8.2.9 looks numerically close to 8.3, but clearly it’s not close enough.

Further investigation showed me that Linux has an impressive looking system for assisting with upgrades of components.  I followed instructions that I found spread out over the Internet – including the quaintly titled article “An Almost Idiot’s Guide to PostgreSQL YUM“.

These instructions let me to downloading a small “.RPM” file onto the server, and then invoking a command called “YUM“.  (Apparently YUM stands for “Yellowdog Updater, Modified”!)  It looked like it was working.

However, when I started up the system again, I saw that the version of PostgreSQL that was running was still 8.2.9.

Another 24 hours elapsed – with lots of red herrings along the way.  I eventually realised that some of the online links had misled me to pick the wrong .RPM file.  (The one I was trying to install was actually, despite appearances, an even older version.)  Finally I found the right file.  This time, when I ran the YUM magic, lots more things happened.

However, these changes broke the admin “control panel” interface when GoDaddy provided, in order to administer databases.  Without this interface, the remainder of the installation (as required to set up Drupal) would probably be impossible.

Not for the first time, I went back to square one (GoDaddy have a handy service whereby they will return the whole system to its inital “provisioned” state).  This time, I was more careful in how I did the upgrades.  This time, the control panel interface kept working fine.

However, this time, although the functions were shown whereby I could administer the databases, the functions all told me:

Admin password is out of sync. Database management will be unavailable until the admin password is changed.

However, everything I try to do to enter (or redefine) the “admin password” fails.  My current guess is that the handling of admin passwords somehow changed between PostgreSQL v8.2 and PostgreSQL v8.3.

At the moment, I’m stuck again.  Perhaps I’ll figure out what password I ought to be typing in.  Or perhaps I’ll have the whole system reprovisioned yet again (for about the fifth time) and do the upgrades even more carefully this time.  (Any advice from readers of this blog will be gratefully received!)

I see my trials and tribulations of the last few days as an example of how it’s hard to alter individual components of a complex software system.  These components can have all kinds of dependencies on each other – explicit dependencies, implicit dependencies, data format dependencies, obscure dependencies, bug dependencies, and so on.

My takeaway isn’t to assign any blame to any particular system.  My takeaway is that:

  • Anyone planning to alter components in a complex software system should set aside plenty time to debug integration issues that arise along the way;
  • Anyone embarking on such an endeavour should be ready to call in expert advice from people who have significant prior experience in that same task.

Indeed, integration is hard.  However, that’s a reason for all of us to design systems that are “integration friendly”.

Added later

Since writing this blogpost, I’ve now understood why the “control panel” phpPgAdmin application was failing to accept passwords, and the problem is solved.

It turns out that a clean installation of PostgreSQL specifies (via the file pg_hba.conf) that user access is checked via an “ident” (identification) system that does not use passwords.  General advice is that this should be changed to use passwords instead.  Changing the word “ident” to “md5” in the above-mentioned configuration file does the trick – and phpPgAdmin is now working for me again.

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.

23 June 2008

Fragmentation is easy, integration is hard

Filed under: Android, fragmentation, integration — David Wood @ 2:13 pm

The Wall Street Journal reports today that “Google’s Mobile-Handset Plans Are Slowed“. The Inquirer picks up the story and adds a few choice morsels of its own: “Depressing news as Google’s Android delayed“:

However, life’s little crises just kept getting the Android down and now apparently some mobile network operators like Sprint Nextel, have abandoned any attempt to get an Android on the market until 2009. This is purportedly because the majority of Google’s attention and resources have been going to Sprint’s competitor T-Mobile USA, who still hope to have an Android mobile out by the end of Q4. We have it on good authority (from un-named sources of course) that Sprint actually asked Google “Do you want me to sit in the corner and rust, or just fall apart where I’m standing?”…

Director of mobile platforms at Google, Andy Rubin, gloomily noted that trying to develop software while the company’s irritating partners kept pushing for new features, was a time-consuming task. “This is where the pain happens”, he sighed.

I recognise this pain. It’s something that has occurred many times during Symbian’s history. That’s why I’ve emphasised a dilemma facing Android: Fragmentation is easy, but integration is hard. Coping with multiple forceful customers at the same time, while your codebase is still immature, is a really tough challenge. Glitzy demos of v2 features don’t help matters: they drive up interest that needs to be deflated, as you have to explain to customers that, no, these features aren’t ready to include in the software package for their next phones, despite looking brilliant on YouTube. Instead, the focus needs to go on the hard, hard task of integration.

Blog at WordPress.com.