Doug Abbott: Embedded Linux development using Eclipse

http://www.intellimetrix.us — Here’s where you can purchase the embedded target board mentioned in Chapter 6 and described in more detail in Appendix B. The downloads page will host any updates or corrections.

http://www.groups.yahoo.com/group/eclipsebook — This Yahoo! group is specifically for readers of the book, a place to ask questions and share ideas. Updates and corrections will also be posted here.

This project never would have come to fruition without my editor, Rachel Roumeliotis, and her assistant, Heather Scherer. They had the thankless job of continually “prodding” me to stay on schedule and get the thing done!

Several Eclipse contributors on the newsgroups pointed me in the right direction when I was puzzling over some seemingly strange behavior: Wayne Beaton, Doug Gaff, David McKnight, Shigeki Moride, and Martin Oberhuber.

Thanks are also due to Craig Crinklaw and Sonia Leal at LynuxWorks, and Troy Kitch at Monta Vista for supplying me with, and helping me get running, demos of their Eclipse-based IDE products.

Stroll around the exhibit floor at the Embedded Systems Conference either in Silicon Valley in April, or Boston in September. You’re sure to see any number of large, flashy booths with big flat screen monitors showing off the vendor’s integrated software development environment. You’ll probably also hear a pitch by a well-groomed marketing type wearing a wireless headset and offering a T-shirt or other giveaway if you’ll hang around for the full presentation.

After a while, it begins to dawn on you that all these integrated development environments (IDEs) seem to have a similar look and feel. Coincidence? Not really. Turns out that most of the major embedded software vendors have adopted Eclipse as the foundation for their IDE products.

It makes perfect sense. Developing embedded development tools is expensive and time-consuming. Making use of a common platform saves a lot of that time and expense. It also provides tools with a consistent look and feel that run in a wide range of operating environments. Vendors compete on the basis of their own proprietary additions to the base platform.

And really, is it any different from the multitude of vendors who build embedded products based on the PC architecture? They all start with the same PC platform and then add their own proprietary hardware and software to create value-added products.

Eclipse grew out of the project that began in 1998 at Object Technology International (OTI), a subsidiary of IBM now known as the IBM Ottawa Lab. The project was initiated to address complaints raised by IBM’s customers that the company’s tools didn’t work well together.

In 2001, IBM established the Eclipse consortium and released the entire code base, estimated to be worth $40 million at the time, as open source. The idea was to let the open source community control the code and let the consortium deal with commercial relations. The initial nine members of the consortium included both partners and competitors of IBM at the time, such as Rational and TogetherSoft.

As Eclipse grew and evolved, IBM wanted more serious commitment from vendors, but vendors were reluctant to make a strategic commitment as long as they perceived that IBM was in control. This problem was addressed in 2004 with the creation of the Eclipse Foundation, a not-for-profit organization with a professional staff and a large and growing roster of commercial software vendors as members.

As of August 2007, the Eclipse Foundation listed 166 members on its web site. There are four categories of membership reflecting different levels of commitment [1] The membership categories were modified somewhat in July of 2008. For details of the new membership categories, see the following page at the Eclipse Web site: www.eclipse.org/membership/become_a_member/membershipTypes.php. :

• Committers . Individuals who contribute and commit code to Eclipse projects. They may be members by virtue of working for a member organization, or may choose to join independently if they are not. Note that Committers are not included in the membership total above, as they are not listed on the web site.

• Associates . These are standards organizations, research and academic institutions, open source advocates, or publishing houses that participate in the development of the Eclipse ecosystem. There are currently 24 associates who can submit requirements, participate in all project reviews, and participate fully in all Membership Meetings. Associate Members are not assessed dues.

• Add-in Providers . Commercial software vendors who have publicly expressed support for Eclipse. Add-in Providers are expected to make available a commercial Eclipse-based product or service within 12 months of joining the foundation. Products may be built using Eclipse tools or on top of Eclipse projects. Services may include, for example, training, consulting, or a hosted web service. The 121 Add-in Provider Members each pay annual dues of $5,000.

• Strategic Members . These are the big dogs. Strategic Members fall into two categories: Strategic Developers and Strategic Consumers. Each Strategic Developer is expected to have at least eight developers assigned full time to developing Eclipse technology and contribute annual dues of 0.12% of revenue with no minimum and a maximum of $250K.

Strategic Consumers are users of Eclipse technology. They contribute annual dues of 0.2% of revenue with a minimum of $50K and a maximum of $500K, but can reduce the cash outlay by contributing one or two developers to Eclipse projects at a rate of $125K for each developer.

Each Strategic Member has a representative on the Eclipse Foundation Board of Directors allowing them direct control over the strategic direction of Eclipse. Strategic Members also have a seat on the Eclipse Requirements Council providing input and influence over the themes and priorities of Eclipse technology.

There are currently 21 Strategic Members, including IBM, Intel, Motorola, Nokia, Oracle, Sybase, and Wind River, among others.

Open source software is released to the public under the terms of a license that grants users of the software certain rights, the most significant of which is access to the source code. The software is copyrighted by its author, but rather than using the copyright to restrict access and use, which is the usual case, the copyright becomes the means of enforcing the rights granted by the open source license. Because open source effectively “reverses” the rights granted by copyright, it is often referred to as “copyleft.”

Many users familiar with open source software may assume that the Gnu General Public License (GPL) is the one and only mechanism for making open source code available. In fact, there are over 50 different licenses certified by the Open Source Initiative, a non-profit body that reviews and certifies licenses that meet its 10-point definition of what constitutes open source software. Note, incidentally, that open source does not prohibit one from charging a fee to distribute open source software, and indeed, many companies are in the business of doing exactly that.

Part of the FUD (fear, uncertainty, and doubt) spread about open source software, mostly by a certain software company in the northwest United States, revolves around its so-called “viral” nature. The implication is that if you use any open source software in your product, it “infects” the rest of the code, forcing it all to be open source. This is at least partially true of software released under the GPL and it’s an issue that developers must take into consideration if they wish to keep their own code proprietary. The GPL requires that any “derivative work,” that is, code derived from GPL code, must also be released under the terms of the GPL.