For the Eclipse Foundation, the Juno release train represented their biggest release in history. Not only did it contain the most projects in a simultaneous release yet, it also heralded the arrival of Eclipse 4.2 as default for building applications.

The honeymoon period appears to be over, however, as community members made their discontent clear in recent weeks over the performance of the new standard platform

A mailing list thread initially started by Eclipse committer Thomas Hallgren sparked concerns amongst the community over the performance of Eclipse 4.2 against the previous incarnation 3.8.

Hallgren wrote:

For various reasons I had to switch my development environment from 4.2 to 3.8 today. I was stunned by the performance improvement after the switch. The 3.8 platform is much MUCH faster. It boots faster, it closes windows faster, it shows menus faster, etc. It also seems to consume less memory and be less buggy. The way things stand right now, there's just no way I'll switch back to 4.2!

Many others in the community echoed Hallgren’s concerns, notably Eclipse plugin developer Andrey Loskutov, who didn’t hold back in his criticism. It quickly emerged that unbeknownst to many in the community, the Eclipse Juno release hadn’t gone through performance regression testing or rigorous code coverage analysis.

Considering that the Eclipse foundation had spent the best part of a year making it clear that e4 was incoming, and the sheer number of Java developers who use the IDE, it’s quite shocking that this was allowed to occur. Granted, with such a big release, the odd bug or two is likely to crop up. But to make Eclipse 4.2 as the stable release without putting it under the most strenuous performance tests is highly questionable.

The reason for the performance testing omission? Lack of funding and resources, both of which have dogged the Eclipse foundation, since IBM reduced their input. Eclipse PMC Mike Wilson revealed back in January that his seven-strong team devoted to working on the Platform UI had fallen to three (as they sought other opportunities), leaving them inadequately prepared for the upcoming months. He rightly admitted at the time that  “three people, alone, are not enough to deliver a 4.2 of acceptable quality.”

It seems that the Eclipse Foundation is struggling to find long-term committers to the Eclipse cause. Having three people work on the core platform just isn’t enough. Does this suggest a fundamental change needs to occur within the open source foundation to allow more developers to commit full-time to core development? Whilst there are a large number of part-time committers, there perhaps needs to be more dedicated full-time developers.

Executive Director of the Eclipse Foundation Mike Milinkovich was equally shocked by the performance findings, stating that this was the first he’d heard of the situation last Wednesday. In a call-to-arms blog post, Milinkovich addressed the problem and what he deemed “very valid concerns”.

“My personal summary of where we’re at is that Juno is on 4.2, and it’s far too late to talk about switching the release train back to 3.8,” he said adding that the next release train Kepler would be based on 4.3 and not Eclipse 3.9 to be based on 4.3. That is to be expected as turning back makes little to no sense at this point, given the expenditure put in.

Milinkovich reiterated that “the Eclipse platform team has a serious resource issue,” and that the only way to overcome it was through people or organisations stepping up their contributions. This is of course the nature of the beast with open source foundations - you are reliant upon the donations of others.

At least this debacle appears to be the catalyst for further donations. Already Google’s Open Source Programs Office have offered $20,000 to purchase needed hardware to test 4.2, but also to build a common testing lab to tackle issues within Eclipse’s common build infrastructure. According to Milinkovich, this is just the first of several offers for help (and cash).

“A few people and companies have quietly approached us about where they can best put their resources to help. The entire staff of the Eclipse Foundation is going to pitch in to help resolve these issues as much as we can,” he said.

Shipping a release of Juno’s scale is hard and it is to be expected that issues arise in the immediate aftermath. But this situation reveals something much more critically wrong at the centre of Eclipse. For the Eclipse Foundation to continue growing, it needs the companies that are so reliant on their Java-based tooling to step up and not only consume, but contribute.

What do you make of this Eclipse 4.2 scenario? Give us your view below...