October 5, 2011
This article was contributed by Nathan Willis
Intel and the Linux Foundation (LF) jointly announced the Tizen project on September 27 in a pair
of blog posts from LF Executive Director Jim
Zemlin and MeeGo Technical Steering Group co-chair Imad Sousou. Tizen is a
replacement for — or successor to — MeeGo in most respects,
particularly because it appears (at the moment at least) that Intel will
still be contributing developer resources to the project. But it also
imports Linux-based technology from Samsung, which had long been a member
and major contributor to the LiMo platform. Exactly what constitutes the
Tizen project — technically and from a governance standpoint —
is yet to be revealed. Meanwhile, a portion of the MeeGo volunteer development
community is reluctant to jump in and may take MeeGo in a different direction.
Poking at the vague bits
What is immediately clear from the initial announcements is that Tizen is supplanting MeeGo as Intel's mobile Linux device initiative. Sousou's post spoke only of transitioning from MeeGo to Tizen, not co-existence. Tizen will target the same set of "vertical" device categories as MeeGo: smartphones, tablets, netbooks, smart TVs, and In-vehicle Infotainment (IVI) systems. Zemlin said that Tizen will adopt "the same principles and open source philosophies" as MeeGo, notably the "upstream first" approach to building releases primarily based on existing desktop Linux projects.
What is unclear is exactly what components Tizen will include, although
Sousou said that HTML5 and JavaScript will replace Qt as the primary
— if not sole — application development framework.
Along those lines, MeeGo community manager Dawn Foster posted a welcome
message on the new Tizen site that alluded to the fact that HTML5 does
not supply device APIs for subsystems like "messaging, multimedia,
camera, network, and social media," and that "for those who
use native code in their applications, the Tizen SDK will include a native
development kit." The SDK, however, is not scheduled to arrive
until the first quarter of 2012.
An announcement on the LiMo Foundation site offers little elaboration, but does list the Wholesale Applications Community (WAC) platform alongside HTML5 as the development environment. WAC is a relatively-new coalition of handset manufacturers and mobile network operators attempting to define a standardized set of APIs for web runtimes. It currently defines APIs for accelerometers, cameras, calendar access, and contacts, and provides an Eclipse-based SDK.
Samsung itself has yet to make any formal announcement of its own at all, leading to a great deal of speculation over exactly what code the company is contributing to Tizen. Back in early September, there was public speculation that either Samsung was going to "join" MeeGo (perhaps rolling in its existing Linux-based OS Bada), or that LiMo would officially merge with MeeGo. Neither alternative seems to quite be the case. Samsung is one of LiMo's primary contributors, but LiMo is not an open source project — it defines a stack that uses the Linux kernel, but it uses proprietary components. Only LiMo Foundation member companies have access to most of the project's resources, and that does not appear to have changed as a result of the Tizen announcement.
Andrew Savory posted a detailed
examination of the history of MeeGo and of Samsung's past Linux
efforts. He argues that MeeGo's primary answer to the question "Why write
applications for MeeGo?" was the popular and established cross-platform Qt
framework. Absent a commitment to the project from Nokia, Intel looked for
a substitute framework, and decided that HTML5 with JavaScript was the only
framework with an established history and viable developer pool.
As for Samsung's code contributions, Savory suggests that the device maker will be donating Samsung Linux Platform (SLP), a LiMo-compliant OS that it has developed, but which has not yet been released in consumer products. What makes that possibility intriguing is that SLP uses GTK+ and the Enlightenment Foundation Libraries (EFL) as its application frameworks. Carsten "Rasterman" Haitzler from Enlightenment recently appeared on the Tizen mailing list, which suggests that EFL will be part of the "native" Tizen APIs, but he would not comment on any specifics.
Both Intel's Moblin and Nokia's Maemo used GTK+ prior to Nokia's acquisition of Qt; if Tizen does bring GTK+ back into the fold, it would be understandable that Intel and Samsung would want to downplay the yet-another-toolkit-swap angle and focus instead on the cross-platform availability of HTML5. Sousou's blog post rejects the notion that "evolving" MeeGo would have given it the platform it wanted, even by adding a robust web runtime. That suggests that the application framework for Tizen will incorporate deeper changes — but it will still likely be several months before anyone knows for sure.
The developer-on-the-street view
The lack of detail about the architecture of Tizen resulted in frustration among MeeGo community developers. The new Tizen mailing list is filled with questions about both the web runtime framework and how the underlying stack differs from MeeGo — questions that so far do not have answers. Post-announcement discussions on the MeeGo list are similar.
The LF is not shutting down the MeeGo project or infrastructure (at least for the time being), which led some MeeGo core contributors to call for continuing to develop MeeGo as an Intel-free project. That call to action seems to assume that Tizen will differ significantly from MeeGo. For his part, Dave Neary argued that it is simply too early to make such a call, and that one can only wait and see:
MeeGo is a collection of open source software components. Tizen will also be a collection of open source software components. which of those components will be different? There will certainly be a few, but I don't know how many. Which of the new components are currently closed and will need to be freed, and which of them are already free? I don't know.
Are there any software projects that people are attached to, which will not be part of Tizen? Dunno...
On the other hand, Thiago Macieira believes
that the lack of information and Tizen's 2012 release date amount to
asking developers to stop working for several months and wait:
At this point, it looks to me like a no-brainer decision. The big
question will come when Tizen has something to show and the community can
join. In the meantime, the community can do some soul-searching and
figure out how it wants to answer that question
Neary and Macieira's comments were directed primarily at contributors to the MeeGo core. Developers of independent applications have different concerns to consider. They clearly cannot begin substantial work on any Tizen applications before the APIs and SDK start to take shape. Just as important, though, is whether or not the new Tizen platform means throwing out all of their Qt-based MeeGo code.
Nokia's Quim Gil said that the Qt project would be happy to "provide tools for [Tizen stakeholders] to make Tizen a first class Qt platform if they wish." Several others in the same thread (including Qt developers) concurred, noting that Qt will probably "just work" on Tizen if there are not major structural changes. Perhaps more importantly, Novomok announced on September 28 that it would support Qt integration on Tizen for commercial customers.
The near-term future is less certain for device-makers that have been planning MeeGo-based products. LF's Rudolf Streif provided some insight into the impact of the move for IVI vendors, saying "MeeGo IVI's work has always been focused on the middleware on top of the Linux stack provided by MeeGo Core to support the functionality required for vehicle applications such as connectivity to vehicle networks (CAN, MOST, etc), audio management, etc. [...] In that sense all the work that has been done for IVI in conjunction with MeeGo still applies to Tizen." Intel's Joel Clark said that there will be an update to MeeGo 1.2 sometime in 2011, and that engineering support will continue for another year, but that the next major release will no longer be based on MeeGo.
Reactions
To many MeeGo community members, the status of the code and makeup of the architecture was not the main issue. They felt betrayed by the Tizen move, which seemed like a blatant reversal of the public "Intel is not blinking on MeeGo" pledge the company made after Nokia's February announcement that it would start shipping Windows 7 phones. Such a platform shift was doubly hard on veterans from the Maemo project, who had weathered Nokia's departure earlier in the year as well as a major shift in the application development framework after Nokia purchased Qt. Moreover, some felt that the strategic shift from Qt to HTML5 (regardless of Samsung's involvement) constituted a breach of the "open governance" and meritocratic principles of the MeeGo project — Florent Viard even went so far as to call it a "takeover."
In the immediate aftermath, a number of other open source projects saw the pool of unhappy developers and tried to entice them over into joining their own distribution. Jos Poortvliet was the first, beckoning MeeGo developers to come joining the OpenSUSE project (seemingly to work on OpenSUSE's ARM port). Timo Jyrinki followed, inviting the developers to join Debian instead and contribute to its smartphone sub-projects. Aaron Seigo suggested that the developers join the KDE project's Plasma Active effort, and announced a number of meetings would be held in a community IRC channel later this week.
For some, however, neither waiting for a 2012 SDK nor signing up for a
different project were appealing. Carsten Munk announced
the re-activation of the Mer project
on October 3. Mer was initially a community rebuild of Maemo, using only
open source components. After MeeGo started picking up steam, Mer was
suspended, and the developers instead focused their energies on porting MeeGo builds to the
not-officially-supported N900 hardware.
The revitalized Mer is described as a "truly open and inclusive integration community" for MeeGo and Tizen devices. Munk set out the goals as building an open UX layer on top of MeeGo Core, while hopefully remaining compliant with Tizen, and breaking MeeGo down into a set of flexible and modular components that are easier for device manufacturers to work with than MeeGo's large and arguably complex compliance effort. The team has already deconstructed MeeGo into 302 packages, and coaxed it into booting into a Qt UI on a Raspberry Pi board.
If Mer picks up steam (and the project members have a proven track
record in recent years), there would of course be bigger challenges to be
addressed, such as governance and the potential desire to move away from
MeeGo conventions (such as RPM packaging). That sort of discussion has already surfaced on the MeeGo discussion lists — although it is important to observe that most of
those discussions are between other community members; Munk regards
reusing the RPM and Open Build System infrastructure inherited from
MeeGo as a done deal.
Wherever Mer (or a community-driven MeeGo) goes in the coming months, the real challenge will be when Tizen produces its own architecture plans and governance structures. It is easy to compare "work that's available now" to vapor and prefer the former. But if Intel and Samsung deliver a compelling alternative in Tizen — especially one that proves itself more stable than the recent history of Maemo and MeeGo — then the choice becomes more muddled.
For the time being, all anyone can do about Tizen is wait for details to emerge. Foster said that Intel is deliberately taking a slower approach this time around, at least with respect to community participation and governance issues, having learned from the high-profile launch of MeeGo. Regarding the HTML5 and WAC-based application framework, information is still scarce, and, as anyone who follows "open web" news knows, there are several competing frameworks and APIs out there already — including from established open source players like Mozilla and Google Chrome. Haitzler's appearance on the Tizen list and various other tidbits about SLP make it sound like the native APIs, too, will require much explanation, but there is still no official word. Until then, the community waits.
(
Log in to post comments)