Life at Eclipse

Musings on the Eclipse Foundation, the community and the ecosystem

The Internet of Things Will be Built on Open Source

leave a comment »

This post was originally published on the Bosch Connected World Blog.

The Internet of Things is poised to become the next wave of technology to fundamentally change how humanity works, plays, and interacts with their environment. It is expected to transform everything from manufacturing to care for the elderly. The internet itself has — in twenty short years — dramatically transformed society. This scale of change and progress is about to be repeated, in perhaps even larger and more rapid ways. New ventures will emerge, existing businesses will be disrupted, and everywhere the incumbents will be challenged with new technologies, processes, and insight.

It is important to recognize that the internet is successful because it is one of the most radically open technology platforms in history. The fundamental protocols of the internet were invented in the 1970′s, and put in the public domain in the late 1980′s. The world-wide web was invented at the European Organization for Nuclear Research (CERN), which made it free for everyone. In subsequent years, open source technologies such as Linux, the Apache web server and the Netscape / Firefox browser ensured that the basic infrastructure for the web is based on open source. The technology behemoths of our day such as Google, Amazon, Facebook and Twitter are only able to scale their infrastructure and their business models by relying on open source. In short: our modern digital world is built on open source software.

The Internet of Things will be implemented using open source software platforms. There is utterly no alternative to this outcome. Anyone who says otherwise is fooling themselves.

There are four reasons why this is true.

  1. Scale: Depending on which analyst you prefer, the next decade will see between 50 and 70 billion sensors being deployed on Earth. This will require tens, if not hundreds of millions of routers, gateways, and data servers. There is simply no way to achieve those levels of scale without relying on open source software to drive the vast majority of that infrastructure. Any other approach will simply be unaffordable, and will be out-competed by the economies of scale achievable by the open source alternatives.
  2. Freedom to Innovate: Open source software allows permission-less innovation. In particular, open source allows innovation by integration, where developers create new and novel systems by combining freely available open source components. This approach is somewhere between difficult and impossible for proprietary software stacks, where the vendor has to drive all of the invention.
  3. Inter-operability: I am a big believer in open standards, and firmly believe that they will be an integral part of the IoT. However, it has been proven time and again that the best possible way to have a new technology achieve rapid adoption is by combining open standards with a robust open source implementation. OSS implementations provide an easy adoption path, near-perfect interoperability with others, and reduces the cost of entering the market. In a world where developers are becoming one of the most precious of commodities, it makes no sense to waste them on implementing a standard. They should be focused on building software which provides the firm with product differentiating features that customers value.
  4. Developers: Lastly, recruiting and enabling developers is a key, and often overlooked part of any IoT strategy. By the end of this decade the number of IoT developers needs to grow from a few hundred thousand to over four million. Today’s developers demand open source solutions and tools. Even a decade ago, technology acquisition was largely a top-down process. Now technology choices are largely made bottom-up, by developers experimenting with open source components and integrating them into a solution.

For these reasons, IoT is rapidly becoming a strategic area of focus for the Eclipse community. From three projects two years ago the Eclipse IoT community has grown to seventeen projects, implementing protocols, device gateway frameworks, vertical frameworks, and tools for the needs of IoT developers.

Bosch has been an active member of the Eclipse Foundation since March 2010. Their initial focus was on the Automotive Working Group, which has been working on tools and methods for automotive embedded systems. Its subsidiary Bosch Software Innovations (BoschSI) is one of the world’s thought leaders in driving open source platforms for the Internet of Things. They have recognized its importance, and with contributions such as the Eclipse Vorto project are helping to make it a reality. The Eclipse Foundation values the partnership that we have with the development teams, and look forward to a long and fruitful collaboration.

The digital world we have today is built on open source technologies. The Internet of Things will be too. Come join the Eclipse IoT community to help make that happen

Written by Mike Milinkovich

October 28, 2014 at 3:50 am

Eclipse Cloud Development: The FAQ

leave a comment »

This morning, the Eclipse Foundation announced a new industry initiative focused on building tooling platforms for the cloud. The team prepared an FAQ, but I thought it might be helpful to publish it here as well.

What is being announced?

Eclipse is announcing the formation of a new Top Level Project, “Eclipse Cloud Development” to create the technologies, platforms, and tools necessary to enable the delivery of highly integrated cloud development and cloud developer environments. The ECD charter is available here. This TLP initially combines Eclipse Orion, Eclipse Che, and Eclipse Flux with SAP signaling that Dirigible will become part of the initiative. The Eclipse board of directors voted to approve this new project on September 17th, 2014, and a new project management committee has been formed. Additionally, Codenvy is announcing the creation of project Che, which contains their IP that makes up the Codenvy SDK, Codenvy IDE, and 50 plug-ins that provide programming language, source code control, deployment, and build / debugger support for cloud development. Codenvy will be contributing 30 full time resources to the ongoing development of Eclipse projects, the development of the community around cloud development, and the promotion of the Ecosystem that makes up the ECD. Codenvy has become a strategic developer member of Eclipse, and taken a board of directors seat with the foundation.

Why is Eclipse creating a top level project dedicated to cloud development?

There are over 22 million professional developers, and more than 99% of all development is still done on the desktop. The cloud has proven benefits to eliminate configuration overhead and improve visibility and control for organizations. The transition to cloud development away from the desktop has begun. Over the past 5 years, there have been 100s of global initiatives to work on development tools or underlying infrastructure necessary to enable development entirely in the cloud. With three projects at Eclipse already working on cloud development, and more coming soon, the time has come to focus the industry’s efforts on enabling this transition. By creating a Top Level Project, the combined projects are better able to concentrate their resources, more easily align on technological and market objectives, and create a streamlined path for onboarding additional ecosystem projects, developers, and committers to cloud development.

Which projects will be part of the Cloud Development Platform top level project?

Eclipse Orion, Che, and Flux. SAP Dirigible is also planned for submission and will become part of the TLP.

What is the Che project?

You can read the Eclipse Che project proposal here.

What is the difference between Orion and Che?

Orion & Che:

  • Provide a runtime for hosting, managing and scaling developer environments as Web apps.
  • Provide an SDK for packaging, loading, and running tooling plug-ins.
  • Provide a default set of plug-ins related to programming languages, source code, deployment, and other elements that are part of the developer workflow.
  • Provide a default cloud IDE that combines a set of plug-ins, the SDK, and runtime together to offer a hosted developer experience.
  • Have ways (or plans for ways) to connect desktop IDEs (like Eclipse and IntelliJ) directly into the hosted services

This commonality is also what makes them different. Orion has been authored with Node.js and JavaScript, to create a system optimized for creating, testing, and deploying interpreted language systems entirely using the latest Web technologies. To achieve this goal, it has adopted a unique architecture that is optimized around the types of applications that are meant to be built with it. With this, Orion provides many advancements around JavaScript and other interpreted languages. Che has been authored in Java and follows many of the architectural principles used by the Eclipse RCP and Java Development Tools projects. Che provides an architecture and design optimized for compiled languages along with in-depth extensions related to the Java ecosystem like maven, Java debugging, ant, and so on. The Che architecture was created to minimize the effort required to port Eclipse plug-ins to work within Che for a Web experience. While plug-ins must be rewritten in Che interfaces, the plug-in lifecycle and tooling support for Che plug-ins is designed to make the transition tax as low as possible. Additionally, the Che runtime model supports developing non-Web applications including mobile, desktop, console, and API-oriented applications that do not have a native HTML output. Additionally, the Che project also has the scope to build out infrastructure supporting a developer environment PAAS, for running developer environments with large numbers of concurrent developers, builds, runs, and projects on a unified set of hardware, while providing enterprise behavioral and access controls. The PAAS infrastructure that is part of the Che project will be designed to support any type of editor, cloud IDE, or development runtime, enabling scale out of those services. So, Orion can work within it as well.

What is Dirigible and how does that relate to Che and Orion?

Dirigible extends the concepts promoted by Orion and Che to deliver on a rapid application development framework, fully hosted in the cloud. Dirigible abstractions make developing Web services and the clients that consume them structured with scaffolding, rapid, and easier to maintain. Rapid development frameworks have commonly been deployed to support database and packaged application development, and Dirigible brings those concepts to cloud developer environments. All three projects provide hosted developer environments. But our commonality and agreement on a common vision means that there will be nice reuse and alignment between the projects. All of the projects agree on core principles relating to providing developer services as atomic microservices, decoupling the clients (IDEs) that consume those services from the services themselves, supporting a broad range of clients (whether our browser IDEs or desktop IDEs connected over a bus), and providing a consistent way to provision, share and scale hosted developer environments together.

When should a developer user choose Orion and when should they choose Che?

They should choose both :). But more seriously, while a developer should try both products for all kinds of applications, if a developer is doing a JavaScript project, they should experience Orion. If their project has Java language extensions, Eclipse plug-ins, mobile development, or other non-Web application development, then they should give Che a try. Both Orion and Che will be working on a variety of common infrastructure projects that will make it easy for projects to migrate between Che and orion, along with the Che / Orion IDEs operating on a common set of enterprise infrastructure.

How will Orion, Che, Flux, and Dirigible collaborate together?

We have identified a number of initiatives that the projects will align on. These include: Finding ways to have Che and Orion plug-ins work within each other’s systems. Standardizing on the synchronous REST API model that allows browser clients to communicate with server-side systems. A sample set of APIs can be seen at docs.codenvy.com. Using Flux to standardize on the asynchronous communication model between various cloud systems, along with enabling browser and desktop clients to have decoupled access to cloud systems. Collaborating on a model that allows for on-demand, authentication-less environment creation through URLs, similar to the effects seen by Codenvy Factory, as documented at docs.codenvy.com/user. Temporary environments will be possible to be generated on any system supporting the format. Align on common underlying enterprise infrastructure, that will seamlessly take a single server cloud IDE package, and allow it to be deployed within an enterprise system that provides multi-tenancy, elasticity, and security. Incorporate the Dirigible configurate-stored-as-a-model approach to create an abstraction to support a variety of rapid development approaches and frameworks.

What is the future of cloud development, and your roadmap here?

Cloud development’s benefits are significant to individual developers, development teams, and enterprise organizations. There are huge configuration taxes that exist today due to environment creation, environmental technical debt, environmental tribal knowledge, hardware interoperability issues, and the general interoperability issues that exist between making an ecosystem of tools and plug-ins work together. All of these problems can be dramatically reduced with a cloud development platform that automates the full lifecycle of developer environment and its supported tooling. To achieve this vision, much more than a cloud IDE is required. A cloud development platform (CDP) takes a cloud IDE and turns it into an orchestration system for developer environments. The power of the CDP is that it can automate many of the workflows that make up the tasks carried out by developers, QA, product managers, documentation specialists, and devops professionals. Why should each developer only have a single developer environment that lives indefinitely (statically) on their desktop, when – with full automation – every developer and system can have a unique developer environment for each task they carry out during the day? Whether it’s fixing a bug, investigating a legacy branch, working on a new feature, or exploring a new technology library, a cloud development platform can auto-provision a specialized environment for each task, on-demand, with no downloads or configuration required by the developer. The CDP can then provide numerous services to make the developer’s workflow shorter and less error prone. These include advanced editors, dependency analysis, automated unit testing, debugging, building, packaging, and source code management integration. The CDP can take these operations at scale, and make them run faster than they would normally run on an individual desktop, but also require less hardware for a large organization than performing these functions on desktops since the cloud can be operated on a dense hardware cluster. Finally, with development centralized, devops and development leaders, can better support the development of a population of developers by incorporating best practices, behavioral access controls, and monitoring tools to ensure IP compliance and maximum productivity of individuals. Imagine being able to direct an extra 20GB of RAM to a developer that urgently needs it for compilation, or creating a special set of sand boxes to support white room development of secure IP, or allowing an instructor to create a programming exam accessible to his students for exactly one hour with controls to detect any plagiarism or cheating. With a CDP, all of these scenarios are configurable, simply. Net, net: Faster development. Cheaper development. Development done with compliance and security. Our roadmap to support this vision includes: Advancing each TLP project through their normal roadmap and evolution processes. Recruiting new projects that provide critical developer services in the cloud into the ECD TLP. Aligning core plug-in, editor, and API / interface models between the projects. There will be combined ecosystem, evangelism, and business development efforts to bring more developers, projects, and plug-ins to ECD model including special efforts and attention to migrating existing Eclipse plug-ins. Codenvy will create an additional project that focuses on the enterprise scale elements of a ECD, and Flux / Orion / Che will work to standardize deployment of each system within the enterprise infrastructure. An effort to study how analytics, events, and the BI of development workflows will be created.

Why is Codenvy donating their core IP?

Codenvy believes in openness, transparency, ecosystem, and Eclipse. The cloud development problem is massive and cannot be solved individually. By working with the Eclipse foundation, Codenvy is able to concentrate their resources with others that have a similar value system and vision.

When will the Che code be available? For which “parts” of the platform?

The initial Che code is available under EPL at github.com/codenvy/sdk. We are working within the Eclipse process to get through Incubation now.

What kinds of products, applications can we expect to see as a result of this collaboration?

You can expect to see new IDEs, new plug-ins, new enterprise technologies to support executing these systems at scale, and you can expect to see integration bridges that bind ECD into other core development platforms like Jenkins and Jira.

How can I contribute to and participate in the Che project?

Get started by cloning the source and getting active at Eclipse. https://github.com/codenvy/sdk

Written by Mike Milinkovich

October 27, 2014 at 8:00 am

Posted in Foundation, Open Source

Leading Automotive Companies to Collaborate at Eclipse: Introducing openMDM

Last week, AUDI, BMW and Daimler announced they are joining forces to form the Eclipse openMDM Working Group to create a new open source community to develop and distribute tools for managing automotive test data. These leading automotive OEMs will be joined in the group by Canoo Engineering AG, GIGATRONIK GmbH, HighQSoft GmbH, Peak Solution GmbH, and science + computing ag.

OpenMDM will address the challenge of managing the generated test measurement data that is becoming critical to the automotive industry. Automotive and other industries are driven by continuous product development processes where multiple partners collaborate across the lifecycle. Almost every development phase includes the testing of components, subsystems, or final products. Usually testing is done with computer assistance via automated measurement systems. The amount of test data created and collected is tremendous in size, and is constantly growing due to an increasing variance of products, a rising number of functions, and advancements in measurement techniques. The management of measured test data is a significant challenge for industry. OpenMDM will focus on developing and distributing tools, certification tests, and test data that conforms to the automotive industry standard called ASAM ODS (Association of Standardisation of Automation and Measuring Systems). MDM@WEB, the first Eclipse project for the group has already been proposed.

For obvious reasons, this is a big deal for Eclipse. When three of the most innovative and successful automotive companies decide to create an open source community at Eclipse, it is a strong statement that open source in general, and Eclipse in particular are offering a compelling solution for companies interested in promoting open collaboration and innovation.

I also see this announcement as confirmation of some key trends in the technology industry.

  1. Open Innovation for All: Software companies long ago understood the importance of open source to drive technology adoption and innovation. We are now seeing other industries, such as automotive and aerospace,  realize that the best way to innovate and drive technology adoption is through open source communities. The model we have developed with the Eclipse Working Groups is proving to provide the right level of governance, process, infrastructure, and community development to make these collaborations successful.
  2. Open Standards and Open Source Make a Good Match: Over and over again we see great things happen when an open standard is matched with a vendor-neutral open source implementation. Lots of industries implement standards to drive interoperability and reduce vendor lock-in costs. The implementation of a standard typically does not provide any competitive advantage for any individual company. Therefore, collaborating on an open source implementation is the best way forward. OpenMDM is focused on implementing tools and test for an automotive standard called ASAM ODS. AUDI, BMW, and Daimler all realize that creating their own proprietary tool for ASAM ODS is not likely to build a better car or increase shareholder value. In fact, working together to encourage a community to innovate on tools will create a better set of tools than an individual company can create by themselves, at a significantly reduced cost.
  3. Vendor Independence Is Key: Many companies start their journey with open source by creating their own community. But they ultimately hit a wall in growing that community, especially in getting the involvement of the other companies in the same industry. Eclipse experienced this in its early days when it was not an independent, vendor-neutral entity. At the time, competitors of IBM were reluctant to make strategic commitments if IBM had ultimate control over the destiny of the Eclipse community. After the Eclipse Foundation was created, companies like Oracle, SAP, BEA, and Borland became more involved. The story of openMDM is strikingly similar, as it originates with Audi and is now becoming a truly independent and vendor-neutral open source community.

One of the key reasons we created the Eclipse Working Groups was so other industries and communities could create their own vendor-neutral “foundations” at Eclipse. We like to think of working groups as being “foundations in a box”. Instead of going through the costly and time consuming process of setting up a new foundation, an Eclipse Working Group can get setup very quickly and provide all the benefits of a vendor-neutral entity. In addition, the operational costs of the group are significantly reduced by using the professional resources of the Eclipse Foundation. OpenMDM is a great example of a vendor-neutral community that allows competing automotive companies to collaborate on equal terms.

Congratulations and thank you to AUDI, BMW and Daimler, as well as Canoo Engineering AG, GIGATRONIK GmbH, HighQSoft GmbH, Peak Solution GmbH, and science + computing ag, for creating openMDM at Eclipse. We see a bright future for this collaboration and open innovation at Eclipse. This is another great example of how industry can and will use open source and Eclipse Working Groups to drive forward open collaboration and innovation.

Written by Mike Milinkovich

July 29, 2014 at 3:21 pm

Posted in Foundation, Open Source

EclipseCon and FOSS4G North America 2015

I am pleased to announce that the dates and venue for EclipseCon North America 2015 have been selected. We are returning to the Hyatt Regency Burlingame, the site of our 2014 event, the week of March 9-12, 2015. It’s great to be returning to the Bay Area once again.

I am also very pleased to announce that FOSS4G North America will be held at the same time and place, a great collaboration between our LocationTech community and OSGeo. Look forward to more details on that shortly from Andrew Ross.

Image

Written by Mike Milinkovich

May 7, 2014 at 8:00 am

Posted in Foundation

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

Follow

Get every new post delivered to your Inbox.

Join 3,140 other followers