JRuby Moves to the EPL
I am very happy to report that after a little bit of conversation, the JRuby project has moved from the Common Public License (CPL) to the Eclipse Public License (EPL). So as of this moment, JRuby is tri-licensed under the EPL/LGPL/GPL. This is an excellent reminder to all remaining CPL-licensed projects (hello JUnit! – discussion thread here) to consider re-licensing under the EPL. I documented all of the history and background back in 2009 when the EPL officially became the CPL’s successor, and the CPL was deprecated by the Open Source Initiative (OSI).
This whole JRuby transition came about because Charles Nutter and I accidentally met one another over good Belgian beer at FOSDEM. Since that approach doesn’t scale, I am going to use this event to remind folks that if your project is still using the CPL, you should switch and it is really easy to do so.
Some key points:
- Back in 2009, the CPL was superseded by the EPL. This means that the EPL is the successor version of the CPL. It also means that using the CPL is the licensing equivalent of using deprecated code.
- Because the EPL is the successor version to the CPL, the “new version re-licensing” clause in Section 7 of the CPL applies. In other words, you can re-license your project without seeking the approval of all of your contributors.
- The CPL and EPL basically differ by about one sentence, which you can see here. The difference relates to the scope of patent licenses terminated should someone sue another party for patent infringement. This is the kind of stuff that lawyers love, but most developers don’t really care about.
Thanks to the JRuby team for fixing this so quickly!
Eclipse Says Goodbye to CVS
Well, December 21st is here and the the apocalypse didn’t happen! But it’s still a big day at Eclipse because today at 12:00 noon, Eastern Time, our webmaster team of Denis and Matt started the process of turning CVS into a read-only service. At this point, we are down to only a handful of projects which still have a CVS repository, and we have hit the long-published deadline.
This is a journey that the entire Eclipse community has been on for at least two years. I have to admit that when I first heard of the idea that we should move the Eclipse community from CVS to git, I was adamantly against the idea. The notion seemed to big, too scary, and the idea that we could get the community to move seemed too unlikely. But as time went by the logic and benefits of moving to git started to clearly make sense. The trend towards social coding is huge. Working with the developer community which has grown up around github is large and vibrant. It is critically important to all open source organizations to make it as easy as possible to attract more contributors, and leveraging git is a big part of making that happen.
There are a lot of people that worked hard to make this happen. In no particular order:
- Chris Aniszczyk, who is an elected Committer Rep on Eclipse’s Board pushed hard to make this possible. Not only did he tirelessly champion this transition at the Board, he worked hard on EGit and JGit to get the tools in place to make it possible. For anyone who wonders about how important your elected representatives are on the Eclipse Board, Chris is a great example of how influential these directors are. Chris blogged about the transition today as well.
- Shawn Pearce, and the entire EGit and JGit teams. Shawn started those projects and helped bring them to the Eclipse Foundation. When we started this process, one of the biggest impediments was the lack of great tools. Shawn, Chris, Matthias, Remy, and many others have worked extremely hard to get these great tools in place. Given how mature and feature-rich the CVS Team Provider was, they had a lot to accomplish and not a lot of time to do it in.
- Wayne Beaton has done a great job in tracking down all of the Eclipse projects and coaching them on what they needed to do to transition their projects to Eclipse. It has been a huge job to get 180+ projects moved, and Wayne has done an enormous job in ensuring that each and every project knew about the transition, and helped them get it done.
- The Eclipse webmaster team of Denis Roy and Matt Ward helped migrate all of the repositories over, and basically made this all possible. I can’t even imagine how many repositories they’ve created for the projects over the past year or so.
- And finally, all of the Eclipse projects deserve a big round of applause. It has been a big job to move to git, involving learning new tools, deciding on a repository architecture, re-doing their builds and so one. In particular, I want to thank some of the older and larger projects such as Eclipse, Web Tools and BIRT who had years of working practices that they’ve had to re-do to make this all possible. In particular, John Arthorne and Paul Webster really helped by elaborating some best practices, and establishing some solid git usage policies that have been widely adopted by the community as we’ve transitioned.
So thanks and congratulations all the way around. It’s been a big job, but we collectively got ‘er done!
Orion: Open Source Platform For Cloud, Web and JavaScript Development
The Orion team has announced their 1.0 release, a major milestone for this new tooling platform for the web, in the web. Or if you prefer, for the cloud, in the cloud.
For those who are not familiar with Orion, you may want to read my introductory blog post when the project first launched in 2011. PlanetOrion is another great source of information. But even better, go and try it out by downloading it, or setting up an account on orionhub.org.
Orion is a completely new open source tooling platform, which provides an open, extensible tooling platform and a set of re-usable components for building web tools which run in your browser.
Despite just releasing their 1.0 version, the Orion team has already seen some pretty interesting adoption. From the team’s post:
Orion has had some great adoption leading up to the 1.0 release like being included in Firefox as the editor for ScratchPad, the editor and the basis for Content Assist in Scripted, a platform for hosting an entire solution at Cloudfier, and numerous investigative demos from other projects such at Stardust and Xtext/Xtend.
So, congratulations to the Orion team! I’m already looking forward to the 2.0 release in a few months.
Google is Eclipse’s Newest Strategic Member
I am very happy to welcome Google as the newest Strategic Member of the Eclipse Foundation. This is important, and exciting news for the Eclipse community. Google will be joining CA Technologies, IBM, Oracle and SAP as the backbone of the Eclipse Foundation’s funding, as each of these companies are providing $250,000 per year for our operations. They will be joining Actuate, Bredex, EclipseSource, itemis, OBEO, and Talend as Strategic Members on the Board.
Google has long been a very large user, adopter and contributor to Eclipse. The Eclipse tooling platform has been an important part of Android’s success in the mobile marketplace, as well as providing the tooling for other Google initiatives such as AppEngine, GWT, and Dart. Google has also contributed to CDT, and has both led and contributed significantly to the JGit and WindowBuilder projects. By providing this additional funding, Google will be helping the Eclipse Foundation ensure that we have a great infrastructure and a great staff to support our community.
Please join me in welcoming Google’s generous support of the Eclipse Foundation!
Juno Performance
There has been a lot of conversation this past week about the state of Juno’s performance on the new Eclipse 4.2 platform. The original thread was kicked off by Thomas Hallgren, there’s been a flurry of comments on bug 385272, and a nice summary of the concerns in Andrey Loskutov’s blog.
I think it is apparent there are a lot of very valid concerns that will need to be addressed, and we as a community will need to pool our resources to ensure we succeed. However, there are two issues I’d like to address: 1) moving to a major new release is always hard, and 2) we need the community to help solve the problem.
Moving to a new major release
For a little historical perspective, anyone who was around when Eclipse 3.0 shipped in 2004 can likely tell you that moving to a major new release is never ever easy. It is absolutely impossible to do a major rewrite of a platform used by millions without pissing somebody off. Nor is it possible to achieve perfection the first time around. That is not said to dismiss any of the concerns that have been raised. We need to have the feedback, bugs and patches to move things forward. However, we do need to move forward.
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. Kepler is going to be based on 4.3. There will never be an Eclipse 3.9. Those decisions were made quite some time ago by the Eclipse PMC and the Planning Council, after long discussions about the pros and cons. That’s where we’re at. So if you want to help move Eclipse forward, please focus your energy on providing input, feedback, patches and tests on the Eclipse 4.x stream because that is unequivocally our future.
Significant community help is required
The performance test were turned off because the Eclipse platform team has a serious resource issue. The simple fact of the matter is that the Eclipse platform team is stretched well beyond what it can reasonably be expected to accomplish. This is not a new problem. It has been discussed in many forums for at least the past three or four years. Unfortunately, very few people or organizations have stepped up to make significant contributions. Perhaps this will serve as a catalyst for people to step forward to contribute more to the needs of the platform. Let me stress how important it is for this to happen.
There have already been a couple of very positive developments that have come out of this conversation. Google has stepped up and donated $20,000 towards the creation of a brand-new testing infrastructure for eclipse.org. 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. However, there are thousands of companies and millions of developers that make use of Eclipse every day. We need more of these companies to come forward to start participating in the core Eclipse platform. Google’s contribution is a perfect example.
The Eclipse 4 platform has a large number of important new features and capabilities which are going to allow us to do many more cool things in the future. The Eclipse platform team has done a great job bringing it this far. It is not perfect and we have the SR1 release coming up in a couple of weeks that will address some known performance degradations and memory leaks. I expect we will continue to see more improvements in SR2 and Kepler. The critical issue is that the entire community needs to be part of the solution. Now is the time to step forward and give back to the Eclipse project that started it all.