Wednesday, December 30, 2009

Maemo, Symbian and Qt are facing internal strife; what was supposed to bind them is tearing them apart

Maemo, Symbian and Qt are facing internal strife; what was supposed to bind them is tearing them apart

By Stefan Constantinescu on Wednesday, December 30th, 2009 at 11:53 AM PST In Linux, Nokia

nerds Maemo, Symbian and Qt are facing internal strife; what was supposed to bind them is tearing them apart

When Nokia acquired Trolltech in January 2008 they outlined a clear strategy that they would build a Qt layer on top of both Maemo and Symbian

so that developers could create applications that would be cross platform compatible:

The acquisition of Trolltech will enable Nokia (NYSE: NOK) to accelerate its cross-platform software strategy for mobile devices and desktop applications, and develop its Internet services business. With Trolltech, Nokia and third party developers will be able to develop applications that work in the Internet, across Nokia’s device portfolio and on PCs. Nokia’s software strategy for devices is based on cross-platform development environments, layers of software that run across operating systems, enabling the development of applications across the Nokia device range. Examples of current cross-platform layers are Web runtime, Flash, Java and Open C.

But something has gone awry. Mark Wilcox, currently an employee of the Symbian Foundation, formerly a Nokia employee, chimed in on a Maemo.org thread discussing Maemo 6, Symbian^4 and Qt and how they’re going to lose compatibility when they hit the market. His 1300+ word missive is too long to copy and paste, but his main point, which he repeats several times, is made in this paragraph:

The very concept that Maemo and Symbian (via Orbit – currently being renamed Symbian^4 UI framework) should build new UI frameworks on top of Qt, which is supposed to be a cross-platform application and UI framework should have set alarm bells off everywhere! When you consider that Qt is owned by Nokia, along with Maemo and almost all of the Symbian development teams

– it seems almost inexcusable that there should be any framework built on top of Qt. However, given that there could be a desire to preseve the quality of Qt by not expanding the team working on it too fast or diluting the quality of the engineers, and at the same time a business need to build some products on top of the technology, you might be able to excuse a common set of widgets etc on top of Qt for mobile devices. Unfortunately two separate sets is just insane and WRONG, WRONG, WRONG!

He goes on to say that the decision to build a Maemo specific flavor of Qt and a Symbian flavor of Qt was made to reduce job cuts and to purposefully separate the platforms from day one so that there can be some separation between the Symbian and Maemo product lines. Quim Gil, Nokia’s spokesperson for all open source

and Maemo related topics, immediately responded to Mark’s remarks by stating that:

I still believe this discussion will be more useful when we have concrete SDKs and platform releases to compare. The day someone comes pointing to duplicated, pointless or missing features then we will be able to have a proper technical discussion.

In the meantime we must play this game where you are the apocalyptics and we are the integrated, when actually the picture is more interesting than that.

Note that this multiparty exercise (that includes you) has a chance of big success precisely because the setting is more wide and diverse. This is one of the reasons why I think I’m working in the right platform and in the right direction, even if the story is not always as simple to explain as I’d wish.

Mark responds, and then Quim does, rinse and repeat. What we’re seeing here is different parts of the organization struggle to prove that they’re right and the other one is wrong. One of Mark’s rebuttals is:

It can only be concluded that politics has trumped technical strategy and pragmatism in this process.

Politics is a huge thing at Nokia, and I know this from personal experience. The top down management style make people seek friends in senior positions to champion their projects and ignore others. With Symbian, Maemo and Qt all open source now one would think that these obstacles would be a thing of the past, but really they just intensify since there are now even more chefs in the kitchen.

With regards to products and why things like this matter, people ask me: why I don’t like the N900? Besides the fact that it is huge, heavy, and made out of plastic, Nokia essentially said that in less than a year they’re going to ship a Maemo 6 powered device that has multitouch capabilities and does everything better than the N900 does things today. Nokia also has a track record of releasing new Maemo devices, with new Maemo software, and cease supporting last generation hardware. I don’t buy products that last less than 1 year. What happens when Symbian^4 and Maemo 6 devices start shipping and the cross platform promise that Nokia not only made, but purchased a company who could help them make that promise a reality, fails to materialize?

Google (NSDQ: GOOG) is facing the same problem with Android. That’s partially their fault since they’re cranking out so many versions of Android every year, and partially the fault of handset manufactures who stop supporting a device once it hits the market. Apple (NSDQ: AAPL) has made the best effort out of everyone to keep the iPhone OS experience the same across multiple generations. Yes, it’s easy to do that when you only ship 1 device (different colors and storage capacity doesn’t count), but it’s impressive none the less than people who purchased the very first iPhone in June 2007 are able to upgrade to the latest version of the iPhone software (3.1.2) which was released only 2 months ago.

One thing is for sure, the future winners will be those that can get their software right and Nokia looks like they’re experiencing a bumpy ride.

[Hat tip to @andreascon]

Share this:
  • Digg

  • Facebook

  • StumbleUpon

Posted via web from rain13r's posterous

No comments: