Closed for business: how open is Eclipse open source?The Eclipse platform is truly an open-source, multipurpose integrated development environment (IDE). When it's used as the basis for commercial vendor-supported products, however, the openness of Eclipse can be compromised. It takes only five questions to the vendor to find out for sure, and the answers to these questions aren't as obvious as you might think. These same five questions can be considered against the Eclipse framework itself, revealing the key advantages of modification and extensibility presented by truly open-source platforms such as Eclipse.
The first question is also the simplest one.
Question 1: Can I get the source code for the tool?
Many vendors deliver Eclipse-based products. They often provide the entire Eclipse directory tree with their product plug-ins already embedded in it. Having the product plug-ins up front saves you the time normally spent downloading and combining the various Eclipse projects and plug-ins. But does this make the product open source? Not necessarily.
In most cases, what you install is an Eclipse tree devoid of the Eclipse source code and the source code for the vendor's own plug-ins. The Eclipse source code is still downloadable from the Web, provided the vendor has adequately listed the Eclipse project version and the versions of any plug-ins shipped with its product. So where's the source code for the vendor's tools?
In truly open-source plug-ins, the plug-in source can be found in a zipped file in the vendor's plug-in directory or in an entire top-level Eclipse source code zip file. If the code isn't there, take a look at the vendor's product documentation to see if the code is available at all. Naturally the final recourse when you've looked and failed to find the source code is to simply ask the vendor, which brings us to the next of our five questions.
Question 2: Can I rebuild the product source code with my own modifications or enhancements?
When the source code actually is available, potential difficulties still lurk for the unwary user. In the RTOS world, many vendors provide the actual source code for the RTOS but without the means to rebuild it. In cases where there was some open-source reuse (such as in many GNU-based projects), the vendor may even provide you just the open-source code base that was the starting point for its product but without any of the actual modifications--often in defiance of the GNU GPL. In these cases, the source code is only good for the occasional user review. You can't use it or modify it without some significant effort. Even then, it will no longer be considered "the product" and won't be supported by the vendor.
With Eclipse, the easiest way to rebuild a project is from the original workspace directory where the product was built in an Eclipse project. You can put the workplace directory into a zipped file and deliver it with the product installation. This ensures that the project directory and associated project make files are available to you. When the vendor has modified an Eclipse component and added its own plug-ins, you'll need buildable projects for both the Eclipse component and the plug-ins.
Surprisingly, even the Eclipse organization itself does not provide buildable projects for all of its own components freely available for download to all users. The projects may be available at different levels to the Eclipse organization membership, provided your company is already a member. It's therefore easy to understand why add-on vendors may do the same thing.
So if projects to rebuild vendor products aren't available, what is a user to do? You can still choose to invest the necessary time and engineering resources to create your own buildable projects. You might also convince your company to spend the necessary money to become an Eclipse organization member. You can pay an experienced Eclipse consultant to do it for you. In many cases, you may not even need to rebuild the entire product to make changes.
Question 3: Does the product provide extension points or other means to add new functionality?
Eclipse provides the concept of "extension points," which enable some manipulation of certain aspects of Eclipse plug-ins, provided the vendor has seen fit to include them in the product. These extensions provide a "hook" for you to add your own features to the existing product without creating unsupportable source-code modifications to the product. Many standard Eclipse plug-ins provide extensions in exactly this manner. Designing and including Eclipse extension points can be more art than science and is often as complex as user-interface design. As a result, many vendors simply don't provide extensions to their product.
Some savvy vendors, seeing the complexity of including extension points, may choose to provide product-configuration files that give you some degree of modifiability and extensibility. These configuration files, however, may be limited to selecting certain predefined styles or colors for the product interface rather than enabling you to add truly new functionality. Although both extension points and configuration files could be enough for a particular user, they simply aren't a full replacement for the source code for adding new capabilities to the existing product.
Returning to the actual source code issue brings us to the next question.
Question 4: Given buildable source code, can I change or reuse basic aspects of the product Views?
In Eclipse, Views are used as a way of interacting with the user in a non–file-based manner. Views can receive input from the user and provide output data to the user but without data persistence from one Eclipse session to another. Views are therefore more often used for plug-in functionality than Eclipse Editors and indeed are simpler than a full-fledged Editor implementation. The Eclipse framework provides template Views through the plug-in development environment (PDE) and its respective plug-in wizards.
In many cases, and with the appropriate source code and the means to rebuild the code, it's relatively straightforward to make code modifications to the Views that are included in your vendor's product. This is assuming that you've got some degree of expertise with Java in an Eclipse context. If you don't have the necessary expertise (or development time) for Eclipse tools development, plenty of training or consulting help is available as well.
You may only need to modify or reuse some aspects of an Eclipse view to achieve your particular design goals. When Views aren't sufficient to achieve the desired goals, however, you must delve into our final question.
Question 5: Given buildable source code, can I change or reuse basic aspects of product Editors?
For file-based use, Eclipse provides the concept of Editors. These aren't just a way to write to a file or read from a file but a means for looking at file information in multiple different ways. A good example of a powerful and useful Editor is the standard XML Editor in Eclipse. This Editor provides multiple "views" into the file using a tabbed or multipage interface. For persistent data across multiple Eclipse sessions, a multifunction Eclipse Editor is the best way for you to add functionality. The Eclipse framework allows you to create new Editors similar to the XML Editor via the PDE wizards in the exact same manner as it does for Views.
If the code is available you can also modify the Editors used in a particular product. Editors, however, are an order of magnitude more complex than Views. Editors provide the same level of functionality as Views in addition to the requisite file-manipulation and -modification capabilities, so the code for these can be quite complex. Again, the usual internal or external development solutions can be applied to achieve your goals when modifying product Editors.
Truth in advertising
Many products, such as Wind River's Workbench, TimeSys' TimeStorm, MontaVista's DevRocket, QNX's Momentics, and Accelerated Technology's Nucleus Edge among others, are based on the Eclipse framework. Although these products are often advertised as open source because they're based on the open Eclipse framework, frequently they're not truly open source. How do you know open source from the wannabe open source poseurs? If the source code for the product or significant aspects of the product are open to user modification, the vendor has a valid open-source claim. In many cases, however, the only open-source aspect of the product is the Eclipse framework itself. It's easy to determine the extent of the truly open-source capabilities by using the five questions I've discussed in this article. Once you know extent of the product's open source nature you can take appropriate steps either within your own organization, through the vendor, or through an outside consultant. Remember when in Rome, it's always caveat emptor.
Mike McCullough is president and CEO of MCC Systems, Inc., a provider of Eclipse-based software development tools, training, and consulting services for the embedded systems market. Mike has a BS in computer engineering and an MS in systems engineering from Boston University. A 20-year electronics veteran, he has held various positions at Wind River Systems, Lockheed Sanders, Stratus Computer, and Apollo Computer. You can reach Mike at email@example.com.