They have plenty to talk about. Predictions for Linux in the embedded market have always been rosy, and they are getting better all the time. As Motorola's Scott Preece noted in one session, it is now expected that there will be over 200 million Linux-based phones in circulation by 2012. Linux shows up in special-purpose applications on a daily basis - often in unexpected places. Increasingly, Linux is the operating system of choice for small systems.
The royalty-free nature of Linux is certainly a reason for its success in the embedded field. If one is selling millions of gadgets, even a small per-unit royalty adds up in a hurry. But cost is not the real motivation here. The ways in which Linux can be modified for specific tasks and the general level of control it gives to vendors are both more important. Also, as Mr. Preece pointed out, there is a ready supply of Linux expertise out there for embedded companies to hire. On the other hand, very few developers go out and learn the Symbian platform on their own. There are advantages to going with a standard system.
Given this situation, one would have expected the ELC to be a large event, but it is, instead, surprisingly small. Quite a few embedded systems vendors were present - telephone handset manufacturers were especially well represented - but others were notable in their absence. ELC was not a particularly well-promoted event, which might partially explain its small size. Whatever the reason, it would be nice to see wider participation in the future; this community, like any other, needs to get together occasionally and talk.
Participation in the community was an ongoing theme of this conference, from Thomas Gleixner's opening keynote through to the end of the last day. Embedded vendors are famous for going their own way, neglecting to contribute their changes back, and generally pushing the GPL as far as they can. If there is one message which came out of this conference, it might be this: the embedded vendors are aware of their lack of participation and the problems it causes. Many of them - at least, those who came to this event - would like to make the situation better. But they often find themselves in a hard position.
Working with the community requires patience, openness, and a willingness to let go of some control. The embedded market, for the most part, does not reward those characteristics. Products come and go after a few months, and, once a product is out the door, and an embedded vendor has little motivation to continue to work with it. So merging product-specific changes back into the projects upon which they were based looks like a cost with little associated benefit. There is little intent to maintain that product into the future, and there will almost certainly be no big software upgrades for it. So the code looks dead. The fact that getting their work into the upstream repositories will help those projects support the next product better is beginning to get through to some companies, but it is a slow process.
Getting code into an upstream project - be it the kernel or higher-level software - goes best when that project is engaged from the beginning. A big after-release dump of previously unreviewed code tends to be hard to integrate at best. But the last thing a gadget maker wants to do is to release detailed internal information about its next product months before that product is announced. So late code dumps will likely be a best-case scenario for some time yet to come.
Consumer electronics products also tend to be quite static once they are shipped. When Nokia released a major software upgrade for the 770 tablet, it was the first time it had upgraded the software for any product in the field. Openness and modifiability are somewhat strange concepts for this industry. Products like the Nokia tablets and the OpenMoko phone are blazing new trails; many vendors are likely to be watching to see how well these experiments go.
Seen in this context, the announcement of the GNOME Mobile & Embedded Initiative fits right in. The GNOME developers, too, are looking to bring embedded vendors into their community and to get them to help make the platform better. They seem to be succeeding: the project claims that there are now more GNOME developers paid to work on embedded applications than on traditional desktop systems. GNOME is already a capable environment for embedded development, allowing developers to use the same software stack on all types of systems. If the project continues to be successful in getting embedded vendors to help build the platform, interesting things are certain to happen.
Some vendors have GPLv3 on their minds as well. Many of the libraries being used by embedded systems are licensed under the LGPL; once version 3 comes around, the LGPL will be essentially a patch to the GPL giving some extra permissions. So the LGPL will continue to allow proprietary applications to be used with the libraries. The LGPL does not, however, waive the anti-DRM provisions of GPLv3, meaning that users will have to be able to replace any LGPLv3-licensed libraries on their gadgets. Such replacement could allow application behavior to be changed in interesting ways - and badly mess up any lockdown scheme. How that will play out remains to be seen; embedded vendors may gain a renewed interest in technologies like SELinux or AppArmor to keep embedded applications firmly sandboxed.
These issues will certainly be worked out; the incentives to do so are strong. The embedded Linux community is on a roll, and rightly so. Linux has all of the right features and freedoms to be an attractive platform in that arena. If this industry can pull together into a true community - with the users as members too - there will be few limits on what it will be able to achieve.looked at the discussion surrounding the GNOME project's mystery announcement at the 2007 Embedded Linux Conference. That announcement turns out to be the GNOME Mobile & Embedded Initiative, a determined push to bring about world domination in the embedded area.
GNOME hacker Jeff Waugh started his presentation with a brief history of the GNOME project. He pointed out that there is a lot of innovative, bleeding-edge technology in the GNOME platform - developments which have pushed the edge within the desktop and beyond. Examples included the libxml2 library, Pango, Project Utopia (which had the goal of making hardware "just work"), Network Manager, and now the Power Manager work. Another stage in this history was the creation of the GNOME Foundation, which showed that the free software world can work with commercial interests to the benefit of both.
In recent times, the shipments of desktop PC's are in decline. On the other hand, laptop shipments are growing, and the shipments of other mobile devices are growing rapidly. There are, says Jeff, more developers paid to work on the GNOME platform for embedded use than for the desktop. Mobile devices, it seems, are the future. This is the situation that the GNOME Mobile & Embedded Initiative was created to take advantage of.
There is a long list of companies and projects which have signed on to this effort - see the obligatory collection of quotes for details. Much was made of the fact that the initiative is a cooperative effort including both companies and free projects.
The initiative, says Jeff, is about writing code. All of that code will have the full GNOME platform available to it (if it needs it), and will be ABI-compatible with the desktop platform. This "is not toy GNOME," it's the full thing. The platform will carry the GNOME LGPL license, making it available to proprietary applications - royalty-free, of course. And it's shipping today, though the first official release will be with GNOME 2.20 in September.
A wide variety of devices is covered by this platform. Examples given at the conference include the Nokia N800 (an Internet tablet device), the One Laptop Per Child XO system, the OpenMoko phone, and, at the novel end of the scale, the upcoming Vernier LabQuest, a handheld data acquisition and display device with a vast list of sensors available to it. The LabQuest was held up as an example of a device which was developed by a company with little software expertise; the Linux and GNOME platform made the whole thing relatively easy. All of these, says Jeff, are "beautiful new ideas" enabled by the open source stack.
The initial code from the GMAE initiative is available now. Possible additions in the near future include display frameworks from a number of sources (examples include the OpenMoko framework and the Hildon desktop used on the N800), applications like TinyMail, integration of GeoClue, and more. There's also low-level initiatives like better touchscreen support in GTK, fixing the floating-point usage in Cairo, etc. Beyond that, time will tell; chances are it's going to be interesting.one complaint which could be heard in the right places, however: it seems that this whole initiative was conceived of and agreed to without the involvement of the GNOME marketing team. One might well ask: if the marketing team does not get involved in an agreement like this one, what does the project keep it around for?
There's a couple of responses which are worth a read. Dave Neary, a member of this team, had some stark comments:
Jeff Waugh, the driving force behind the embedded initiative, states:
One might well argue that the GNOME marketing team has failed to live up to expectations. Some members of the team are doing so and beginning to think about ways to change that situation. As a result, we might well see a more active team in the future. But there is a question which is worth asking here: to what extent might the comments quoted above apply to any project's marketing team? It might just be that a project which is trying to grow its user and development community has little to gain from the formation of a marketing group.
In the corporate environment, a marketing team takes a leading role in identifying potential customers, designing something that those customers might just want to buy, and finding ways to motivate customers to make that purchase. Once a marketing strategy has been worked out and adopted, the rest of the company is expected to work to execute that strategy. In successful companies, marketing tends to lead the way.
Most free software projects are not amenable to this sort of leadership. What gets done in free software is what individual developers decide to do - or are told to do by their employers. Paid developers may well be working toward the execution of a marketing plan, but it's their employer's plan, not the project's plan. Free software hackers will be working to make a project better, but they are not marching to the project's drummer. They will not seek approval from a project's marketing team when they decide what to hack on.
The same is true of project members who work to create initiatives or alliances in a specific area. GNOME's support of embedded applications comes as a result of work by interested developers and the companies which are operating in that area. It was a natural consequence of the way the embedded market is going; there was no need for a marketing team to foresee, plan for, or mandate a bigger role for GNOME in the embedded marketplace. If a GNOME marketing group were to call for such a role, it would have little effect on GNOME developers working on more traditional desktop applications. Free software projects are not corporations; free software users and developers will not wait for a marketing group to sign off on their plans.
Some projects do have marketing organizations which appear to be effective. The push behind the Firefox browser is arguably one of the most prominent examples; the alliances and promotional campaigns which have been arranged have undoubtedly helped to increase adoption of the software. The marketing of packages like MySQL has also been effective. There is a pattern to be seen here: in almost all of the cases where a free software project has had an effective marketing operation, that project is owned and controlled by a single corporation. In such cases, the project's marketing plan is, in fact, a component of the company's plan; it's the company's control of the project which allows its marketing objectives to drive what the project does.
In the absence of that sort of control, it's not clear what a free software project's marketing team can achieve. Certainly a marketing group can point out areas of opportunity in the hope that developers will choose to pursue those opportunities. Such pointing-out must be done carefully, though; free software hackers tend to be irritated by those who seem to be trying to tell them what to do. Marketing teams can also fulfill a useful sales role by, for example, organizing booths at trade shows, distributing live CDs, convincing distributors to package the software, etc.
But it's not the marketing group which will bring about a project's success; that depends on the code, artwork, music, documentation, support, etc. provided by the project's members. A project is made by its community, not by a marketing plan. It's hard to imagine wanting that to change.
Page editor: Jonathan Corbet
Copyright © 2007, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds