Life at Eclipse

Musings on the Eclipse Foundation, the community and the ecosystem

Archive for the ‘Open Source’ Category

Introducing EE4J: The first step towards Java EE at the Eclipse Foundation

I am very excited and proud to introduce the new top-level Eclipse Enterprise for Java (EE4J) project. For those that might not have heard, Oracle has announced their intention to move Java EE to the Eclipse Foundation. Creating the EE4J top-level project is the first step to making this a reality.

Moving Java EE to the Eclipse Foundation is going to be an exciting and massive undertaking. It is a significant opportunity to use the Eclipse open development model to accelerate innovation in Java for enterprise and cloud native computing. We look forward to engaging with the millions of developers and organizations using Java EE.

The Java EE technology is a very large portfolio of source code, TCKs and specifications. Moving all of Java EE will be a significant undertaking for the community. For instance,

  1. The GlassFish open source project includes 130 github repos. Moving these existing GlassFish open source projects to the Eclipse Foundation, and getting all of the various sub-projects set up and under the Eclipse development process will take some time.
  2. The Java EE TCKs will be moved to Eclipse open source projects and be available to the community.  What this means and how the community interacts with the TCKs needs to be defined.
  3. Create an open build infrastructure so EE4J can be built and tested by the community.
  4. Establish a new specification process under the auspices of the Eclipse Foundation.

The good news is Oracle, along with IBM and Red Hat, is moving incredibly fast. Publishing the top-level project charter is an important first step. However, we are aware that there are literally millions of developers who have a vested interest in the future of the enterprise edition of the Java Platform, and who quite rightfully would like to have detailed plans now for how and when the above list are going to be completed. Unfortunately, the details are going to take some time to plan and execute. Moving Java EE to the Eclipse Foundation is going to be process, not an event. I do expect this will be an open process that encourages community members to contribute.

Today marks a very significant milestone in our journey. We are pleased to announce that the draft charter for the Eclipse Enterprise for Java top-level project is now available for community review and feedback. We have created the ee4j-community mailing list for the community to use to provide that feedback, so please subscribe to the list and join the conversation!

Written by Mike Milinkovich

September 28, 2017 at 8:30 pm

Posted in Foundation, Open Source

EPLv2: A New Version of the Eclipse Public License

The Eclipse Foundation is in the process of revising the Eclipse Public License (EPL). Refreshing a popular open source license is a big job, and one that we have been chipping away at for over a year.

The EPL and its predecessor the Common Public License have been around for about 16 years now. For a full presentation on the changes we are considering and their motivation, you can check out our presentation, or the video on YouTube.

Please get involved. Just as importantly, if you are a developer involved in the Eclipse community and ecosystem, encourage your colleagues in the legal department to get involved. The discussions are happening on the mail list (subscription required). The most recent public drafts of the EPLv2 can be found here.

Written by Mike Milinkovich

April 7, 2017 at 2:17 pm

Posted in Foundation, Open Source

Tagged with , ,

Investing in Eclipse Tools

Yesterday I talked about three interesting new runtime projects which have joined the Eclipse community, and made the point that we are extending our reach beyond our “…original comfort zone of tools…”. But that doesn’t mean that we are not seriously investing in tools. In fact, in 2016 the Eclipse Foundation itself is hiring new staff to do exactly that.

The first position was just posted on our forums. For the first time ever, the Eclipse Foundation is looking to hire a full-time Eclipse platform developer. This position will be responsible for adding new features and fixing bugs in Eclipse under the umbrella of the Friends-Enabled Eclipse IDE/Platform Enhancements Program (FEEP). (Awkward name, great acronym!) The FEEP process ensures that it is the community leadership that guides what new investments we make in the Eclipse IDE and Platform. It is financially supported by the personal and corporate donations that we receive under the Friends of Eclipse program. You can help make Eclipse better with your donations!

Around the middle of this year we also intend to hire a Java Tools Evangelist, who will work with the community to help promote not only the Eclipse IDE, but also newer tool projects such as Eclipse Che.

Like I said, 2016 is off to a great start!



Written by Mike Milinkovich

January 15, 2016 at 11:03 am

Posted in Foundation, Open Source

A Great Start to 2016

Yesterday was quietly one of the biggest days ever for Eclipse. That is because of three new project proposals that went live. It’s certainly unusual for us to have three new projects at once, but I’m not sure if it’s unprecedented. However, I am really excited about these projects, and what they mean for the future of the Eclipse community.

  • Edje is a new IoT project that brings Java functionality to very small devices. It provides a standard hardware abstraction Java API required for delivering IoT services that meet the constraints of small, Arduino-class devices. The initial code contribution for Eclipse Edje is coming from MicroEJ, who has been working in this area for many years.
  • IoT Connector  provides a generic, cloud-based IoT platform architecture which supports the implementation of IoT solutions  requiring device connectivity, device management, and interaction with business applications. The Eclipse IoT Connector project is targeting numerous runtimes such as Cloud Foundry, RabbitMQ and AMQP, and Docker. It is co-led by Bosch and Red Hat, two of the Eclipse Foundation’s Strategic Members.
  • OMR aims to provide a technology platform for building language runtimes. It consists of core components that can be used to build runtimes for languages such as Ruby and Python. These components include: memory management, threading, platform port (abstraction) library, diagnostic file support, monitoring support, garbage collection, and native Just In Time compilation. Eclipse OMR is led by the same folks who build the IBM J9 Java virtual machine.

Several years ago we decided that the Eclipse Foundation was going to start welcoming projects outside of our original comfort zone of tools based on Java and OSGi. It has taken a while to get that message out, but it is clear that it is starting to be heard. None of these project are tools in the traditional Eclipse sense. They are runtimes and frameworks targeting environments from the smallest microcontrollers to the largest clouds.

Each of these projects are very ambitious in their own right. To have all three launched on the same day is crazy cool. I am really looking forward to watching these grow and mature as part of the Eclipse community.

EclipseCon North America March 7-11 in Reston, VA will be the place to be to find out more about these new projects. We’ll have talks on all of them.

Written by Mike Milinkovich

January 14, 2016 at 3:22 pm

Posted in Foundation, Open Source

Eclipse Ships Luna SR1a Git Security Release

Several weeks ago, the Git community announced a new 2.2.1 release which fixed a serious security vulnerability. You can read more here and here. The Eclipse JGit project had their fix available the day that the vulnerability was announced. However, since the vast majority of Eclipse users get their Eclipse via the packages, the decision was made to make new versions of those available as well. I am happy to announce that as of 10:00am Eastern this morning, those new packages are now available for download from Eclipse.

This is the first time the Eclipse community has done a re-spin of our current release for a security issue. Congratulations and thank yous are due to many people, but in particular the JGit project, the webmaster team, and to David Williams and Markus Knauer for all the hard work necessary to make this happen.

Eclipse users who use Git or GitHub through their Eclipse Workbench should either download the new package, or use “Help > Check for Updates” to update their existing installation.

Written by Mike Milinkovich

January 12, 2015 at 10:01 am

Posted in Foundation, Open Source

The Internet of Things Will be Built on Open Source

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

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 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 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 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.

Written by Mike Milinkovich

October 27, 2014 at 8:00 am

Posted in Foundation, Open Source