In recent years, the open-source software-development process has demonstrated some impressive successes (see sidebar "Defining open source"). According to the December 2003 Netcraft Web Server Survey (news.netcraft.com), users employ the Apache HTTP Server project, an open-source project of the Apache Software Foundation (www.apache.org), to run more than 67% of the Websites on the Internet. The GNU/Linux operating system (www.linux.org) is another widely used and supported open-source software project. The Eclipse Platform is an open-source software project that is garnering support for embedded-development tools.

Eclipse is an open-source software-development project focused on building a platform for hosting and developing tightly integrated software-development tools. IBM, with a $40 million donation, launched Eclipse as an open-source project in November 2001 as a way to more cost-effectively create a platform that supports best-of-breed tool plug-ins. IBM has continued to be the major content contributor to the project and has headed the project organization. The project is currently changing to an independent entity that replaces the IBM leadership with an independent management organization. This transition emphasizes the project's focus on creating an industrywide platform for tool integration. The name of the project may also change as part of the transition.

The Eclipse and the Sun-driven NetBeans projects are similar open-source projects that compete with each other as Java-development environments. Sun recently formally declined to join the soon-to-be independent entity's board of stewards, citing a lack of common ground between the Eclipse and the NetBeans projects that would preclude an equitable share in mutual development. Both Eclipse and NetBeans are Java-based platform frameworks and language-independent IDEs (integrated-development environments). Being Java-based, they can operate on a range of hardware and operating systems, including Windows, Linux, Solaris, and Mac OSX. Both IDEs are free downloads, require a JDK (Java development kit) 1.3 or higher compatible virtual machine, and immediately support Java development. Additional language or development-tool support, such as for C/C++ development, requires you to download additional plug-ins or modules.

Both Eclipse and NetBeans allow you to create your own tools that integrate with and extend the IDE to support any software-development function. Tool extensions are called modules for NetBeans and plug-ins for Eclipse. The plug-in/module interface differs between the two platforms, so the plug-ins and modules for each are incompatible, and the platforms cannot share them. The cross-target graphical tool kits that each project uses are another source of significant divergence (see sidebar "Native versus emulation").

NetBeans uses the Swing/AWT (Abstract Windowing Toolkit) graphical tool kits to provide a "write-once, run-anywhere" capability. The Eclipse project uses the JFace/SWT (Standard Widget Toolkit) graphical tool kits, which can provide better native performance as well as the look and feel at the expense of some target portability. Another fundamental difference is that Swing uses the Java garbage collector, and SWT relies on the programs to free operating-system resources. This difference allows SWT to expose operating-system functions and avoid timing issues—especially between versions of the JVM (Java Virtual Machine)—from the time an object becomes garbage to when the system performs finalization to free the resources.

Eclipse and NetBeans share a strong enterprise-software-development bias, but integrated tools for embedded development that use the Eclipse framework are starting to appear. The member-company representation in the Eclipse organization encompasses the enterprise, Linux, and embedded-development segments for tool development. Each of these segments has a different audience with different needs, and the platform workbench includes commodity functions that apply to each development segment. Tensilica and WindRiver are recent adopters of the Eclipse platform from the embedded-system industry.

Tensilica's Xtensa Xplorer IDE uses the Eclipse platform for processor-configuration and software-development tools. Even though Wind River has the Tornado IDE, company officials feel that using the Eclipse framework allows it to focus its development resources more on tool functions and less on commodity- infrastructure functions. Eclipse's tighter integration with the native platform, which resulted in near-native performance, and its more native look and feel were considerations in the companies' decisions to adopt Eclipse.

The Eclipse framework is distributed under the CPL (Common Public License), which encourages collaborative open-source development of the code base but is flexible enough to let you use and integrate the code with software licensed under other licenses, including commercial licenses. The OSI (Open Source Initiative) approved the CPI, and it is available at www.opensource.org. If you modify a program licensed under the CPL, such as the Eclipse code base, and you distribute the object code, you are obligated to make the modified source code available to others. You need not make your modifications available to others if you use the modified program only internally and do not publicly distribute the changes. You also need not make the source code publicly available if you write and distribute plug-in modules that interface with but do not change the CPL code.

The provision that plug-in modules need not be open-source if they interface with but do not change the base code is important if you want to distribute value-added functions under a commercial license. This licensing model allows you to freely use the Eclipse framework and develop value-added functions as plug-ins instead of using your tool-development resources to build an environment around your functions without giving up proprietary IP (intellectual-property) rights.

Developing and maintaining software tools from scratch can be costly. Open-source projects, such as Eclipse, may help you reduce your building and maintenance costs for the commodity portions of your tools. The plug-in architecture of the Eclipse platform couples with the terms of the CPL to allow you to balance between using and distributing the commodity and proprietary portions of your code and benefit from and contribute to the commodity portion of the software at lower cost than if you did not use the platform (see sidebar "Extending Eclipse"). However, not all software is created for distributed commercial sale; in-house tools and embedded software are two examples. As open-source commodity software continues to mature, it may make sense for you to periodically evaluate whether and how platforms such as Eclipse might help you develop and maintain your in-house software tools at lower cost.

The embedded-software-development community is fragmented and diverse. The embedded-development environment is teeming with processor architectures and development tools to address dissimilar application-specific requirements for constrained resources, such as memory usage, processor performance, and power consumption. Embedded software often tightly couples with the underlying hardware to meet the performance and cost constraints of real-time embedded-system applications. The fragmented nature of the embedded-software-development environment complicates the wide applicability that benefits many open-source software efforts, because most of the embedded-system architectures differ significantly and are exclusive to each other.

However, the embedded-development market's fragmentation strengthens Eclipse's core value-proposition, because the open-source base code covers the lower commodity-value portion of IDE construction and supports proprietary- tool extensions. Usually, software-development tools from processor vendors are strategic components to selling their silicon and are generally not subject to direct competition from similar tools from other processor providers. A possible indirect benefit of using Eclipse-based development-tool suites is that your in-house tools could exist in the same environment and support better integration between in-house tools and other tools, proprietary or otherwise, that have also adopted the Eclipse platform. On the other hand, pure-software-tool providers could see Eclipse-based tools as sources of complication because these providers base a significant portion of their tools' value on creating a consistent and fully integrated environment that covers a range of processor devices and architectures.

The GCC (GNU Compiler Collection), available at www.gnu.org, provides an open-source compiler front end for several programming languages, including C and C++. To support a specific microcontroller, someone must port the GCC to support it, and ports for embedded processors, such ARM and MIPS architectures, exist. The GCC can probably support code compilation for any microcontroller or DSP. However, application-specific resources and optimizations, such as special-purpose registers, multiple memory spaces, and modal instructions that some microcontrollers and DSPs use, do not play to the strengths of the GCC engine and may make the porting effort impractical. The compiler output-code quality and performance are tool differentiators. Proprietary embedded-compiler tools are quick to highlight material performance margins when you compare them with GCC output, and those margins can critically affect the hardware costs for high-volume, cost-sensitive applications.

The Eclipse IDE completely avoids the target-code-efficiency issue unless you are developing for a Java target. Eclipse's current proposition is that, as a tool de veloper, you do not have to build the commodity components of an IDE, such as the workbench, file navigator, wizards, text editor, component-version management, and publishing services. The CDT (C/C++ Development Tools) project provides a set of plug-ins that implement a C/C++ IDE. Each component of the workbench is extensible and customizable via the plug-in interconnection model, allowing you to focus more of your development resources on the value-added tool function. If your suite of tool functions is loosely coupled, you can with little effort probably focus most of your resources on plug-in development and maintain compatibility with future versions of the base code. If your suite of tool functions is tightly coupled, you may decide it is worth changing the base code and contribute the changes back to the community.

Under the terms of the CPL, if you distribute software or tools that make changes to the Eclipse base code, you must make the source code for those changes available to the community. Why would you be willing to invest resources to modify code that you must give away? The answer to this question is central to the short- and long-term viability of the open-source community. The roots of the formal open-source community arguably derive from the idea that a community of individuals can provide alternatives to and compete with proprietary software from big businesses.

Many theories try to explain why programmers choose to develop open-source software despite the fact that this type of development generally precludes direct monetary rewards. For some, open-source development is a way to build a reputation; for others, it is a fun hobby; for yet others, it is a way to learn how to be a better programmer. Some do it because it aligns with their political or moral positions. Others see it is a way to give back to the community, to protest proprietary software, to make software affordable, or to take and keep control over the software they use.

These reasons may apply to individuals, but why would a business invest resources to build and test code that is freely available to its competitors? Joel Spolsky, owner of Fog Creek Software, applies microeconomic concepts to theorize why companies would spend their resources on open-source software (Reference 1). Every product in the marketplace has substitutes and complements. A substitute is an acceptable alternative product you might use if another product costs you too much. You could view open-source software as a substitute to proprietary software.

A complement is a product that you usually buy together with another product—for example, computer hardware and an operating system. Embedded processors and software-development tools are also complements. An important relationship between complements is that demand for a product increases as the prices of its complements decrease. Processor vendors try to strategically commoditize the software-development tools available for their processors to enhance the demand for their processor offerings. In contrast, pure-software-development vendors try to commoditize the processor support, by supporting a range of processor devices and architectures to enhance the applicability and demand for their software-development environment and tools across a wider audience.

Commoditizing the complements to your company's core competencies makes good business sense. Communitywide use of Eclipse can commoditize the base functions of development-software tools and IDEs. Hardware is not the only complement to development tools; support and consulting services can also benefit from commoditizing the tool environment. The Eclipse platform and the CPL do not preclude value-added plug-in tools that commoditize consulting services.

Keys to deciding whether to use an open-source platform are the overall time and cost differences between building and maintaining your own platform and using the open-source platform. Considerations include modifications you might need to better accommodate your needs, such as easing the complexity to integrate and more naturally present tightly coupled tools to your user. If a tighter integration mechanism will add strategic value to your product, an open-source platform may be a bad business choice. If the Eclipse platform provides you with sufficient IDE function, using it may save you significant development resources that you can focus on more valuable tools and functions.

Development tools provide value by lowering development risks. They can reduce development time, overall cost, and complexity by enabling you to work at higher abstraction levels. Although the Eclipse platform is free, the tools on top of it are not necessarily so. And, although tool interoperability is not the focus of the platform, it is another potential benefit of the Eclipse platform whereby plug-in tools built by independent developers can interact with each other in an integrated way without prior effort. Examples of this type interoperability are code-development tools from a provider and library/version-management tools. Their coincidental interoperability is due to the fact that little to no coupling exists between the tools; they perform functions that are exclusive to each other. Any inter-operability between tightly coupled tools is the result of deliberate planning and cooperation using and extending the integration levels built into the Eclipse platform.

Most Eclipse-based tools are available as complete installation packages that include the Eclipse binary. In this way, the tool provider provides you with a single source for getting the tools running. It also enables the tool provider to ensure version compatibility between all of the dependent components and to bundle any complementary plug-ins from a single installation. Eclipse-based tools can also take advantage of the update-manager plug-ins to manage updates. Tool vendors may also make their Eclipse-based tools available as just plug-in files; this approach requires users to install Eclipse on their systems and places responsibility for version synchronization in their hands.

Each company handles Eclipsed-based technical support differently. Just because the platform code is open source does not mean it is in the tool providers' best interest for you to troubleshoot problems without their support. In general, technical support for the tools is a key value, and each company may act as a single point of contact for you with regard to its tools within the environment. If you are experiencing trouble within the base platform or between two tools, some companies may still act as a single point of contact to determine the cause of and a resolution to the problem.

As an embedded-system designer and user of development tools, you may not care whether your tool provider uses the Eclipse platform. If you develop in-house tools, you may value the opportunity for tool integration that the Eclipse platform provides. You may also value the independent tool-interoperability opportunities; be sure to recognize that you may already be using a proprietary tool environment that supports similar integrated tool interoperability. The Eclipse platform has a strong enterprise bias in its architecture, but it may become more appropriate for supporting embedded-development tools, especially as companies from the embedded-tool environment on the board of stewards influence the code base to better accommodate the needs of embedded development.

Author Information

You can reach Technical Editor Robert Cravotta at 1-661-296-5096, fax 1-661-296-1087, e-mail rcravotta@edn.com.