The Eclipse framework creates both opportunities and design challenges for vendors of integrated software development tools. The open-source nature and extensive built-in capabilities of the Eclipse framework force vendors to evaluate how they will provide value
to their customers and how they will differentiate their products. Developers seeking to maximize their purchasing power and minimize learning curves also face difficult decisions when selecting Eclipse products. To date, three distinct approaches have been chosen when addressing Eclipse use in deliverable products. They provide varying degrees of flexibility to developers working within the Eclipse environment.
For "Isolationist" vendors, Eclipse poses a huge threat to the status quo. Once-key value-adds for vendors—Language-Aware Editors and Project, File, and Directory Management Tools—are now provided by Eclipse. Add the CDT plug-in, and now you have GDB-based Graphical Debugging and Project Management for C and C++.
The collaborative nature of Eclipse itself flies in the face of Isolationist desires to "lock in" users to their proprietary interfaces and operating systems. Users going with Isolationist vendor tools are locking themselves into a long-term relationship that will preclude any advantages offered by Eclipse. They will be limited by their vendor tools and placed on the unhealthy end of the latest development trend.
"Proprietary" vendors publicly acknowledge the Eclipse advantage while deciding which parts to replace to properly "lock in" users. These vendors replace these functionalities with their own custom code and then do not release their own code to users. Proprietary vendors define and, more importantly to the vendor, control which pieces are and are not open to users. Also, the Proprietary approach does free up some of Eclipse to the user. Some users can incorporate their own tools and scripting capabilities, but they are still locked out from any capabilities provided by the software development environment.
Naturally, the user community ends up paying for the large engineering teams necessary for these vendors to replace working Eclipse functionality with Proprietary versions. The Proprietary approach, while offering some advantages over the Isolationist, simply does not provide any cost benefit to the user and expects the user to defray the engineering cost of unnecessary proprietary functionality.
The "Truly Open" vendor acknowledges the unparalleled extensibility of Eclipse and exactly matches that openness with an equally open, customizable software development environment and integration tools delivered as full source code. Tools can be used for software development and then scaled appropriately as the product moves into integration. This allows a single interface to cover the entire design cycle. It also means that the same Eclipse interface can be used across multiple operating systems as well. If the user is providing an Eclipse-based solution to its customers, there is little difficulty with the Truly Open model adapting to suit these needs.
Embedded developers require their tools to be as customizable as their own applications and hardware. Truly Open vendors recognize and accept the custom nature of the embedded industry. The other approaches simply do not offer a cost-effective solution to this issue. In the Truly Open model, users buy once and customize forever, effectively maximizing their total tools investment and giving themselves more flexibility.
Truly Open vendors provide an Eclipse-based embedded software development solution that genuinely lives up to the open and collaborative spirit of Eclipse. This is not a model that many tools vendors prefer. As a result, these vendors are still struggling to restrain and otherwise control any access that the user gets to the vendors' tools. Truly Open vendors offer the user what the user has always wanted—an environment that is completely under user control and not at the mercy of the marketing needs of the vendor.
Reprints
