jump to navigation

MeeGo – some feedback and thoughts February 15, 2010

Posted by Florian in Devices, Linux, Maemo, MeeGo, OpenEmbedded, Source.
trackback

I only had a very few free minutes today I was able to spend following the discussions and reading released information about MeeGo. For some reason the most intensively discussed fact among the community members  seems to be decision to use the RPM package system. This one is followed by the Qt vs. GTK+ discussion I cannot remember when it started but I still remember it even started before I wrote the first line of open source code :-)  I have seen a lot of questions about currently existing devices (N900 mostly) and software –  if they are likely to become supported in future MeeGo releases – at least for the N900 and Maemo 6 there is a statement by Ari Jaaksi already. The other technical questions… well, in an ideal world these should not even be relevant for the developers because there would be the perfect tools that create the packages you want and assist you to create user interfaces without thinking much about the toolkits you  use. Again – this is the theory – we all know that the real life for development is quite different. But in the end or customers / users will decide which platform and with this which applications they are going to use. Users will not care about the package format used in the platform or the toolkit that is used by some application. In fact many (mostly Linux/Unix based) platforms do not expose the software package file format to an average user any more while some quite popular ones still do (e.g. Symbian and Windows). For users the availability of a consistent and widely used software platform with a high amount of available applications is likely to be the most important criterion. Ok, I admit that the availability of sexy hardware is quite important too :-)

Way more interesting than technical details is to look at the landscape of mobile device software stacks and to place MeeGo in it. So how does this landscape look like now?

  • There is Apple with the iPhone – pretty much closed but many developers and sexy hardware but quite limited amount of devices and only one manufacturer.
  • Symbian – well established with a large community but it feels like it hits its limits with modern smartphones.
  • Samsung just launched Bada which looks quite interesting but does not yet seem to have a large community of developers and users.
  • Microsoft Windows Mobile is available for many years now but seems to have lost attraction over the years.
  • Palm WebOS is interesting from both developer and user point of view but I think it will be hard for it to compete with all the major players in this area.
  • Google developed Android which enjoys a fast growing user- and developer base. It’s easy to get started with Android and there is a wide range of interesting devices available already. It is quite portable since most of the lowlevel components are open source.

Among these the most likely candidate to play the dominating role in the mobile handset market might be Android. At least this is how things look like right now… we all know this market changes pretty fast and you never know what happens next. I think Nils asked the question quite a few of us asked themselves: Will MeeGo become a kind of “Android killer”?

No way I will comment on this but in order to become a more generic platform MeeGo needs to focus on different things Maemo did so far. So far Maemo was focused on supporting a very few devices and contained quite some specialized bits that only worked for the Maemo specific devices and its distribution. I still remember that getting basic support for building the Maemo software stack with OpenEmbedded caused some headaches and sleepless nights. (I was mentor of a GSoC project working on this – just take a look at Kirtika’s blog to find out some details.)  It is good to see that it is quite obvious that MeeGo folks understand that these things will have to change. A good example is the process how to get some hardware supported. For someone like me supporting various device makers the really interesting part will follow: How will the device makers adopt MeeGo and how many of them will ‘jump onto the MeeGo boat’? Having more hardware vendors supporting MeeGo means more users and meant to make the platform more interesting for developers. And gaining interest from developers and users is absolutely vital for any software platform that is going to play a major role in future.

In my opinion there is a lot of potential in MeeGo – the most important one is the fact that the key components are going to be open and portable. The project joins two (comparably small) developer and user communities and combines this new community with the support by two very successful companies. I can imagine that this base is able to attract quite some more valuable contributors like smaller device makers, software companies and open source projects.

I’m pretty sure that ‘The Big Merge’ is going to cause quite some movement in the mobile device landscape…

Comments»

1. Jerome Haltom - February 16, 2010

I think I’m about two years past the point where I write off both projects as lacking any relevance. Few products here and there, which may be cool, but are largely eclipsed by their competitors in months.

No market position whatsoever. Technically interesting, but they appear to just be a money sink for their participating companies. This is product development driven by engineers at it’s finest.

I love being an engineer, of course. I just think I know when to switch hats.

Just contrast two approaches here. Android’s and Moblin/Maemo/MeeGo. Google announces Android products. Shipping. With things people care about. With marketing. With advertisements. The others announce new SDK versions and source code merges, and largely bicker about whether they’re going to use Gtk or Qt. RPM or DEB. And then switch between the two.

Sure. Android is obviously not ideal. It’s obviously not a pure super-cool open development environment. But it’s shipping. It’s making money. That guarantees it’s continued existence. If somebody can make a case about whether the number of devices shipped by using Rpm is greater than the number generated by using Deb, sure. Same situation for Gtk/Qt. But there is no compelling case. Frankly either would be fine. Few people who would pay for the devices care. But then the existing work gets trashed to switch. WTF?

And this saddens me. Because I would really love one of these devices as my primary mobile device.

Andreas - February 16, 2010

Yeah, I don’t think you’re wrong, generally. But consider this: If a platform is supposed to be open it is impossible to present it in finished form to the world, with devices or not. The established platforms are pretty good so it takes big improvements to beat them. Openness is a big feature, not directly for users, but it’s good for adoption of the platform.
I don’t care about the package format as long as the packages and package manager are good. Package *quality* and a very good package manager are the reasons why I prefer debian packages, which has nothing to do with deb or rpm.

Jerome Haltom - February 16, 2010

Well, yes. It does seem like an impossible problem.

I think I want to be a bit more optimistic than saying it is impossible, though. I think there is some sort of compromise that can be reached… and maybe some company will find it at some point. I think Android has come damned close for me. Hate the Java platform bits. Dislike the UI bits. Hate the hacked up userspace. Dislike the kernel mods. Wish I could app-get install android on any Ubuntu/Debian machine. Sure.

I think I have a lot greater chance of seeing all of that with Android than I do with Maemo. Android will be around. It will not vanish when funding is pulled. Because it is a money maker.

I have hopes that eventually Google will get tired of maintaining their kernel forks… and they’ll either replace them with other bits, or they’ll merge into mainline (renamed, rebuilt, as something else, etc.) Some compromise will be reached. It is open source code. It is possible for a team to make it possible to apt-get install Android. They just have to do a lot of work. But again, as long as the code has relevance and eyes on it, then people will do it. Eyes require devices in hands.

I think all of this was conscious on the part of the some of the brains behind Android. Okay, we know we have to make a ton of compromises to get this thing to ship… but as long as it ships, then we keep getting paid to work on it. One step at a time, etc.

2. Jimbo - February 16, 2010

“Technically interesting, but they appear to just be a money sink for their participating companies.”

I think actually in the case of Intel this is the complete opposite of a money sink, it is crucial to their survival. As things continue to change in the hardware world, soon even your main computer could potentially be running an ARM processor and if Intel aren’t careful they might find themselves relegated to gaming PCs and workstations. Ensuring their products are at the forefront of mobile computing is essential, and what better way to do it than to be the main player in the open source mobile stack.

Even if it will play second fiddle to Android in market share they are still in a better position than they would have been just twiddling their thumbs.

As for where Nokia fits in, I’m not even going to go into the whole mobile side of things because I will be typing all day ,but I would take the opportunity to remind you that Nokia came out with a netbook running an Atom CPU a few months back. At the time bringing out a Windows 7 netbook made no sense for Nokia to be doing, but fast forward 6 months from now and lets say they have the next gen of their netbook now running MeeGo and it integrates with the MeeGo mobile phones in some really cool way. Suddenly they have a whole hardware ‘platform’ rather than just a smart phone.

3. a - February 16, 2010

Intel’s problem is that their current offerings require too much power for the phone/tablet market which are very constrained by size and weight. Moblin, now MeeGo, don’t solve that problem.

The bigger problem now though is that the developers can’t trust either Nokia or Intel to have a consistent plan and not make surprise announcements of change of direction (Nokia-Maemo goes GTK->Qt->deb->rpm, or Symbian->Maemo->MeeGo, Intel goes GTK/Clutter->Qt). As a developer why would I want to develop for MeeGo given the poor track record of these companies?

4. mrmcq2u - February 16, 2010

“But in the end or customers / users will decide which platform and with this which applications they are going to use. Users will not care about the package format used in the platform or the toolkit that is used by some application.”
Yes this statement would be true if moblin and maemo remained independent but now end users will not have the choice to use clutter/gtk over qt after the merger because the two competing platforms will be focusing on Qt.
Would be nice if maemo stuck with Qt and Moblin stuck with clutter but now that choice is pretty much gone.

5. edgar - February 16, 2010

I’m pretty sure really cool apps written for gtk/clutter will go a long way in not making gtk/clutter obsolete. It’s a supported platform in meego. Nokia and Intel chose Qt for strategical reasons, but it doesn’t mean all app developers have to do so.

6. mrmcq2u - February 16, 2010

Yet on the site it only mentions Qt with relation to development and the only mention of clutter is that it will be supported for legacy, no thanks..
I became uninterested in maemo when they started pushing Qt and I don’t like it that they are assimilating the other option for people.
Take a look at the developer tools they advertise, do they mention Clutter? No! Only Qt, Well Moblin dies, maemo lives on, I lose complete interest.
I want a platform focused on clutter, if I wanted one focused on Qt I would have been a fan of maemo.
Its the equivalent of merging gnome with kde and telling people Qt is the way to go but don’t worry, we will still support your legacy gnome stuff or vice versa.
Stupid move Intel.

7. Tom - February 16, 2010

Oh come on people.

Sure Gnome Mobile and GTK/Clutter are now pretty much dead in mobile space, but this move makes so much sense no amount of petty whining about deb or GTK will change that.

Qt is already used by more than 5000 companies and as a dev platform it is more modern, mature, feature complete, efficient, platform independent and has better tools. There really is no competition. Intel was wise to see that. I guess the LGPL change made this possible. I just wish Qt got it sooner .. that would have prevented this bad fragmentation.

8. mrmcq2u - February 16, 2010

I suppose you would have had no objection if it was the other way around and clutter was used instead of Qt.

They were too completely different platforms and it didn’t make sense to merge them in my view both used competing toolkits and both used different distributions as bases.

Just goes to show how open they really are if these companies can completely redirect them without any notice, not surprising considering nokia’s track record but disappointing that intel decided to tag along.

9. Eric P - February 16, 2010

No device manufacturer in their right mind would use Clutter/GTK+ when there’s Qt available. Qt is also going forward, Clutter + GTK+ not so much.

@Tom: I wouldn’t be so sure about Gnome Mobile’s death, GTK+/Hildon is kind of dead yes. But isn’t Maemo/MeeGo basically still Gnome Mobile + Qt. Anyway, move to Qt is so obvious and right that words cannot express.

And @a:
Nokia is not going Symbian->Maemo->MeeGo.
Nokia has Symbian and for years they have been saying that Symbian will remain their choice for smartphones, Maemo/MeeGo is for “Mobile computers”.

10. mrmcq2u - February 16, 2010

@Eric P – Clutter is moving miles faster than Qt when you take the age of both projects into account, and now the MX toolkit will be released with the latest Moblin.
On what bases are you judging clutters prospects, surely if Qt were as great as you think it is there would be no need in trying to kill any competing toolkits on alternative platforms. Instead the Qt platform should kill such alternatives dead on its own merit.
No instead Qt take the approach of assimilation which Micro$oft enjoy to take so much.

11. mrmcq2u - February 16, 2010

@ Eric P “Maemo/MeeGo is for “Mobile computers”” – do we have a marketer in the room, mobile computer = buzzword for smartphone

12. Tom - February 16, 2010

@mrmcfu2

?? Qt did kill Clutter/GTK on its own merits. Intel looked at both and decided that compared to Qt Clutter/GTK has no future.

And really, just look at what Qt provides and will provide with 4.7 and compare that GTK/Clutter and tell me that you still think GTK/Clutter is better. Even if it was only for Linux Qt would be better, but it also runs well on Mac/Windows/Symbian/WinMo/Haiku/OS2 .. the list goes on. Qtcreator is better than anything crossplatform GTK has etc .. just make a chart will all features and compare you will see why they chose Qt.

And with that I will stop posting here, fan boys don’t respond well to solid reasoning.

13. Jerome Haltom - February 16, 2010

Dudes. Really. The last 11 comments are an argument about whether Qt or Clutter is better. Seriously… you’re making my point.

Nobody cares.

The one that is better is the one that is on a popular device first. That is it. That is all that matters.

If you want to see your side “win”, then go build a device. :p

14. Anders Feder - February 17, 2010

Jerome Halton for president. Don’t drag another promising open source project into the UNIX-flame-war abyss, people.

15. don - February 18, 2010

@Jerome Haltom

Developers care and we are one of the target groups. As someone who was using GTK a long time till he discovered QT, I’ve to admit that the decision to go with QT is the right on. This will pay out for Nokia and Intel and all others that will join this opportunity.

16. Anders Feder - February 19, 2010

Developers don’t care. They take the tools available to them and run with it. If they didn’t, nothing would get developed.


Leave a reply to a Cancel reply