Life at Eclipse

I have a bit of sad news, which is that Barb Cochrane of the Intellectual Property Management team is leaving us, effective Friday. Barb has been great to work with for the past three years. She added a lot of fun and enthusiasm to both the office and the community, and was incredibly diligent and professional in her work. A great combination! She will definitely be missed by all of us at Eclipse.

After talking with Janet Campbell, we’ve decided that for at least the next few months we’re not going to replace Barb’s position. The tasks of recruiting and training a replacement would only slow the team down further as we head into the busiest time of the year for IP reviews. For projects which are part of the Indigo release train we highly recommend getting your CQs in earlier rather than later, carefully considering whether you truly need to packages you’re asking for, and be darn sure you make it clear that you need the CQ for Indigo. Janet will be communicating deadlines and progress through the normal channels as we get ready for the release train.

So Barb: so long and thanks for all the shwarma!

Neil Bartlett asked me on Twitter a few days ago why the Eclipse Foundation was supporting the JSR for SE8, given that this JSR is “anti-OSGi”. That is a very good question.

I believe that Neil and others are basing their “anti-OSGi” read of the JSR based on Section 2.1’s description of modularity. “OSGi already does this” being the operative phrase. Of course, OSGi already does this stuff and could easily be the solution for the set of described requirements. However, I also believe that if you read the section purely from the perspective of the status quo which exists today for the JDK, all of the statements there are perfectly valid. The point made in Section 2.5 illustrates this further: “Existing [modularity] frameworks and tools support these tasks today, but standardization in the Java SE Platform would promote interoperability and benefit developers, users, and vendors.”

But the statement in the JSR which ultimately drew our support is in Section 3 (emphasis mine):

In the case of the proposed Java Platform Module System JSR, it is understood that there is already a significant investment within the Java community in applications and frameworks built using the module layer of the OSGi Service Platform. The extent to which the Java Platform Module System should adopt, interoperate with, or otherwise accommodate OSGi will be a topic for that JSR’s Expert Group and the Java SE 8 Expert Group to discuss and decide.

The bottom line is that this JSR (well actually the still-to-be-established JSR focused on modularity) represents the beginning of a conversation about the shape of modularity in the base Java platform. This conversation is going to take something on the order of one or two years to complete. We are supporting this JSR because it is the forum for that discussion. But if the end result is “anti-OSGi”, I’ve already made it clear that we will be voting against it. And although no one else has publically committed to a position, I think we will be in good company in doing so.

I should also be clear on what I mean by anti-OSGi. I haven’t spent a ton of time thinking about this, but at the moment my perspective is that the bottom line is the existing OSGi ecosystem must be able to continue operating on SE8 without any interruption. Further, OSGi cannot be disadvantaged by platform modularity in terms of performance or scalability. But I have heard enough comments from very competent Java developers who are unhappy with OSGi that I don’t believe that in its current form it is perfection personified. So perhaps there will be options along the lines revisions to OSGi specs, an inter-operability story or some other solution beyond the scope of my imagination or technical abilities. So “anti” does not equal “use OSGi in its current form or else” in my view.

I am not so naive as to think that this is going to be easy. Mark Reinhold and others at Oracle have made it pretty clear that OSGi in its current form is not the solution that matches their vision for platform modularity. To change this is going to require persuasion on both the technical and ecosystem/business benefits of OSGi. I use the word “persuasion” very consciously because I believe that the name calling and negative emotion which have been part of the modularity debates (on both sides) over the past couple of years have not, in my view, been helpful. We (the OSGi) community have one last kick at this can. This is it.

Eclipse Summit Europe is only a few short weeks away. ESE and EclipseCon (EC2011 call for papers is open!) are definitely the two funnest and busiest weeks of the year for me.

Thanks to the Program Chair, Bernd Kolb of SAP and his hard-working Program Committee, this year’s ESE promises to be the best ever. The keynotes alone are going to be hard to beat. In order of appearance we have:

• Dr. Hendrik Speck (University of Applied Sciences Kaiserslautern) on “Code and Belief“. I saw Dr. Speck speak at an event in Berlin a few months ago and thought his talk was extremely thought provoking.
• Dr. Jeff Norris (NASA) on “Mission-Critical Agility” will reprise his incredible talk from EclipseCon 2010 — one of the best talks I have ever seen.
• Dr. Gunter Dueck (IBM) on “The Industrialization of the Services Sector“. I haven’t had the opportunity to see Dr. Dueck speak before, but I’ve heard from several people that he is excellent as well.

In addition, the main technical program has something in it for every budding Eclipse aficionado. There are five tracks, all of which are offering two full days of great talks: Eclipse 4.0 (e4), Embedded, Modeling, Runtime and Other / New & Noteworthy.

Putting on events and conferences is a large part of what we do at the Eclipse Foundation. They are a ton of work, but are absolutely worth it in every way. Each event provides an opportunity for our worldwide community to come together, meet, talk and maybe have a couple of beers. So register now. I find ESE in particular to be a great community event: great technical content with a relaxed and cool vibe. I really hope to see you there!

Oh, and thanks to all of our sponsors! We literally could not do it without you.

Today’s announcement that IBM is going to join forces and work with Oracle on OpenJDK is good news for Java, and by extension for Eclipse. All of us who live within the Java ecosystem need to recognize that this fundamentally strengthens the platform, enhances the business value of Java and offers the hope of an increased pace of innovation.

Although it will take a while for all of the ramifications and reactions to become clear, at its face the announcement challenges the conventional wisdom that the future of Java is going to be a fractured one. Some recent examples of these expectations can be seen in blog posts like James Governor’s “Java: The Unipolar Moment, On distributed governance for distributed software” and Joseph Ottinger’s “The Future of Java: forking, death, or stasis”. When I read them just a short time ago, I thought they accurately reflected the likeliest outcomes for Java’s sure-to-be fractious future. Now I am much more optimistic that we can get back to innovation.

To me the overarching motivation is obvious. Both IBM and Oracle have a shared interest in assuring their enterprise customers that Java was, is and always will be the safe technology choice that they’ve been selling for the past ten to fifteen years. As much fun and excitement as a further escalation of the “Java Wars” would have been, both companies have a very large vested business interest in combining forces, closing ranks and focusing on reassuring their customers that Java should remain their platform of choice.

This announcement fundamentally alters the equation in at least three important ways.

• The presumption of conflict: Implicit in almost all of the recent writings on the future of Java is the notion that IBM’s interests would lie in direct competition, if not outright conflict with Oracle’s. Many have been assuming that IBM would eventually snap and declare war on Oracle’s Java hegemony, with the battles being fought in places like OSGi, Apache and Eclipse. It is now apparent that is not going to happen. Furthermore, now that IBM is working with Oracle on OpenJDK, we can expect a lot more mutual support within the JCP on driving specifications, especially platform specifications, forward.
• Oracle is focused on reviving the business of Java: In case you hadn’t noticed, Oracle’s stewardship of Java is going to be a significant departure from Sun’s. As Amy Fowler said “…this is a practical company who isn’t suffering from an identity crisis and knows how to make money from software.” A couple of thoughts on the differences: First and foremost Oracle actually has resources to invest in moving Java forward, whereas Sun’s financial weakness prevented forward progress for at least the past three years. Second, Oracle is putting in place the software engineering discipline and process in place to ensure that future releases of Java can happen on a much more reliable and predictable timetable than Sun. Third, Oracle is large enough and confident enough in its execution that it is much more comfortable in striking business deals with its co-opetition such as IBM. It will be darn interesting to see if they are successful in signing up more participants down the road. And finally, there will be less talk about community-driven motivations and more focus on the business.

  In my opinion, all but the last of those are unequivocally positive. But Oracle’s current focus on the business at least offers the hope that it may pay community dividends down the road. It is a lot easier for large companies to consider community motivations when they’re profitable and feel that they have momentum on their side. The past couple of years of Java have been years of stalemate, lack of innovation and lost opportunities. Turning that around has to be job one if Oracle is going to see a return on its acquisition.

• This is an inflection point in the Oracle-IBM relationship: If you think back a few years ago, IBM and BEA were two companies who competed fiercely in the Java marketplace, but managed to collaborate on many JCP specifications and in numerous open source projects at places such as Apache and Eclipse. It was a mature industry relationship. Maybe I’ve missed it, but I haven’t seen a similar historical pattern with IBM and Oracle, even after Oracle acquired BEA. This is an important step in the relationship between the two companies, at least in the Java space. Hopefully it is a harbinger of additional collaboration.

The big question is what are going to be the reactions of the other significant players in the Java ecosystem. The actions of Google, SAP and VMware in particular will all be interesting to watch.

Disclaimer: Both IBM and Oracle are Strategic Developer Members of the Eclipse Foundation, with seats on our board of directors. They are first and second place respectively in terms of the number of active committers contributing to Eclipse projects. SAP is also a Strategic Developer Member. Google, VMware are Solutions Members of the Eclipse Foundation.

I mentioned in a comment last week that — pending Board approval of the 2010 budget — there are a number of items which we’re looking at for 2010 that we at the Eclipse Foundations are pretty excited about. These are some major pieces of work that we are going to be focusing our time and energy on.

There will also be a number of significant programs for the commercial members, but those will be the topic of a separate post.

• Build and Test: The team here is aggressively begging companies for the hardware contributions required to take on more of the build and test requirements for Eclipse projects. If we are successful, we will happily provide additional infrastructure and support for build and test activities for projects. But don’t forget that the hardware is actually only a relatively small part of the total solution here. The resource management that the webmaster team will take on will be a significant amount of additional work for Denis and team.
• Git: Denis and the webmaster team have been working hard on getting read-only git mirrors up and running on eclipse.org. But we really look at this as just the starting point. We view git as the SCM solution of the future at Eclipse and hope to have it up and running for as the main SCM repository for as many projects as possible by the end of 2010. Our reason for doing so is pretty simple. From what we can tell, the use of git at Eclipse is going to make it easier for contributors to make and track changes to the Eclipse codebase. And anything which gets us significantly more contributors is a very good thing.

  That said, there are a couple of items that are out of the Foundation’s control that the community will have to help with.

  The CVS Team Provider that has been in the platform for years is really good. In fact, it is so good and so stable that it makes CVS very usable from within Eclipse. For git to gain traction at Eclipse, the EGit Team Provider is going to have to get good, and do so quickly. If we want to see git adopted to a significant degree, my personal belief is that we are going to have to ship EGit with Helios. My guess is that you, the community, are going to have to help make that happen through use, feedback and contribution. (Note that I do not know what the plans of the EGit project are. This is my personal opinion.)

  The Eclipse Foundation doesn’t tell projects what to do. So if git is going to be adopted at Eclipse, the projects are going to have to vote with their feet. In other words, we are going to have to see a number of the large and mature projects bite the bullet and make the transition to git. Because if there is little or no evidence of this within the projects, then the investment by the EMO will be for naught.

  In some ways, the most difficult part of this will be deciding which of the existing SCM systems we’re running to shut off. I personally have a major problem with the idea of running CVS, SVN and git for anything other than a short and constrained period of time. The main reason for this that having multiple SCM systems is a barrier to contribution for the community. If someone needs to learn three different SCM systems to interact with and contribute to three different Eclipse projects, then we have failed our community.

• “Eclipse Labs”: We’re looking at creating an Eclipse Foundation affiliated forge where projects which are based on the Eclipse platform, but are not interested in hosting at eclipse.org can run their projects. There will obviously be some constraints (e.g. only Eclipse Foundation projects can use the org.eclipse namespace, and be part of the release train) but Eclipse Labs will hopefully over time form a powerful complement to the projects hosted at Eclipse.
• “Get Involved”: We are going to be adding some variant of a “get involved” menu item to the left nav for project home pages. We want to make it easier to contributors to understand how to get involved with every Eclipse project, and we want to help projects to learn and follow best practices on how to facilitate more community involvement. Obviously, this may require some additional work for some projects, but the increases in community involvement, contributions and project diversity will be worth it to all of us.
• Artifact Repositories: We want to make it easier for adopters of Eclipse technology to find and consume the great work that’s happening in the Eclipse Foundation projects. For this reason we are going to be looking into what technologies would make it easier to consume Eclipse software. To be blunt, we don’t know what this might be at the moment. It could be Nexus or Buckminster or Tyco or something new from the B3 project. We just don’t know and we won’t be making any final decision for six or seven months. If people are interested in getting together for a BOF at EclipseCon, I think that would be a great way to move the conversation along.

As you can see, this is a pretty significant list of projects for 2010. Denis, Wayne, Ian and their respective teams are going to be carrying the ball on these. So comment at will, but please also consider buying them a beer at EclipseCon 🙂