Life at Eclipse

Musings on the Eclipse Foundation, the community and the ecosystem

The Eclipse Foundation’s 10th Birthday

Today the Eclipse Foundation celebrates its 10th birthday. Boy, time flies when you’re having fun!

It is very hard to put your mind back to an event in the past. I don’t mean simply remembering the event; that’s easy. What is hard is to recall what the environment was really like at the time, without the context of all of the subsequent history.

But if you look back at the original press release, with all of its quotes, and the open letter Sun wrote to the Eclipse Foundation Board, how did we do versus the expectations of the time?

  • The first thing that struck me was how much has changed in 10 years. If you read Sun’s open letter in particular, it’s definitely a bit of a time capsule. Of course, Sun itself has long since been acquired by Oracle. And although NetBeans does continue to thrive, I can barely remember Sun Java Studio Creator, or the Java Tools Community. (The “Page last updated 15 January 2004″ rather says it all.)
  • One of the questions that Sun raised was around the true independence of the Executive Director (which five months later turned out to be me) and the organization itself. On that topic, I think that the Foundation deserves very high marks. We’re fiercely vendor neutral at Eclipse, and every decision we make is checked against that principle. As for me, I answer to the entire Board at Eclipse, as well as the community, and I consider the independence of the Foundation to be paramount. I think a watershed moment in the Eclipse Foundation’s history was when both Borland and BEA signed on as strategic members in time for EclipseCon 2005. Having those direct competitors join the fun was a very clear endorsement of the Eclipse Foundation’s governance and independence.
  • On helping to improve Java interoperability, Eclipse has been part of the Java Community Process for many years, and I’ve served on the JCP Executive Committee for six. I can’t say that we’ve fixed all the issues with the JCP, but we’re certainly committed to trying.
  • Remember the Swing vs. SWT debate? Although it was wonderful flame bait for quite a while, the whole thing seems so overblown in retrospect. Especially given that Swing seems destined for maintenance-only with JavaFX on the horizon. And the development world has definitely changed from once wanting a high degree of desktop fidelity to caring more about custom application look and feel.

Overall, I think that the biggest change at Eclipse is the breadth of the technology that is happening here. Reading the initial announcement, the focus was entirely on Java and tools, and tools for Java. Our community’s reach has now extended into rich client platforms, runtimes, modeling, geospatial. and the Internet of Things. In addition, the tooling platforms that we’re now seeing developed at Eclipse range from browser-based development such as Orion to full lifecycle model-based development for safety critical software like PolarSys. These are very cool new technologies, and I am very excited about the future direction of our community.

Here’s to the next 10 years!

Written by Mike Milinkovich

February 3, 2014 at 4:51 pm

Posted in Foundation

JavaOne: The Eclipse Inside

I spent last week at JavaOne in San Francisco, and I thought I would share a few things about the event that might be of interest to the Eclipse community.

First I should mention that I thought the buzz at the conference was the best that I’ve felt for years. It was certainly the best since Oracle acquired Java, but it was also better than the last couple of Sun-run events. Back in those days, all the loud music and hype on the planet couldn’t hide Sun’s lack of vision and investment in the Java platform. I’m not saying that everything is perfect in Javaland, but things are certainly moving in the right direction.

On one hand, it would be fair to say that there wasn’t a lot of Eclipse at this year’s JavaOne. The Eclipse Foundation did not have a booth in the exhibit hall. There weren’t a lot of sessions, and Oracle does seem to love to talk about NetBeans. Other than 10-year-old Aditya Gupta’s “hacking Minecraft” demo in the Thursday community spotlight, I don’t think there was a mention of Eclipse in any of the keynotes.

But in some ways, this was the best JavaOne for Eclipse ever. In fact, there was Eclipse inside a couple of the most talked about projects at the show.

  1. Did you know that we (sort of) won our community’s first Duke Award? The Open Home Automation Bus (openHAB) project was recognized for its creative and innovative uses of Java technology. You can read more from Kai Kreuzer’s blog post.

    Contributors to the openHAB project have developed a Java-based home automation solution, which includes a runtime based on the Equinox OSGi runtime and Eclipse Jetty web server and a scripting language for easily defining automation logic. openHAB provides a central integration point for developers to integrate devices and applications into the solution.”

    If this sounds familiar, it should, because within the next couple of weeks the core of openHAB will be moving to Eclipse and becoming the Eclipse Smart Home project.

  2. In the opening JavaOne keynote, and again in the Thursday morning IoT keynote at OpenWorld, Oracle highlighted a very cool people counter M2M application developed for the conference by Eurotech and Hitachi which used doorway sensors to track the movement of people through the conference. The application was built with Java, OSGi and MQTT technologies. In other words, it showcased Eclipse Paho (MQTT), Mosquitto (soon to be Eclipse Mosquitto), and the OSGi-based device gateway frameworks which Eurotech has proposed to contribute to the Eclipse Kura project. The M2M/IoT community at Eclipse is growing very quickly, and it was great to see so much of its potential being highlighted at JavaOne.

So all-in-all, I would say that the Eclipse community played a low-key but darn cool role at JavaOne 2013.

Written by Mike Milinkovich

September 29, 2013 at 10:12 pm

Posted in Foundation, Open Source

Embracing Social Coding at Eclipse

The Eclipse Foundation is going to start allowing its projects to host their mainline development on third party forges such as GitHub, and (eventually) Bitbucket. This means that an Eclipse project will be able to leverage the great development tools provided by those vendors. The first project that we are going to work with on this is Vert.x, which has been hosted on GitHub since its inception. Our intent is to start small, and continually improve this program and our support of it. This is an important new option for open source projects which have matured to the point where vendor-neutral governance, meritocratic processes and proper intellectual property management have become important for future growth and adoption.

It’s hard to believe that it was almost two years ago when Mikeal Rogers penned his “Apache Considered Harmful” post, stirring a decent amount of controversy at the time. Although I disagreed with many of Mikeal’s points, his key point that open source foundations need to change to maintain their relevance resonated strongly with us in the Eclipse community. We listened, we’re learning, and we’ve been working hard to change our processes and infrastructure to stay relevant for open source developers. Here are a few examples:

  1. We switched to git: Last December 21st we shut off CVS at Eclipse, and we have migrated basically all of Eclipse to git. (There are a few projects still on Subversion.) Using a modern distributed version control system at Eclipse has already helped a great deal in increasing contributions and reducing barriers to contribution to our projects. Among other things, it has allowed us to mirror Eclipse projects on github, which has attracted some interest from the development community there.
  2. We adopted Gerrit: Using git has also allowed us to start using the Gerrit code review tool at Eclipse, which has been a great addition to our contribution workflow.
  3. We implemented the project management infrastructure (PMI): We now have a database-backed system which tracks all of our project metadata, such as committer lists, release dates, project plans, and the like.
  4. We started using contributor license agreements (CLA): Using CLAs further reduces the barriers to contribution, as we no longer have to have a discussion on each contribution about the IP rights.

The last two of those items are extremely important because they put us in a situation where we can begin to automate workflows, thereby reducing the amount of effort by our commmitters and contributors. So, for example, by the end of June we will have automated the CLA check on all of our contributions which flow to us via Gerrit, or directly into our git repositories. We will have all of the data in place to determine that the author, committer, and signed-by fields on a contribution map to a person who is either a committer or who has signed the Eclipse Foundation CLA.

And then along came Vert.x.

Early in January 2013, there was a very active discussion about the future of the Vert.x project. The project had reached a point in its progress where it was clear that it should move to a vendor-neutral home. After quite a bit of discussion, the Vert.x community decided that the Eclipse Foundation would make a good home. The discussion was particularly interesting because the relative merits of moving to Eclipse, Apache, OuterCurve and the Software Conservancy were debated in an open and flame-free manner. Now that the Eclipse Foundation is open to projects which are implemented in any language or technology, without requiring linkages to our eponymous IDE, it is a good home for innovative new projects like Vert.x.

Since its inception, Vert.x has been hosted on GitHub, and is one of the most watched Java projects there. During the process of discussing how to migrate Vert.x to the Eclipse Foundation, we had a bit of an epiphany: if Eclipse projects could mirror to GitHub, what would happen if we simply flipped things around and mirrored projects hosted at GitHub on eclipse.org’s git repos? After some discussion, we decided that this was a really good idea. Complementing the great developer infrastructure at GitHub with the governance and meritocratic processes that an open source foundation like Eclipse brings to the table will be the best of both worlds for some projects.

Projects which choose to take advantage of this will be hosting their mainline development remotely, but all of their code will be mirrored back to Eclipse’s git repositories. The full Eclipse development and IP processes will be applied to these projects. Project metadata, plans, committer records and votes will be maintained in the Eclipse project management infrastructure (PMI). Admin rights to the repos will be owned by the Eclipse Foundation webmaster team.

Initially, most of this will be maintained manually, but over time we expect to automate a great deal of it. For example, initially checking that a pull request’s author has signed an Eclipse CLA will be done manually by the project committer accepting the contribution. Over time that will be automated using git commit hooks. We will continue to automate these interfaces, so that things like committer lists, etc. will be automatically updated based on changes in our PMI.

The last year and a half have been extremely busy at the Eclipse Foundation, as we have done a lot of work to modernize our infrastructure, and to make it more attractive than ever to become part of the Eclipse community. This is part of an on-going effort to remain relevant as the expectations of developers and open source committers rapidly evolve.

If you are interested in learning more about this, please read our FAQ.

Written by Mike Milinkovich

June 20, 2013 at 10:30 am

Posted in Foundation

Eclipse Contributor License Agreements Are Live

As we started talking about back in February, the Eclipse Foundation is doing a major overhaul of our IP processes. With the Kepler release now firmly in its end-game, the time has come to start rolling this out.

In February, I identified three major pieces of work that needed to get done:

  • First, we are going to implement Contributor License Agreements (CLAs) for all contributors at Eclipse. The CLA will be a short document that essentially asks The Three Questions once. We will collect some information about the contributor so that we have a record on file of who is giving us code or documentation. Note that the Eclipse Foundation CLA will be quite different from those in use at other organizations. For example, Apache’s CLAs basically give the ASF a license equivalent to ownership for contributions. The Oracle Contributor Agreement (OCA) used by OpenJDK community gives Oracle joint ownership of contributions. The Eclipse CLA is much more modest. In terms of licenses, all it says is that the contributor agrees that their contributions will be provided under the license(s) for the project they’re contributing to. You can review and discuss the draft CLA on bug 401349.
  • Second, we are going to support signed-off-by for contributions which flow to Eclipse project via git and Gerrit. The goal here is to make it as simple as possible for Eclipse projects to accept contributions via the community best practices which have grown up around git. As part of this, we will be developing a contributor certificate of originality, inspired by the one used by the Linux community.
  • And finally, we are going to automate as much of this workflow as possible. Our CLAs will be presented and completed on-line. There will be Gerrit support so committers get an immediate indication as to whether a contributor has a CLA on file. There will be git triggers which will reject a commit where there is no CLA on file for the author of the code commit.

Ever since then, we’ve been working on getting all of the pieces lined up to go live with these capabilities. Today is the first step!

The Eclipse Contributor License Agreement is now live. This means that contributors can execute a CLA, and get theirs on file. Committers will be able to use the PMI (project management infrastructure) to look up whether a particular contributor has a CLA on file. So starting immediately, you will be able to refer to a CLA rather than asking the “three questions” on a bug. This is basically delivering on the first item above.

For the second item, the Eclipse Foundation Contributor’s Certificate of Origin has been published, and contributors and committers should start using the signed-by option with git.

In order for a contributor to sign their CLA, they need to do the following:

  1. Obtain and Eclipse Foundation userid. Anyone who currently uses our Bugzilla or Gerrit systems already has one of those. If they don’t, they need to register.
  2. Login into the projects portal, select “My Account”, and then the “Contributor License Agreement” tab.
Navigate to the CLA

Navigate to the CLA

The day after Kepler ships — Thursday, June 27th — we will deliver on the third item, which is automation. On that day, we will start automatically enforcing CLAs. This means that every time a contribution arrives at one of our git repositories (including Gerrit), the author field will be checked to ensure that there is a CLA or Committer Agreement on file for the author. If there isn’t, the contribution will be rejected.

Progress!

Written by Mike Milinkovich

June 17, 2013 at 1:35 pm

Posted in Foundation, Open Source

Community Review of the Eclipse Public License

The Eclipse Public License, and its predecessor the Common Public License have been in existence for around 12 years now. A lot has changed since the EPL’s introduction in 2004, and the time has come for a review to ensure it remains current. As a result, we are going to kick off a public process to solicit input on the license, and discuss possible revisions. Once we’ve arrived at a set of revisions which have a broad support, the Eclipse Foundation Board of Directors would have to unanimously approve the new version. And, of course, any revisions would be submitted to the Open Source Initiative to have them certified as compliant with the Open Source Definition.

I don’t want to steer the conversation in any particular direction, but as a sampler of issues, here are a couple:

  1. The distinction drawn between object code and source code aren’t really helpful when you’re talking about scripting languages like JavaScript.
  2. The use of the term “module” is confusing to some.

There are a few things that we already know we don’t want to change. First and foremost is that the EPL will remain a copyleft license. Another is that we want to continue to enable a commercially-licensed ecosystem based on Eclipse technologies.

We are going to be starting these discussions soon on the epl-discuss@eclipse.org mailing list (subscribe here), and will be tracking individual issues in the Eclipse Foundation/Community/License component in the Eclipse bugzilla.

If you are interested in the future of Eclipse licensing, please join in the conversation!

Written by Mike Milinkovich

May 31, 2013 at 11:37 am

Posted in Foundation, Open Source

The EPL as a Platform License

Yesterday’s announcement of the OpenDaylight project has gotten very wide coverage. It looks like a well-done announcement, and the industry support for this important new collaboration is stellar. Yet another great example of how open source is facilitating collaboration on new and innovative industry platforms.

In my opinion, one important detail of the announcement has not received sufficient notice:

OpenDaylight … is structured and governed using open source best practices and is licensed under the Eclipse Public License (EPL)…

So OpenDaylight is flying in the face of a lot of recent conventional wisdom that the Apache License is the default license of choice for new industry collaborations. (See here here and here.) Frankly, I thought I would see pigs fly before seeing Microsoft fully participating in an EPL-licensed open source community.

I think that this could be the start of a new trend, because as we’ve seen platform fragmentation in the Android ecosystem is becoming bit of an object lesson for the industry.

The EPL has a couple of really important features that make it a particularly good platform license. It strikes the perfect balance between the competing interests of the collaborative community who is building the code, and the commercial interests who want to use that code in their products and services.

  • The EPL is copyleft, which means that if a company forks the code to further their interests, they need to make that code available under the EPL. This is a powerful incentive to simply do the work in the main project, in collaboration with the other players.
  • The EPL is commercially friendly, allowing corporations to build products on top of EPL-licensed code and use their own End User License Agreement when selling to their customers. This provides the ability for companies to leverage EPL-licensed open source code in traditional software business models.

The combinations of those two main features has been a big part of the success of the Eclipse community. We’ve seen remarkably few forks at Eclipse (aka fragmentation), while enjoying massive amounts of commercial adoption of our technologies. Will the OpenDaylight announcement make other industry open source collaborations think a little bit harder about their license choices? Time will tell, but I think this could be an interesting trend to watch.

Written by Mike Milinkovich

April 9, 2013 at 8:45 am

Posted in Foundation

Public Review Drafts of New IP Documents Now Posted

A few weeks ago, I talked about a major overhaul of our IP processes. As part of that, we have posted our Public Review Drafts of our Eclipse Foundation Contributor License Agreement (CLA) and our Contributor’s Certificate of Originality (CoO).

I was asked why we needed both documents. I will repeat the explanation here:

The two documents are complementary.

The CLA is something that a contributor signs, and is a legal agreement.

The CoO is a statement that clarifies what we expect from contributors when they use the “signed-off-by” feature in git.

There is a saying that many lawyers use: “belts and suspenders”. Yes, there is some overlap between these two approaches, but there since the DCO is not something that a contributor is expected to sign, I don’t think that it adds any extra burden to the process.

Your comments and feedback would be greatly appreciated. However, please don’t do it in the comments here. We would prefer the community’s feedback on bug 401349.

Update: s/DCO/CoO/ in blockquote.

Written by Mike Milinkovich

March 14, 2013 at 8:00 am

Posted in Foundation

Follow

Get every new post delivered to your Inbox.

Join 2,691 other followers