Eclipse


Oracle’s recently announced a proposal to move the open source Hudson project to the Eclipse Foundation. Should your company’s stance on Jenkins or Hudson change as a result? Short answer, no. The more interesting question is what this contribution means for the Eclipse Foundation.

Eclipse contribution won’t mend the Hudson & Jenkins split
In explaining Oracle’s proposal, Ted Farrell, Chief Architect and Vice President, Tools and Middleware at Oracle, writes:

…I can’t speak for the Jenkins folks, but one of the good things about Hudson moving to Eclipse is that anyone can participate. When the fork happened, I think it came down to a difference of opinion about how to run an open source project. Oracle and Sonatype wanted more of an enterprise focus, and CloudBees wanted more of a grass-roots environment which is how Hudson came to be. I think both are valid opinions.

So when we started talking about this move to Eclipse, we initially focused on talking to people whose views were more in line with our Enterprise focus. Now that the proposal is public, we welcome anyone to join the conversation over the next 2 months while we finalize the submission and get it accepted.

Farrell makes several points that appear counter to the public record.

First, unlike Oracle, CloudBees relies on Jenkins to power a commercial product aimed at enterprises. To claim that CloudBees has anything less than an “enterprise focus” is curious.

Second, when a community around any open source product up and moves to another location, under a different project name, that’s not a fork – that’s a rebranding. Jenkins community member Andrew Bayer told InfoWorld’s Paul Krill:

The Jenkins organization on GitHub now has almost 500 repositories, the majority of those plug-ins, and almost 100 public members, while Hudson only has its core repository available and only four public members. Of the 25 most commonly installed plug-ins from before the split, 21 of them have moved primary development to focus on Jenkins, with the remaining four not having any changes during that time. In fact, 40 new plug-ins have been added to Jenkins since the split, while only one has been added to Hudson. The development community has definitely made its choice heard.

The lack of community response on the Hudson proposal mailing list at Eclipse is not a very good start for the project. Two individuals that have commented suggest they support the proposal if it will unify the Hudson and Jenkins camps. However, there’ no indication of a Hudson and Jenkins unification occurring as a result of the Eclipse contribution proposal.

Eclipse at risk of becoming a graveyard for abandoned OSS projects
Like most, I’m a big fan of the Eclipse Foundation, not simply because Ian and Mike are Canadians!

However, I fear that Eclipse is at risk of becoming a home for projects whose owners are looking to gracefully reduce their investments while gaining some open source kudos along the way.

Rewind to November 2009 when Oracle and SpringSource jointly announced the Gemini project proposal. Gemini was based on SpringSource’s DM Server technology. Two short months later SpringSource announced the Virgo project proposal to contribute SpringSource’s dm Server to Eclipse. Although SpringSource had been a big proponent of OSGi, OSGi and dm Server became less of a priority for SpringSource after it was acquired by VMware.

SpringSource tried to play up the potential for increased community contributions to the Gemini project.

However, VMware/SpringSource killed off their dm Server product as a result of contributing the project to the Eclipse Foundation. The lack of a product and revenue linked to the Eclipse project should have been a warning sign for the Eclipse Foundation.

A year and a half later, while OSGi support is offered by WebSphere, GlassFish and JBoss, and continues to gain developer attention, the Eclipse Gemini project is stuck in neutral.

Does Oracle, or more importantly, the Eclipse Foundation, truly expect a better fate for Hudson?

Oracle doesn’t have a viable business associated with Hudson. This makes any future investment decisions regarding the project at Eclipse tenuous at best. Cue the graceful exit music.

While I agree that, “if you’re going to kill it, open source it!“, I simply don’t think that the Eclipse Foundation needs to be, or should want to be, the destination of choice for these types of projects.

I hope I’m wrong about the fate of Hudson at the Eclipse Foundation. The Eclipse Foundation is too important to open source projects to become, or even just be viewed as, anything but a leading destination of choice for new and exciting projects.

Follow me on Twitter at SavioRodrigues. I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies, or opinions.”

SpringSource, a division of VMware, recently announced its intent to shift development of the SpringSource dm Server project to the Eclipse Foundation.

In analyzing the announcement, The 451 Group’s Matt Aslett wrote:

“The move to the EPL appears to be motivated by a decision that there is more to gain by encouraging wider doption of OSGi approaches through more permissive licensing and collaborative community development.”

Prior to the announcement, SpringSource offered dm Server under the GPL and a commercial license.  SpringSource now intends to shift from the GPL to the Eclipse Public Licensed (EPL) and no longer offer a commercial license.  SpringSource will offer a support subscription for dm Server instead of attempting to monetize usage through a commercial license.

I was quite surprised to hear about this business model change.  While the support subscription business model has been en vogue since the open source vendor movement began, there has been a dramatic shift towards the open core business model.  The adoption of an open core business model is predicated on the belief that revenue potential is optimized through the sale of commercially licensed products.  I remain convinced that support is not a scalable business model and does not address the issue of customers reverting into free users.  The largest and best known open source vendors have shifted away from support subscriptions to variations of an open core business model.  However, Matt used data from VC investments in open source companies to suggest:

“….that we may be starting to see a return to support and other services, rather than commercial code and licensing, as the preferred mode to monetize open source.”

Is SpringSource an example of a vendor returning to support and other services to monetize open source?  On the surface, yes.  However, I think the dm Server licensing and support changes represent a small piece of a larger vision.  When VMware announced the SpringSource acquisition, delivering and monetizing a cloud platform was a key component of their vision.  It doesn’t take a crystal ball to see that VMware is attempting to drive dm Server adoption through the Eclipse Foundation and monetize the adoption when operations team want to deploy dm Server applications on Cloud infrastructure.  The dm Server support subscriptions are a stop gap until VMware can build out their Cloud offerings and dm Server adoption increases.  This is a perfectly valid strategy, especially when considering the interest in cloud computing and open source.  However, it’s not a proof point against the open core business model.

Follow me on twitter at: SavioRodrigues

PS: I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies or opinions.”

I’ve been thinking more about the Eclipse Foundation over the past day.  As many have written, getting 33 projects, consisting of 24 million lines of code, to deliver one day is truly impressive.

What’s more impressive is the collaboration across 44 competitors and vendors with their own plans and agendas that was necessary to deliver against the release schedule.

By in large, Eclipse projects are shepherded by employees from one or more vendors whose business are tightly linked to the project.  Each of these vendors across different Eclipse projects have different business targets and customer demands they’re trying to address.  As a theoretical example, the Mylyn project, driven by Tasktop, may have been ready to launch on June 1st with key features that their customer base was looking for, while the PHP Development Tools project, driven by Zend, may have needed a few more days to pull in a whiz-bang feature.  And yet, both projects released on June 24th. (I picked the Mylyn and PHP Development Tools projects because they came to mind first.)

In the commercial software world, or when a single vendor is driving the release schedule of an open source project that they control, cross project release planning is easy, or, at the very least, easier.  Anyone working at a large software company, with different divisions on different schedules will tell you about the fun of lining up releases into a complete and integrated platform.

The Eclipse Foundation deserves the accolades it’s receiving for getting 44 vendors to march in lockstep. Eclipse remains one of the top three examples of meritocratic open source driven by an open community (Apache & Linux being the other two).

And to think, all this started as an IBM Canada project.  Happy early Canada Day (July 1st) ;-)!

Follow me on twitter at: SavioRodrigues

News out today that the Eclipse community has delivered Galileo, the 2009 Eclipse release train, made up of 24 million lines of code across 33 projects, with contributions from 380 committers and 44 companies participating.  As a product manager, I must say this is a pretty impressive accomplishment by the Eclipse Foundation and everyone involved with Eclipse. Well done!

The Galileo release offers new capabilities along these three themes:

1) Expanding adoption of Eclipse in the enterprise
2) Advancement of EclipseRT runtime technology
3) Innovation of Eclipse modeling technology

Details of each are provided below:

Expanding adoption of Eclipse in the enterprise
Adoption of Eclipse in the enterprise continues to grow.  New features in Galileo help expand the use of Eclipse by enterprise developers, including:

–    New support for Mac Cocoa 32 and 64 bit.
–    New Memory Analyzer tool to help analyze memory consumption of Java applications
–    PHP Development Tools (PDT) 2.1 is first PHP toolkit to support the new PHP 5.3 language release, including namespaces and closures.
–    New Mylyn WikiText support for editing and parsing wiki markup.
–    New XSL tooling for XSL editing and debugging.
–    Developer productivity improvements to Business Intelligence Reporting Tools (BIRT) report designer and performance.

Advancement of EclipseRT Runtime Technology
EclipseRT is the set of Eclipse technologies that provide OSGi-based frameworks and runtimes useful in building software systems. The Galileo release includes a dedicated category of EclipseRT components including elements from Equinox, RAP, RCP, Riena, BIRT, Swordfish, EclipseLink, ECF and EMF. Notable feature updates that advance the EclipseRT technology stack include:

–    Eclipse Equinox has been updated to support the draft OSGi Release 4, v 4.2 specification.
–    Target Platform provisioning support in the Plugin Development Environment (PDE) makes it easier to develop, test and deploy software to EclipseRT runtimes.
–    The Equinox p2 provisioning system has been updated to be faster, more robust and make provisioning OSGi bundles to embedded, desktop and server environments easy.

Innovation in Eclipse Modeling Technology

The Eclipse Modeling community continues to create new innovative technology for model-based development frameworks, tools and standards. Key new innovations in Galileo include:

–    Xtext, a new Eclipse project that allows for the creation of Domain Specific Languages (DSL). Xtext will create customized Eclipse editors for the DSL, making it easier for developers to focus on a smaller set of APIs and write less code.
–    Connected Data Objects (CDO) is a framework for distributed shared EMF models focused on scalability, transaction and persistence.  New enhancements in CDO include distributed transactions, pessimistic locking and save points, change subscription policies, an asynchronous query framework and security hooks in the repository.

What are you waiting for? Go download Eclipse Galileo!

Ian Skerrett just posted 6 Insights from the Eclipse Community Survey.  They’re all very interesting, but Insight #1 is really surprising.  Ian writes: “Insight #1 – Linux is doing really well at the expense of Windows.” Ian bases this on the following data:

It’s long been held that developers build applications on Windows regardless of which operating system the (server side) application will be deployed on.  This Eclipse data suggests a change might be underway.

Is anyone else surprised that nearly half (27 percent vs. 64 percent) as many Eclipse users build applications on Linux as they do on Windows?  Frankly, I’ve worked with more customers whose developers build applications on Mac OS X than on Linux; emphasis on the word “on” vs. “for”.  None the less, this data should definitely get some attention from folks over at Microsoft.

Yes, these results are based on Eclipse users and do not account for the Visual Studio developers who are 100% on Windows.  But let’s say Eclipse and Eclipse based tooling is used by (as little as?) one-third of all enterprise developers, it’s still a large enough audience that Microsoft needs to keep on Windows.  Maybe there is work that Microsoft could do to optimize Eclipse for Windows; much like Microsoft has done with PHP and Windows?

More worrisome (to Microsoft) is the fact that Linux has secured the #1 position for deployment operating systems amongst Eclipse users.  In related news, Sun Solaris/OpenSolaris fared no better, declining from 8% in 2007 to 5.2% in 2009.

My data analysis spidey senses are tingling.  I’d love to have more time with this data! But alas, life calls…

Follow me on twitter at: SavioRodrigues

Tasktop and Protecode are two interesting startups I ran into at EclipseCON 2008. They are very different businesses, aimed at very different audiences. However, both are made possible by Eclipse ecosystem….It would be very interesting to estimate the revenue opportunity that the Eclipse Foundation has opened up for vendors of all shapes and sizes.

Tasktop is based on Eclipse. The makers of Tasktop are many of the guys behind the Eclipse Mylyn OSS project. Mylyn is a task-focused UI for developers using Eclipse. Mik and team realized that the task-focused nature of Mylyn could be extended to support everyday use (outside of developers). Tasktop is able to group documents, emails and websites based on tasks you’re working on. So, for instance if I was working on a customer issue for work, researching for a blog post and writing a paper for school, I could switch between these three tasks and Tasktop would open/close the appropriate files, emails, webpages etc. based on the task I’m working on. Searching for files becomes simpler because they are associated with tasks. Also, Tasktop tracks how much time I’ve spent on a given task. I suspect there is a way to prevent Tasktop from tracking how long I spend reading FSJ and Dilbert ;-) It does a lot more, so watch this demo. While Mylyn is pure OSS, Tasktop is a commercial product for $60/year.

Protecode on the other hand has a really useful Eclipse plugin that tracks the pedigree of your code. It does so whether you import a file into Eclipse, or paste text from clipboard. The tool works unobtrusively while the developer is working away. As a result, the developer doesn’t have to remember the pedigree of a file or snippet of code 6 months later when the lawyer comes knockng. Companies can also set policies to restrict the code that can be brought into the project based on the license type (i.e. restrict GPL code usage). If you bring in code that doesn’t have a license attached to it, Protecode is able to check the code against its constantly updated collection of OSS software code. This occurs over a network connection. If there isn’t a network connection, the code is marked as “Unknown” and the developer, manager or lawyer can act on identifying the code when there is a network connection. As the use of OSS grows in the enterprise, so to does the worry of IP infringement. A tool like Protecode could become just what IT managers have been looking for. BTW, the guys at Protecode are in the midst of updating their website, so don’t let that get in the way of trying Protecode. The product is actually very cool and I can see it helping companies (and lawyers) get more comfortable with using OSS to develop their own products.

I’ll be posting interesting news from EclipseCON this week; as it happens and as I happen to hear it ;-)

The first piece of news that Ian Skerrett and Mike Milinkovich shared was the introduction of a new runtime initiative at the Eclipse Foundation. “A runtime project at Eclipse? I thought Eclipse was a home for tooling stuff.” That’s what I would have thought if I wasn’t previously aware of the Eclipse Rich Client Platform (RCP). RCP is the foundation for some IBM Lotus client-side products. Back in the day, folks at Eclipse realized that under the Eclipse tooling environment was a fairly robust client runtime environment. This client runtime had historically been used to run a tooling environment (i.e. a Tooling app). Supporting general purpose client-side applications was a natural next step.

The news today is a little different as it focuses on the server-side. The Eclipse Runtime project (Eclipse RT) is a new top-level project that will use the OSGi-based Eclipse Equinox runtime at the core of the top-level project. The Eclipse RT project will host several sub-projects that deliver runtime infrastructure based on Eclipse Equinox. The Project Management Committee (PMC) for Eclipse RT will be driven by Code 9, Innoopract, Sopera, Oracle and IBM.

OSGi is core to this announcement. OSGi is used to build several enterprise software products. I know that WebSphere Application Server v6.1 was built using OSGi, and I’ve read that BEA’s microkernel leverages OSGi. I know Oracle uses OSGi, but I can’t remember in what fashion. However, all of these uses of OSGi have been in the building of products, not the support of a new programming model. It will be interesting to see what traction OSGi gets as a programming model, and how Eclipse RT can help raise the profile of OSGi. If you’re using OSGi or interested in using OSGi, drop a comment with with you’re doing and how you think Eclipse RT can help. Better yet, get involved!

BTW, Eclipse Equinox is going up against Apache Felix, another OSGi-based runtime. I only mention it because Apache & Eclipse have been pretty complimentary (for the most part) in the past…but hey, competition is good for everyone. ;-)

Next Page »