A Realistic Look at the State of Eclipse
Jens Eckels
June 30, 2006
It's time to take a long, hard, realistic look at Eclipse. As alternative IDEs grows in popularity and function, it's relevant to explore the effects of this environment on the Eclipse ecosystem, and how best to face the challenges posed by Sun/NetBeans and others.
Ok - so Eclipse doesn't have the same sexy, out-of-the-box appeal that some other IDEs deliver. Environments like NetBeans look great, have smooth functionality (for the most part), and are wrapped in a pretty package. If we look only at pink and lace, NetBeans beats Eclipse. But the question is, does NetBeans have the power and steam behind it to take it to the next level of adoption, and more importantly, should Eclipse follow Sun's footsteps by focusing on end user out-of-the-box experience instead of the less glamorous platform or ingredients inside? The short answer is, “HELL” no.
The long answer is rooted in the need to resist the temptations to take this competition personally and to slide into a tit-for-tat feature war that will ultimately cannibalize the true power behind Eclipse; its ecosystem. After all, Eclipse is much more than a single application or a free IDE. It's the standard for open source toolkits, and the one already adopted by enterprises of all sizes. The recognition by these companies that the current and potential ingredients that make up Eclipse are superior to any single application (including Netbeans) is already well demonstrated. Eclipse is quickly becoming the base ingredient for all but a small set of development environments, and is not (nor is it intended at this point) to be a complete end product. It's designed to be a plugin-friendly, customizable, and functional solution for tools and Rich Client Applications; the key reason for adoption by the Enterprise.
The brainpower (139 independent members of the Eclipse Foundation and counting) behind Eclipse is overwhelming, and the Eclipse add-in community seems to grow on a daily bases. This collective “power of the many”, when viewed as an ecosystem, gives Eclipse a significant advantage over any one organization or product. When most companies look at their development choices, they are naturally drawn towards the product with the greatest, value, flexibility, efficiency, and evolutionary potential. Eclipse developers all over the world are making useful and advanced tools that further enrich the options available to their fellow developers. Current estimates show Eclipse at over 50 million downloads, and the availability of over 1200 commercial plugins. No other platform can come close to such claim.
Despite all of this potential and apparent positioning as the environment of choice, why are competitive IDEs able to survive against Eclipse? Part of it has been superior marketing campaigns by companies like Sun and the NetBeans project. Their evangelists have simply done a fabulous job of redefining the rules of competition, and Eclipse has in my opinion failed to promote the combined power of the platform and the ecosystem. Evans Data's latest survey, for example, concluded that Eclipse trails other IDEs in feature sets. Developers rated it last when it comes to features, which is a preposterous statement when taking into consideration more than 1000 feature extensions for the Platform. Trends in searches, blogging, and virtual buzz show that Eclipse has maintained only a flatline market share over the past 12 months (though a sizable increase is seen in traffic for Eclipse 3.2). Surprisingly, IDEs like NetBeans have also been fairly flat, showing only slight growth.* Recent analyst estimates state that half of all IT houses** and two-thirds of Java shops*** utilize Eclipse-based tools. This means Eclipse enjoys a huge, apparently loyal market presence, but the Eclipse Foundation, hindered in my opinion by the “not invented here” mindset, has not adequately taken steps to assert themselves as the clear leader in the marketplace. Eclipse plus a handful of plugins is unequaled in the tools market. This recipe can be repeated indefinitely in any tools specialization and if done properly will change the competitive picture once and for all. But, this may require a new way of thinking.
Eclipse will need to refocus their approach back to the roots of Eclipse; providing the quality platform for others to build upon. To accomplish this, it seems that the Foundation will need to explore embracing the plugins offered by the community to enrich the functionality of Eclipse at the core, in addition to the flexibility of Eclipse as a tool you can plug your favorite features into. Eclipse has provided the platform for construction, and many outstanding tools have been built on its foundation. If the collective thought behind the innovations in the ecosystem is reintegrated in to the base Eclipse platform, it would increase functionality, feature sets, and user experiences several fold. The more advanced the platform, the more likely it is that the tools created on top of it will be even more innovative, creating cyclical evolutionary advances.
But how could this be accomplished? An option may be allowing users to register their tested and proved plugin as part of the Callisto installer. This method of delivery (introduced with Eclipse 3.2, which is slated for GA release on June 30) is both efficient and controllable, and would allow the community the immediate benefit from new features. In this model, EPIC (Eclipse Plug-In Central at http://www.eclipseplugincentral.com – a centralized resource for Eclipse plugins recently placed under the management of the Eclipse Foundation) may emerge as a valuable tool to qualify plugins and features prior to inclusion. In addition, this approach would allow the Eclipse Foundation to proactively recognize and promote its own members – something it should inherently be pursuing.
Promoting this type of infrastructure will also require rekindling the meritocracy of open source. As an example, several top-level Eclipse features lack the same quality standards as the platform SDK, but continue to be promoted as the premiere tools despite superior comparable community add-in plugins or extensions. In order to satisfy customer demands both in commercial extensions and the extensible tools platforms, Eclipse will likely need to begin exploring the external tools available (even in competitive platforms) to enrich end user experience and to demote dangerous “must be invented here” ideologies that are at the heart of mediocrity.
Playing devil's advocate against the community-input-is-better concept, entities like NetBeans can/do/will protest “all of our IDE is free, the extended Eclipse community isn't always.” This is true (though Eclipse itself is always free). But this assumes that free tools are adequate for everyone. Factoring in Enterprise needs for support, a larger community provides a greater choice for companies and sets the rules for healthy competition without having to give up open standards or an arm and leg for them. If you want to get down and dirty, the large Eclipse community has your back as opposed to a single entity.
To coin a perhaps overused cliché; it now takes a village to gain an advantage in the world of development tools. When one looks at the balance sheet of companies such as Sun (in both dollars and in talent resource) compared to the “village” of Eclipse, there is no competition. If some of the changes mentioned above were to be implemented, I believe we'd see a growth in the Eclipse ecosystem beyond anything we have imagined, and beyond what any other IDE is currently capable of offering.
This ARTICLE is no way an attack against the EMO. The foundation has done a good job of in marshaling resources and spreading the word about Eclipse. However, new plateaus require sincere introspection, and in some cases asking if the emperor indeed has any clothing.
Google Trends and Technorati keyword/tag histories
Forrester Analysts, July '05
Interarbor Solutions Analysts, June '06
Ok - so Eclipse doesn't have the same sexy, out-of-the-box appeal that some other IDEs deliver. Environments like NetBeans look great, have smooth functionality (for the most part), and are wrapped in a pretty package. If we look only at pink and lace, NetBeans beats Eclipse. But the question is, does NetBeans have the power and steam behind it to take it to the next level of adoption, and more importantly, should Eclipse follow Sun's footsteps by focusing on end user out-of-the-box experience instead of the less glamorous platform or ingredients inside? The short answer is, “HELL” no.
The long answer is rooted in the need to resist the temptations to take this competition personally and to slide into a tit-for-tat feature war that will ultimately cannibalize the true power behind Eclipse; its ecosystem. After all, Eclipse is much more than a single application or a free IDE. It's the standard for open source toolkits, and the one already adopted by enterprises of all sizes. The recognition by these companies that the current and potential ingredients that make up Eclipse are superior to any single application (including Netbeans) is already well demonstrated. Eclipse is quickly becoming the base ingredient for all but a small set of development environments, and is not (nor is it intended at this point) to be a complete end product. It's designed to be a plugin-friendly, customizable, and functional solution for tools and Rich Client Applications; the key reason for adoption by the Enterprise.
The brainpower (139 independent members of the Eclipse Foundation and counting) behind Eclipse is overwhelming, and the Eclipse add-in community seems to grow on a daily bases. This collective “power of the many”, when viewed as an ecosystem, gives Eclipse a significant advantage over any one organization or product. When most companies look at their development choices, they are naturally drawn towards the product with the greatest, value, flexibility, efficiency, and evolutionary potential. Eclipse developers all over the world are making useful and advanced tools that further enrich the options available to their fellow developers. Current estimates show Eclipse at over 50 million downloads, and the availability of over 1200 commercial plugins. No other platform can come close to such claim.
Despite all of this potential and apparent positioning as the environment of choice, why are competitive IDEs able to survive against Eclipse? Part of it has been superior marketing campaigns by companies like Sun and the NetBeans project. Their evangelists have simply done a fabulous job of redefining the rules of competition, and Eclipse has in my opinion failed to promote the combined power of the platform and the ecosystem. Evans Data's latest survey, for example, concluded that Eclipse trails other IDEs in feature sets. Developers rated it last when it comes to features, which is a preposterous statement when taking into consideration more than 1000 feature extensions for the Platform. Trends in searches, blogging, and virtual buzz show that Eclipse has maintained only a flatline market share over the past 12 months (though a sizable increase is seen in traffic for Eclipse 3.2). Surprisingly, IDEs like NetBeans have also been fairly flat, showing only slight growth.* Recent analyst estimates state that half of all IT houses** and two-thirds of Java shops*** utilize Eclipse-based tools. This means Eclipse enjoys a huge, apparently loyal market presence, but the Eclipse Foundation, hindered in my opinion by the “not invented here” mindset, has not adequately taken steps to assert themselves as the clear leader in the marketplace. Eclipse plus a handful of plugins is unequaled in the tools market. This recipe can be repeated indefinitely in any tools specialization and if done properly will change the competitive picture once and for all. But, this may require a new way of thinking.
Eclipse will need to refocus their approach back to the roots of Eclipse; providing the quality platform for others to build upon. To accomplish this, it seems that the Foundation will need to explore embracing the plugins offered by the community to enrich the functionality of Eclipse at the core, in addition to the flexibility of Eclipse as a tool you can plug your favorite features into. Eclipse has provided the platform for construction, and many outstanding tools have been built on its foundation. If the collective thought behind the innovations in the ecosystem is reintegrated in to the base Eclipse platform, it would increase functionality, feature sets, and user experiences several fold. The more advanced the platform, the more likely it is that the tools created on top of it will be even more innovative, creating cyclical evolutionary advances.
But how could this be accomplished? An option may be allowing users to register their tested and proved plugin as part of the Callisto installer. This method of delivery (introduced with Eclipse 3.2, which is slated for GA release on June 30) is both efficient and controllable, and would allow the community the immediate benefit from new features. In this model, EPIC (Eclipse Plug-In Central at http://www.eclipseplugincentral.com – a centralized resource for Eclipse plugins recently placed under the management of the Eclipse Foundation) may emerge as a valuable tool to qualify plugins and features prior to inclusion. In addition, this approach would allow the Eclipse Foundation to proactively recognize and promote its own members – something it should inherently be pursuing.
Promoting this type of infrastructure will also require rekindling the meritocracy of open source. As an example, several top-level Eclipse features lack the same quality standards as the platform SDK, but continue to be promoted as the premiere tools despite superior comparable community add-in plugins or extensions. In order to satisfy customer demands both in commercial extensions and the extensible tools platforms, Eclipse will likely need to begin exploring the external tools available (even in competitive platforms) to enrich end user experience and to demote dangerous “must be invented here” ideologies that are at the heart of mediocrity.
Playing devil's advocate against the community-input-is-better concept, entities like NetBeans can/do/will protest “all of our IDE is free, the extended Eclipse community isn't always.” This is true (though Eclipse itself is always free). But this assumes that free tools are adequate for everyone. Factoring in Enterprise needs for support, a larger community provides a greater choice for companies and sets the rules for healthy competition without having to give up open standards or an arm and leg for them. If you want to get down and dirty, the large Eclipse community has your back as opposed to a single entity.
To coin a perhaps overused cliché; it now takes a village to gain an advantage in the world of development tools. When one looks at the balance sheet of companies such as Sun (in both dollars and in talent resource) compared to the “village” of Eclipse, there is no competition. If some of the changes mentioned above were to be implemented, I believe we'd see a growth in the Eclipse ecosystem beyond anything we have imagined, and beyond what any other IDE is currently capable of offering.
This ARTICLE is no way an attack against the EMO. The foundation has done a good job of in marshaling resources and spreading the word about Eclipse. However, new plateaus require sincere introspection, and in some cases asking if the emperor indeed has any clothing.
Google Trends and Technorati keyword/tag histories
Forrester Analysts, July '05
Interarbor Solutions Analysts, June '06
Print
Email
