越来越多的嵌入式开发人员正在转向采用开放源工具来构建可靠与灵活的系统和软件。开放源代码既可以提供构建系统软件和应用程序所需的原材料，也可以为此提供开发工具。特别是象Eclipse和GNU工具集这样的开放源开发工具，开发人员可以对其进行定制与扩展，以满足项目的精确需求。不仅如此，许多嵌入式开发商采用了多种开放源工具，以此作为更全面的开发环境的基础。
Eclipse就是这样一种开放源集成化开发环境(IDE)。Eclipse基金会正在对Eclipse平台及其相关技术进行开发。该基金会是一个由软件公司组成的非盈利性团体，致力于利用共享技术和贡献技术以供共享。
Eclipse目前的开发项目以及潜在的新项目
Eclipse平台在嵌入式设计与开发领域的应用主要受两大因素推动：平台的成本与灵活性、共享技术贡献者与插件提供商的社群规模。如今，嵌入式供应商不是在抢搭Eclipse这趟车，就是在为不跟风找出正当理由。一旦置身其中，他们就会想方设法地利用免费的开发源软件来赚钱。
Eclipse开发工作围绕若干不同项目而展开，这些项目包括设备工具项目(Device Tools Project)、数据工具项目(Data Tools Project)和网络工具项目(Web Tools Project)。这些项目的启动时间各不相同，版本号也不一致，并且在过去的开发中，彼此之间极少协调。举例来说，某家供应商可以自己针对这些组件的特定版本来测试和推出工具，但与此同时，这家供应商也会面临很大压力，因为很难保证其插件与基本需求不同的其它供应商的插件兼容，或是与Eclipse平台本身的后续版本兼容。
捆绑系统方便工具集成
随着业界纷纷为Eclipse平台灌注热情，并快速推进开发工作，一些复杂问题也应运而生。所幸的是，一种代号名为Callisto的捆绑系统可以解决这些问题，并将于今年夏天推出。该系统涉及到多个项目之间的协调，这些项目由不同公司领导，并吸引了数以百计的成员公司和数以千计的贡献者的参与。
Callisto系统将结合Eclipse平台与若干插件。它还有助于供应商对工具进行集成，因为集成工作可能需要添加一长串名单的组件，而这些组件对测试版本而言必不可少，以便开发商交付产品并提供技术支持。一旦具备在准备就绪时添加Eclipse插件和新构件的能力，供应商在扩展能力方面的承诺与版本控制的现实之间，又会面临着微妙的分界线。
公平地说，有不少供应商的工具与多种版本的Eclipse平台及相关插件都兼容。而Callisto为使用Eclipse的供应商赋予了确保其插件与其它改进全都能运行在兼容的配置上的机会。例如，在Eclipse 3.2平台就绪大约仅三个月之后，实时操作系统开发商QNX公司就计划交付基于该平台的Momentics工具。如果一些低层依赖关系不与基础平台同时升级，那么，就很难做到这一点。
QNX研发工具开发总监Derrick Keefe透露，该公司是Eclipse基金会的创始会员。他表示：“这完全是为了节省成本。我们原本就没有必要建立和维护自己的基金会，但我们早就就看到了Eclipse的潜力，并成为其中一员。”
众多象QNX这样的供应商发现，Eclipse能让他们专心做自己擅长做的事情。而他们面临的问题是，要如何评定软件平台与专业技术相结合的价值与价格？
用户是赢家
无论如何，赢家是用户。目前还不清楚免费软件是否带低了工具价格，但它毕竟方便了用户的选择。虽然现实可能不如理想，但大多数使用Eclipse的嵌入式开发商都能够利用特定配置的优势，因为这些特定配置比任何通用工具集更能满足他们的要求。
迄今为止，大多数嵌入式开发人员都听说过Eclipse。对于这些用户而言，Eclipse的优势显而易见：完全免费，且可自由下载；下载版本就可对其进行升级；在Java环境中运行，这在理论上使之可通过多种平台来访问，如大多数开发商所瞄准的Windows、Solaris和Linux这样的通用平台和操作系统。
任何一种实现为Eclipse插件的工具都可以被方便地安装到该环境中，所以，与C/C++、Java编译器和其它工具一起提供的QNX Momentics，只要被放置在开发机的合适目录中，就可以对Klocwork静态分析工具等组件构成很好的补充。
很少有嵌入式供应商提供面向团队开发和源代码控制的工具。但配备Eclipse插件的工具数量很多，丰富了开发人员的选择范围。Eclipse配备面向并发版本控制系统(CVS)的客户端插件，而CVS是一种开放源系统，可通过GNU通用公共授权条款获得授权。
应该指出的是，许多面向普通Java开发人员的第三方Eclipse插件，实际上对用C++构建远端目标而言并无裨益。但是，开发第三方Eclipse插件的社群正在膨胀。例如，今年在美国加州召开的EclipseCon研讨会吸引了1,400多名Eclipse会员和用户的参加，而这一数字在2005年仅为约1,000人。这显示Eclipse开发群体的规模在不断扩大。
大多数软件开发都免不了得失权衡(trade-off)。从短期效果来说，采用Eclipse可帮助工具供应商降低成本，因为该平台提供了构建一个IDE所必需的大部分基础组件。如果提供IDE或开发工具套件的其它供应商都沿着Eclipse路线发展，那么也就构成了一项竞争优势，在这方面，QNX、Accelerated Technology和LynuxWorks的实例就能提供证明。
但另一方面，构建一个提供许多公共用户接口、连接特性、可扩展性并支持多操作系统的平台也是一项关系重大、代价昂贵的事业，而这项事业对供应商的核心专业技术并无贡献。尽管对于Eclipse而言，它也可以促成许多基于公开的通用基础组件的特定解决方案。
多年来，开发工具供应商一直在孜孜以求心目中的圣杯(holy grail)：一种涵盖产品设计直至制造的逻辑工具链。这一度意味着要单独构建或购买所有的组件，并将它们汇聚到一个专有的框架之中。或者，更糟糕的是，从用户的立场看，根本就不去汇聚这些工具，而是提供具有不同用户接口的工具，只不过需要明确这些用户接口。
在Eclipse萦绕的背景下，供应商面临的情况较为复杂，嵌入式用户面临的情况则较为直接了当。供应商不需要完整工具链，但却需要促成完整工具链。而采用Eclipse来主导一个开发环境，就象QNX、Wind River和Accelerated Technology正在做的那样，可以让开发人员根据其独特需求来增添其它工具。任何意味着停止向该平台添加其它工具的变化，都很可能招致用户的反弹。
许多用户已经在利用Eclipse所提供的灵活性，或者准备着手加以利用。此前参加EclipseCon研讨会的一家小型设计工作室的开发人员Don Weldon说：“我在Eclipse上汇聚了自己的一套开发工具。它贴合我的需求，而且我很清楚地知道如何使用它。”
Eclipse软件开发套件(SDK)已经添加了Java开发工具、插件开发环境和Eclipse插件工具。所有组件结合在一起，就形成了Eclipse SDK，也就是一种包含基于Eclipse的工具和插件，以及Eclipse本身的开发环境。
作者：Peter Varhol
自由技术撰稿人