MeeGo steering group easing platform concerns?

Valtteri Halla, the Nokia member of the MeeGo Technical Steering Group recently attempted to allay the concerns of the open source community by underscoring the importance of openness in the development of the MeeGo operating system.

In a blog post last week, the veteran Nokia executive who has been working to get Linux onto Nokia phones since 2000, announced that the MeeGo repository will be opened by the end of this month. The source and binary repo will provide a raw baseline for building MeeGo on the Nokia N900 and Intel Atom-based netbooks.

What’s more interesting is the flurry of debate surrounding the details – or lack thereof – related to the processes that will enable the open source development model to flourish around the MeeGo platform. So far, Halla has said little about the decisions made by the technical steering group to choose RPM rather than deb as the package manager for MeeGo:

While code is certainly the most important question, the most frequently asked, however, has been about technology selections. The big ticket items like Qt, OBS and RPM were already communicated at the launch and as we expected, kicked off a few small avalanches of debate! These selections were, of course, pre-agreed and I can assure you that the amount of effort spent in resolving these was not small. After all, these are the points driving most of the investment cost and transition pains for Nokia, Intel and the Moblin and Maemo communities. Further selections are mostly still under discussion and beyond a few obvious ones (X, connman, ofono, gstreamer, dbus,…) can be considered as working assumptions for MeeGo 1 release. Now that the internal responsibilities within Intel and Nokia are becoming clear I expect that the people behind these selections and assumptions will start appearing in meego.com pages, mailing lists and wikis during the coming days.

This has generated some concerns that developers are being left out of the conversation, thus increasing their skepticism of the purported “openness” of the MeeGo platform. To be fair, it was necessary for the steering group to make some hard decisions at the beginning of a big open source initiative that merges two existing platforms. Otherwise, we could argue till the cows come home and nothing will move.

But what is the process that governs these decisions? Are we talking about a process similar to JCP (Java Community Process), where there are clearly defined procedures for the development and revision of the Java’s technology specifications?

Other tough questions that need to be addressed: driver support from hardware and device manufacturers, DRM support that is compatible with operators’ content business and application support for potentially different variants of MeeGo that could emerge. The technical steering group should address these issues early on if it wants to seed a rich developer ecosystem that is crucial for the success of any mobile platform.