At the last Eclipse Architecture Council meeting, I said that we, the Eclipse Project, thought that our ability to deliver the Eclipse SDK R4.2 as part of Juno was at risk. I am happy to say that we have been able to re-align our development effort, and now expect to deliver Eclipse SDK R4.2 as part of Juno. I wanted to talk briefly about how we ended up in this situation, and then cover the highlights of what we are doing to mitigate the risk.

Almost all of the new work in 4.2 is focused around the Platform UI team. When the planning for Juno started, there were 7+ people working (for me) full time on that team. Since then, a number of individuals have left the team to pursue other opportunities. Each time this happened, we looked at what needed to be done, how many people were left, whether we could pull in someone from somewhere else to help, and in the end managed to convince ourselves that a successful delivery was possible.

Last week, two more people told me that they had decided to leave. This left us with just 3 developers working on Platform UI, and that's when I brought the situation up with the EAC; three people, alone, are not enough to deliver a 4.2 of acceptable quality.

Since then, I have worked with the remaining UI team members and the Eclipse PMC to come up with a plan which we believe will allow us to succeed. The highlights of this plan are:

We looked at the other component teams to see whether there was work that could be delayed to free up resources to join the UI team. Because we believe it is critical that 4.2 be part of Juno (see below), this trade off made sense, even though it left some other teams with effectively no active developers. [Even so, we could only add two new people this way, and they will take time to ramp up.]

We took many of the "peripheral" tasks that people from the UI team were working on (e.g. builds, legal/IP, internal company interactions,...) and moved these to others elsewhere on the team.

We made some hard decisions about where to focus our resources. For example, we decided that providing API for the new capabilities of 4.x would have to happen post-4.2. Working on solid backwards compatibility and performance need to be our first priorities.

Some might argue that it would be better to simply release 3.8 into Juno and move ahead with the 4.x stream in a follow on release. Honestly, I believe this would be catastrophic for our community. The Juno simultaneous release is going to be the basis for both the first Eclipse Long Term Support and first Very Long Term Support offerings. Given that, plus the overall maturity of Eclipse and the requirements of many of the large organizations that are participating, I see the Juno release as being extremely important. If we are unable to deliver 4.2 in Juno it would mean that a huge segment of the community would not be able to take advantage of the new features it provides, but more importantly they would be building on a code base that we know needed to be replaced -- that was, after all, the impetus for the 4.x work in the first place. It would literally mean that it would no longer be possible for the Platform (that we all build on) to adapt to the changing needs of modern, desktop applications. And this, more than anything I can think of, would jeopardize the future of Eclipse on the desktop.

In the end, what's clear to me out of all of this is that the Eclipse Platform UI team, and indeed the Eclipse Project as a whole, *needs* more non-IBM committers now. And by that I mean more, *active*, "working on the SDK for the good of the community in general" people. All those arguments about lack of diversity on the Eclipse Project are coming home to roost: It is clear now, that the remaining IBM Eclipse committers are too few to support the entire SDK. It is a virtual certainty that we will see more situations like we did recently with the Platform User Assistance team; that is, we will get to the point where there are no longer *any* active committers left on some areas of the SDK. I tell you truthfully, I am committing all of the people that I can to working on the SDK, but if we (the Eclipse community) care about Eclipse having a future on the desktop, other resources need to be found. There is still calendar time for you to have a positive impact on the Juno release if you wish to participate.