LICENSING IS IMPORTANT
It's worth discussing licensing details because of the way that Eclipse can be used. Most IDEs are owned by a specific company and they jealously guard the source code and distribution rights of the IDE, which is not the case with Eclipse. It has an extremely liberal licensing policy, allowing it to be turned into a closed-source product or a mixed-source product where proprietary components are distributed in binary form only. This can have a number of benefits for developers, as the proprietary components should work with any Eclipse implementation. Likewise, plug-ins designed for the generic Eclipse platform should work with the proprietary implementation.
IDE vendors using Eclipse benefit as well. Eclipse may not be at the top of the list for third-party plug-in developers right now, but it will be eventually. Previously, getting third-party support of an IDE took a good deal of negotiation and support on the part of the IDE vendor. This tended to limit the number of plug-ins available.
Finally, Eclipse can be used as an application platform. In many instances, companies might not want to distribute the source code for Eclipse or for their customization. The Eclipse licensing allows this to happen. In fact, many companies will want to take this approach not to keep things private, but to reduce tech support calls from overzealous users with programming experience. Still, it can be a useful bargaining tool if the source can be made available upon request.
LITTLE IDEs STILL SURVIVE
The type of IDEs discussed thus far are what most developers employ for 32- or 64-bit platforms. Some 8- and 16-bit IDEs retain the simplicity of earlier tools, foregoing integration with more advanced plug-ins. These are often used when projects are smaller, such as a single developer working on a single 8-bit microcontroller.
In other cases, these IDEs are a stepping stone to more functional products that can be utilized when a project becomes larger and more complex. For example, Microchip's PICkit 1 is a starter kit with the MPLAB IDE. It's possible to move to more sophisticated toolsets that include ICE (in-circuit emulation) support.
More compact IDEs aren't always spartan text editors. Features like color-coded text and real-time, context-sensitive tips are always creeping in. Still, one reason for these IDEs is the limited resources available to create them. Another is the availability of open-source IDE platforms like Eclipse and KDevelop.
SHUTTING DOWN
Proprietary IDEs remain important because of features they provide. For instance, many DSP IDEs offer data graphing facilities like Texas Instruments' CodeComposer Studio (Fig. 3). These types of features will eventually find their way into other IDEs, but until more companies move to open platforms like Eclipse there will be a need for vendor-specific IDEs.
Most developers tend to prefer the flexibility of the larger, more robust environments like Eclipse. It will be interesting to see how other IDEs will fare versus Eclipse given its open-source nature and the support it's received. Developers are already pressed for time, so the ability to use the same development environment for a number of projects can have significant benefits.