Eclipse in Embedded Survey
I recently came across a link to a survey report on Eclipse usage in the embedded space on Chris Lanfear’s blog. The most exciting conclusion of this survey is that Eclipse usage among device software developers has grown from 1% to 17% in the past two years and is expected to be almost 50% two years from now. Clearly this is an excellent rate of adoption. The survey goes on to describe Eclipse usage breakdown by vertical markets, developer opinions of Eclipse tools, developer demographics, vendor integration, purchase decisions, and target operating system support. A few specific items jumped out at me, and I describe them below.
Vertical Markets. Below is a chart made from data in the report. It shows current and 2-year expected usage of Eclipse Tools by vertical market. (Presumably respondents were allowed to select more than one market for their development work.)
While the growth in expected usage for almost all of the markets is great, the mobile phone vertical really jumped out at me because it mirrors the growth in DSDP’s projects. Four of the DSDP projects have specific focus on the mobile space, phones or otherwise – eRCP, MTJ, NAB, and TmL. I am confident that these projects are currently building or have plans to build the underpinnings of this adoption.
Developer Opinion. The report states, “On a case-by-case basis reactions to Eclipse-based tools are quite mixed, with many users reporting decreased levels of satisfaction with their Eclipse-based tools.” The survey respondents average 3.5 out of 5 when rating their Eclipse tools favorably relative to their previous non-Eclipse tools (3 was neutral). I believe this is a reflection of the maturity level of both commercial embedded products based on Eclipse and open source embedded projects. Contrast this with the satisfaction around Eclipse-based Java development tools, which are much more mature. I would expect similar survey results from the other newer technical verticals in Eclipse. Ultimately, though, one can view this as good news because the high Eclipse adoption rates in the space will drive the quality up, both commercially and in open source.
Vendor Integration and Purchase Decisions. The report states that the integration of tools from multiple vendors is not a big driver when developers select Eclipse-based tools. Instead, the primary drivers are 1) that the commercial tool is based on open source technology and 2) that the tool is supplied by the developer’s preferred vendor. Given the plugable nature of Eclipse, I find this survey result surprising, as did the authors. I believe there are two explanations. First, embedded developer adoption has just started, so those developers are just beginning to see the compatible commercial and open source offerings available to them. Second, as I discuss below, the report points out that many commercial solutions are forking and heavily customizing stock Eclipse, which may lead to either real or perceived lack of plugability.
Target Operating System Support. The report states, “Most developers currently using Eclipse-based development tools are developing products that utilize a commercial or open source operating system. Going forward, however, Eclipse-based tools will also be used more commonly in the production of devices using both proprietary operating systems and no formal operating system.” I have some trouble with this conclusion at the technical level because it requires end-users of commercial Eclipse products to staff Eclipse developers in order to build custom support for their in-house proprietary operating systems, especially in the area of debugging. While this is certainly in the spirit of Eclipse extensibility, it runs counter to my experience that customers are actually looking for turn-key solutions rather than solutions that require a heavy amount of customization on their part. Perhaps it’s more accurate to say that companies will experience a partial adoption of Eclipse for their proprietary operating systems, whereby they use some of the IDE capabilities while still relying on their non-Eclipse tools for debugging and analysis of their proprietary operating systems. I will comment on this in future blog entries as I get more data.
Final Thoughts. With respect to device software tool vendors that are avoiding Eclipse, the report states, “Issues such as maturity of technology, vendor customization, fragmentation or forking risks to meet the needs of both the enterprise and embedded segments, and the openness of individual solutions are often raised as risks that have not been suitably addressed.” While there are few major device software companies who haven’t adopted Eclipse at this point, the concerns raised are still important. Some comments:
- The need for openness, collaboration, and common base technology in the device software space is real, and it’s one of the driving factors behind the projects in DSDP and their attempts to bring together multiple vendor solutions.
- “Customization, fragmentation, and forking” means modifying dependent Eclipse projects, not keeping up with the latest versions of dependent projects, violating open API’s, or not supplying your product as a plug-in to existing Eclipse installs. Vendors that avoid these pitfalls will be the most successful in their commercial offerings.
- Commercial solutions should follow the Eclipse open and extensible API model for their IP: build open, proprietary API’s to allow partner and customer integration with commercial IP built on top of Eclipse. In this case, the API is open, but the implementation is IP. After all, what’s proprietary today may eventually be open tomorrow.