Life at Eclipse

Musings on the Eclipse Foundation, the community and the ecosystem

Archive for the ‘Foundation’ Category

Measuring Industrial IoT’s Evolution

Today the Eclipse IoT Working Group announced major milestones as IoT’s largest Open Source community:  41 member companies, 37 projects, and 350 contributors. It’s hard to believe that it all started in 2011 with just three projects and the basic goal to reduce the complexity of developing machine-to-machine IoT solutions.

And it’s an interesting day to reflect on “where we are today” on the Industrial IoT adoption curve.

Where the arrival of consumer IoT adoption is obvious in our day to day lives–with smart thermostats, smart doorbells, Alexa and Google voice attendants, and ever more gadgets creeping into our smart homes–industrial IoT’s progress has been much trickier to follow.

Key industries in industrial IoT — like manufacturing — have companies that have been around for 40, 50 and 100 years. There’s an inherent complexity in rolling out new technology in brownfield scenarios. It’s much more difficult to drop new technology into plants with massive existing computer-controlled systems, each with their own alphabet soup of protocols and frameworks that people outside of that industry have never even heard of.

Remember the Earliest Days of the Commercial Internet?

The cleanest way I can think to explain where we are in industrial IoT adoption today is to draw an analogy to the early days of the commercial Internet.

A lot of people’s concept of the Internet’s origins is Mosaic and the advent of the web browser. Sure, the human interface to the web — the modern browser — was a critical enabler for the commercialization of the Internet. But I think the plumbing — and more specifically, the LAMP stack — was the most critical enabler for the Internet’s acceleration from disparate connected systems on academic and science campuses, to the web as we know it today.

The industry’s standardization on the Linux, Apache, MySQL, and PHP scripting language open source “stack” brought uniformity, predictability, and scalability guarantees for everyone building web applications. Those guarantees inspired the massive wave of innovation in web applications that allowed businesses to capture new revenue opportunities, while the underlying stack just worked. Industry doesn’t want to innovate below the value line–it wants to create new services on top of standard infrastructure.

To date, Industrial IoT still awaits its LAMP stack, to give industry the uniform building blocks and graduate away from the proprietary one-offs of the first generations of creating IoT systems. Eclipse IoT represents the largest open source community that’s racing to standardize on those open, interoperable, and flexible components for industrial IoT. It is our conviction that the basic building blocks of the IoT must be open source in order to enable the full array of highly scalable business models necessary to the IoT’s success.

Eclipse IoT: Building the LAMP-Like Stack for Industrial IoT

Let’s take a look at some Eclipse IoT projects that I believe have the same characteristics of modular, open source components, with broad appeal to industrial IoT use cases today. Obviously these aren’t perfectly analogous to Linux, Apache, MySQL and Perl / PHP / Python – but I think the case can be made that they are addressing some of the critical application infrastructure pieces that industrial IoT needs to take off. And just like the LAMP stack, all of these components are 100% open source, and therefore offer the flexibility and permissionless innovation characteristics that helped launch the commercial Internet.

Eclipse Paho

In terms of protocols, Message Queuing Telemetry Transport (MQTT) is the most widely adopted in IoT. While it’s been around for a dozen years, MQTT remains the standard of choice for IoT messaging with 80% of Eclipse IoT Developer survey takers using it. Eclipse Paho is a hardened open source client implementation that focuses on integration with a wide range of middleware, programming and messaging models..

Eclipse Tahu / SparkPlug

MQTT is very lightweight and easy to understand, but does not allow out of the box connectivity. SparkPlug compliments the transport layer–so you can get immediate interoperability. That’s a huge missing piece now. Topic structures, payload structures, all that stuff. Eclipse Tahu extends that capability of SparkPlug and addresses the existence of legacy SCADA/DCS/ICS protocols and infrastructures to provide a much-needed definition of how best to apply MQTT into these existing industrial operational environments.

Eclipse Kura

Kura is a gateway project that provides all the technology you need for building the middle tier in an industrial IOT application. Most IoT implementations have sensors that send telemetry data to some gateway device that does processing at the edge, then determines whether that data needs to be shared with higher order business processes. One of the big responsibilities is protocol translation. Coming in could be any number of low level industrial protocols you’ve never heard of, then going out would be translated for the cloud, over MQTT or HTTP itself. Kura focuses on MQTT–allowing you to data into on premise business process applications or to the cloud for large scale collection. The constrained devices that are collecting data at the edge need to funnel your data back through routers and firewalls, and Kura provides a critical gateway to allow the brokering of data between the sensors, processing at the edge, and publishing via MQTT to IoT cloud platforms such as Eclipse Kapua.

Eclipse ioFog

Where constrained devices are tend to be cheap sensors with limited functionality, edge devices tend to push processing, memory and compute to the edge, to avoid the round-robin back to datacenters and the cloud (which is not possible for latency reasons).


If industry is arguing over how to build and deploy and get interoperability those are extreme barriers to widespread adoption of industrial IoT. That’s the case for an industry standard stack based on common standards, and that’s why we firmly believe the future of IoT will be open source.

There was a version of the Internet that existed for many years. Before the browser came along and before HTTP and HTML, the interfaces to the Internet were command line interfaces that only a very technical person would love. Once the browser came along, there was the possibility of widespread adoption. But the widespread adoption could not have happened if the server side equation were proprietary. We are at a similar inflection point with industrial IoT. The combination of open source, open standards, and the backing of a diverse ecosystem of partners will be key to delivering the interoperability and flexibility required to break free of locked-in, proprietary solutions and see adoption soar.

Written by Mike Milinkovich

February 25, 2019 at 8:00 am

Posted in Foundation

Eclipse Foundation: 15 Years Young

Saturday, February 2, 2019 marks the 15th birthday of the Eclipse Foundation. That was the day that it was publicly and officially announced, and the opening day of the first ever EclipseCon conference.

The creation of the Eclipse Foundation was quite an event at the time. It was really the first time that a member-supported consortium was married to a truly open and meritocratic open source project community. In 2004, the existing open source foundations were organizations like Apache and Mozilla, which are organized as charities. The consortium approach is a model that has become completely normalized (think Linux Foundation, Cloud Foundry, CNCF, etc.), but in 2004 it was very novel. In my personal experience the balance that we have within the Eclipse community between open source development, and fostering the use and adoption of that technology has been incredibly powerful.

There were 50 organizations that were founding members of the Eclipse Foundation, but it should be recognized that IBM, SAP, HP, and Intel did the heavy lifting in drafting the Bylaws and establishing the legal framework for the EF. IBM and SAP remain strategic members of the Eclipse Foundation to this day, and their support is greatly appreciated. From 50 we have grown to over 275, and that growth reflects the continuing relevance of the Eclipse Foundation to the software and broader technology industry.

But it has been the growth of the project community at Eclipse that has been the most exciting. When the Eclipse Foundation was founded 15 years ago, there were about 12 projects hosted here. That number is now over 360. Our committer population has grown from about 150 in 2004 (mostly IBMers) to a very diverse group of almost 1600. But the growth in the breadth of technology hosted at the EF has been striking. Our roots are in desktop developer tools, and the Eclipse IDE remains our most broadly used project. But our community has grown in ways that we never imagined at the outset: modeling and model-based engineering environments, the Internet of Things, automotive technologies, geospatial, and cloud native Java runtimes are all now significant pieces of the overall Eclipse community. What all of these projects have in common are a shared community of practice around the Eclipse Development Process, and our robust intellectual property management.

Interestingly, we’re seeing project growth at the Eclipse Foundation continuing to accelerate. Last year was a record year of project growth. You may assume that was because of the migration of Java EE from Oracle to Jakarta EE at the Eclipse Foundation, but we had significant growth over and above that in other areas such as IoT.

The past 15 years has been an adventure. The Eclipse Foundation has survived and thrived in a world that has changed dramatically over that period of time. But more importantly, the community that we serve has grown and thrived. There are far too many people that deserve a “thank you” than I could possibly list here. But you know who you are. So thanks to all, and looking forward to many more years of success for the Eclipse community.

Written by Mike Milinkovich

February 1, 2019 at 3:00 am

Posted in Foundation

New Eclipse Foundation Committer and Contributor Agreements

Note: to see redline versions of the changes to the documents discussed below, please visit this contribution and committer agreements page.

Over my almost 15 years of sharing updates about what’s going on at Eclipse, some blogs are more important than others.  This one is important as it requires action by our members, committers, and contributors!  There is a lot of ground to cover explaining what’s going on and why we’re changing things, so please forgive me for a longer than normal post.

tl;dr.  The Eclipse Foundation is starting to develop specifications. First for Jakarta EE, but soon for other areas as well. We want to make it clear that contributions to our open source projects may someday be used to create a specification, because we believe in code-first innovation. We also believe that if you’re contributing to open source, you want your contributions to be used for open purposes, including specs.

We are updating our standard contributor and committer agreements, and we will be requiring all our committers and contributors, as well as those members who have member committer agreements,  to re-sign their agreement with us.

To make this happen, we will be reaching out to everyone who needs to re-sign.  You don’t have to do anything yet – just be aware the change is coming, and please act when we do make contact with you.

First, a bit of background.  All contributions and commits made to any Eclipse Foundation project are covered by one of three distinct agreements – the Member Committer Agreement, the Individual Committer Agreement, or the Eclipse Contributor Agreement.

These agreements basically say that if you contribute to an Eclipse project, your contributions are being made under the license of the project. That license is usually the Eclipse Public License, but about 20% of our projects using additional or alternate licenses such as the Apache License, BSD, or MIT. It is important to note that the way things work at the Eclipse Foundation, the Foundation itself does not acquire any rights to the contributions. This is very different from other organizations like the FSF, OpenJDK, or the Apache Software Foundation. Eclipse uses a licensing model sometimes referred to as symmetrical inbound/outbound licensing, where contributors license their code directly to the users (recipients) of their contributions. Our approach requires us to ensure that all of our contribution agreements provide all necessary grants because we at the EF don’t have any rights to re-license contributions.

As most are aware, Eclipse is now about to start hosting specifications as open source projects.  This is very exciting for us, and we think it represents a new opportunity for creating innovative specifications using a vendor neutral process.  The first specification projects will be a part of the Jakarta EE initiative, but we expect other specification projects to follow shortly.

Everyone expected to re-sign one of these is encouraged to ensure they understand the details of the agreements and to seek their own legal advice. However, the change we have made is basically to ensure the copyrights in contributions to Eclipse projects may be used in specifications as well. (For the lawyers in the crowd, please note that these additional grants do not include patents.) We certainly expect that our committers and contributors are fine with this concept. In fact, I assume that most folks would have expected that this was already obvious when they contributed to an open source project. To that, all I can say is….ahhhh…the lawyers made us do it.

The new agreements are already posted, so they are in immediate effect for new contributors and committers. Since we need to overhaul our contribution agreements, we are also taking this opportunity to fix a few things. In particular, our committers will know that up until now they’ve been required to be covered by both a committer agreement and the ECA. We’re going to fix that, so if you sign an Individual Committer Agreement, or are covered by your employer’s Member Committer Agreement, you will no longer have to personally sign an ECA. We are also going to implementing electronic signatures for ICAs using HelloSign. So going forward there is going to be a little less paper involved in being a committer. Yay!

We’re sensitive that asking our contributors and committers to ‘update their paperwork’, especially if they’re not working on a specification, is – well, a pain in the backside.  But we’re hoping everyone will be supportive and understanding, and recognize that we take IP very seriously, and it’s one of the real value propositions of working with Eclipse.

Contributors who have an ECA will see them revoked over the coming months, and will be asked to re-sign the new one. We will be starting first with the contributors to the EE4J projects, since they are the ones who are most likely to have contributions flowing into Jakarta EE specifications.

Executing this change represents a massive effort for our team, as it literally means updating hundreds of committer agreements.  Our staff will be emailing individually each individual and member company needing to update their agreement with us, but we will be spread it over a period of the next few months.  So don’t be surprised if you don’t get an email for a while – we will get to everyone as soon as we can.

Stay tuned for emails on this subject that will be sent to our various mailing lists with more details.  If you have questions, feel free to reach out to us at and we’ll do our best to provide answers.

I thank our entire community in advance for accommodating this significant change.  We are excited about the Eclipse Foundation hosting an even more vibrant collection of projects, and believe hosting open source specification projects is a great step forward in our evolution!

Written by Mike Milinkovich

November 5, 2018 at 1:27 pm

Introducing the Jakarta EE Specification Process

I am very happy to announce that we are publishing a draft of the Eclipse Foundation Specification Process for community review and feedback. This specification process will be used by Jakarta EE as the new open specification process, replacing the JCP process previously used for Java EE. It is also expected that this new process will be of interest to other Eclipse working groups.

We are really looking forward to your feedback, which you can do via the Jakarta EE Community mailing list (preferred), or on the document comments.  The feedback provided will be used as input to finalizing a first version of the specification process and its adoption by Jakarta EE and other working groups at the Eclipse Foundation.  

As you are reviewing this draft specification process, please keep in mind the following key points about the approach that was taken by the Specification Committee.

  1. We want to design a specification process to replace the JCP. While there are many differences with the JCP, the key objective was to make the whole process as lightweight as possible.
  2. We want the specification process to be as close to open source development as possible. This is actually not a trivial exercise, as by its very nature drafting specifications is a somewhat different process.
  3. This is the Eclipse Spec Process, so we want to reuse the Eclipse Development Process wherever possible, and we want to ensure that the general flow and tone of the EDP is followed.
  4. We want to create a process that allows code-first development. Specifically, we want to enable a culture where experimentation can happen in open source and then have specifications be based on those experiences.
  5. We want the specifications that result from this process to be as high quality as possible. In particular, this means that we need to take care of the intellectual property flows, and to protect the community’s work from bad actors. This requirement manifests as two fundamentally important differences from the EDP:
    • Specification Committee approval is required for releases from Spec Projects, in addition to the normal PMC approval; and
    • We introduce the notion of “Participants” who are committers who represent specific member companies on a Spec Project. This is necessary to ensure that the IP contributions (particularly patents) from companies are properly captured by the process.

All of us at the Eclipse Foundation would like to recognize the tireless efforts of the members of the Specification Committee. A lot of hard work has gone into this document, and it’s very much appreciated. We are certain that Jakarta EE, and many other Eclipse technologies, benefit from the thoughtful efforts of this Committee.  In particular, we would like to thank the following Specification Committee members and alternates:

Fujitsu: Kenji Kazumura​, Mikel DeNicola
IBM: Dan Bandera​, Kevin Sutter
Oracle: Bill Shannon​, Ed Bratt​, Dmitry Kornilov
Payara: Steve Millidge​, Arjan Tijms
Red Hat: Scott Stark, Mark Little
Tomitribe: David Blevins​, Richard Monson-Haefel
PMC Representative: Ivar Grimstad
Elected Members: Alex Theedom, Werner Keil​

I also wish to recognize Tanja Obradovic and Wayne Beaton from the Eclipse Foundation team who have driven the process throughout – many thanks to you both!

Written by Mike Milinkovich

October 16, 2018 at 3:18 pm

Posted in Foundation, Jakarta EE, Open Source

Tagged with , ,

Case Study: How Bosch Is Succeeding with Open Source at Eclipse IoT

How is it that a 150-year-old, 400,000 employee industrial conglomerate is competing and winning in the rapidly involving IoT software industry? We’ve just published a case study in which Bosch shares how open collaboration at the Eclipse Foundation factors into that success. This case study is required reading for any organization considering pursuing an open source strategy.

This case study is yet another proof point that open source has won. No single company can deliver innovation at the pace and scale of open source. For industrial companies in particular, broadly adopted open technologies and standards are critical for success in the digital economy. It’s a case of disrupt or be disrupted — and open source holds the key for rapid and sustainable innovation in the digital age. The team at Bosch recognized all of this several years ago. When the time came for creating an IoT platform for themselves and their customers, Bosch chose open source to compete with proprietary vendors.

At the Eclipse Foundation, Bosch is successfully executing a long-term strategy to create a widely adopted open source platform for IoT. Having previously been a long-term Solutions member of the Eclipse Foundation, Bosch increased its membership level in the Eclipse Foundation to become a Strategic member and joined the Eclipse IoT Working Group in 2015. Beyond IoT, Bosch is an active participant in the Eclipse Foundation’s Automotive Industry community.

Some of the highlights from the case study (html) (pdf):

  • Bosch’s leadership in the Eclipse IoT community has helped position the company as a leader in the IoT industry.
  • Bosch has created six different IoT open source projects since joining the Eclipse IoT community. In addition, Bosch contributes to many other Eclipse IoT projects.
  • Bosch has contributed around 1.5 million lines of code to Eclipse projects. At present, over 60 Bosch developers work on Eclipse IoT projects.
  • Many of the Bosch IoT Suite commercial products are now based on Eclipse IoT projects. The open development process used by the Eclipse projects has been adopted by Bosch Software Innovations’ product development teams. The open source development model helps Bosch provide more transparency for their customers, and aids in recruiting new developers keen to work on open source.
  • The Eclipse Foundation’s clear, vendor-neutral rules for intellectual property sharing and decision-making make it easy to collaborate with other organizations on driving rapid innovation. The Foundation’s legal processes provide Bosch with the legal assurance that they can successfully embed open source technology into their commercial products.

We are thrilled that Bosch is seeing the benefits of their open source strategy and participation in the Eclipse community. Thanks to the contributions of Bosch engineers and many other developers within the Eclipse community, all can benefit from runtimes and frameworks creating a open, vendor-neutral platform for IoT.

To learn more about the Eclipse IoT community, head over to the Eclipse IoT Working Group website.

Written by Mike Milinkovich

October 2, 2018 at 8:04 am

Posted in Foundation

Jakarta EE Status – September 2018 Update

Migrating Java EE to the Eclipse Foundation and Jakarta EE is a process not an event. In the past couple of weeks however, several very important milestones have occurred that deserve to be recognized.

  • 100% of Glassfish and related Java EE reference implementation components from Oracle have now been contributed, and published to GitHub repositories of the EE4J organization. For those of us at the Eclipse Foundation, part of the reason why this is so huge is that to a large degree, we’ve completed our part. The repos (99) have been provisioned, the committers (162) have been given access, and the initial intellectual property reviews (404) have been done. From this point on, progress on the projects is now largely under the control of the projects themselves.


  • Builds for the EE4J projects are now running on Eclipse Foundation infrastructure based on our Jenkins-based Common Build Infrastructure.
  • The Java EE TCKs have been contributed and are now available in open source. The importance of this cannot be understated, as my colleague Tanja Obradović points out in her blog.
  • The Eclipse Foundation has signed the Oracle Java EE TCK agreement, which is going to allow us to ship Eclipse Glassfish certified as Java EE 8 compatible. This has also required us to create a testing infrastructure at the Eclipse Foundation, and allowed the EE4J projects to begin testing against the Java EE 8 TCKs.
  • IBM, Oracle, Payara, Red Hat, and Tomitribe have all committed to three years of funding for Jakarta EE ranging from $25K to $300K per year. This funding will allow us to create a dedicated team and fund marketing activities for the Jakarta EE Working Group.

This migration has been an enormous effort, and we certainly have a ways to go yet. But it’s always fun to celebrate some victories along the way.

If you are interested in learning more about Jakarta EE and the future of cloud native Java, please join us at EclipseCon Europe in Germany in October. There is a wealth of Jakarta EE and MicroProfile content. In particular, I hope to see you at the talk that I am doing with Wayne Beaton about the new specification process. Oh, and there’s also this other conference happening in San Francisco at the same time….


Written by Mike Milinkovich

September 27, 2018 at 5:21 pm

Posted in Foundation, Open Source

K8s at the Edge – Some Context on the New Kubernetes IoT Working Group

It’s hard to believe that Google released Kubernetes as an open source project only three years ago. What began as the Borg cluster management platform to provide services like Gmail and YouTube at global scale is now the standard orchestration layer at the center of a massive industry shift to cloud native.

Enterprises are being catapulted into system resource engineering concepts that have been the bedrock of operations at web-scale leaders like Google and Netflix, and the open source stack underneath it all is evolving so fast it’s hard to keep up.  Kubernetes is attracting all sorts of exciting frameworks and services (see projects like Istio and Envoy), and no one could have anticipated it having this degree of momentum.

So what does any of this have to do with IoT?

The Eclipse Foundation is excited to be part of today’s announcement of a new Kubernetes IoT Edge Working Group – in conjunction with CNCF and supported by leading vendors like Bosch, Eurotech, InfluxData, Red Hat, Siemens, Vapor IO, and VMware.  

Eclipse Foundation has a lot on the go with IoT — 2.93 million lines of code (by last count), 42 different member organizations, 36 projects and 280 developers. The pace of innovation in IoT is very fast, and there are still a lot of great unsolved challenges at the IoT Edge.

Kubernetes was born in the datacenter. Its original promise was bridging datacenter and cloud.

But Kubernetes has a ton of potential for handling massive workloads on the edge — providing a common control plane across hybrid cloud and edge environments to simplify management and operations. Chick-fil-A, for example, is running Kubernetes at the edge in every restaurant.

Some of the great unsolved problems at the IoT edge — connectivity, manageability, scalability, reliability, security challenges, how to bring compute resources closer to edge devices for faster data processing and actions — are being solved as one-offs by the enterprises that are jumping into IoT. This new working group sees Kubernetes as having great potential as a foundational technology for extending hybrid environments to the IoT edge, and believes that broader industry collaboration on requirements definition around Kubernetes will accelerate broader adoption of IoT. Once again, it’s the rising tide theory of open source.

As Red Hat’s Dejan Bosanac (lead for the Kubernetes IoT Edge Working Group) says:

“IoT and edge applications have many distributed components that don’t usually sit together within the same datacenter infrastructure. There are messaging challenges, security has to be re-invented for every application and service, and there are integration and data locality issues with sidecar services. These are issues that shouldn’t have to be re-invented every time — they should be open source infrastructure with broad industry support. Red Hat and this working group see Kubernetes and other cloud-native projects in its orbit as having broad potential sitting between gateways, edge nodes and cloud platforms. Much like the LAMP stack was instrumental to the web-applications era, this group is focused on accelerating a Kubernetes stack for running cloud infrastructure and distributed components at the IoT edge.”

Some of the initial targets for the group in how it evolves Kubernetes for IoT edge applications:

  • Supporting Industrial IoT (IIoT) use cases scaling to millions of constrained devices a) connecting directly to Kubernetes-based cloud infrastructure (IP enabled devices), or b) connecting via IoT gateways (for non-IP enabled devices)
  • Via Edge nodes, bringing computing closer to data sources to support processing and acting on data sooner. Anticipated benefits include reduced latency, lower bandwidth, and improved reliability. Some example use cases:
    • Deploying data streaming applications to the Edge nodes in order to reduce traffic and save bandwidth between devices and the central cloud.
    • Deploying a serverless framework for using local functions that can be triggered as a response to certain events (without communication with the cloud)
  • Providing a common control plane across hybrid cloud and edge environments to simplify management and operations

The initial focus of the working group will be to flesh out IoT edge computing use cases and see how Kubernetes can be used (and to what extent). Among some of  the requirements identified so far:

  • For IIoT applications, the Kubernetes ingress layer must scale to millions of connections
  • That same ingestion layer must provide first-class support for IIoT messaging protocols such as MQTT (it is primarily HTTP TLS centric today)
  • Kubernetes must support multi-tenancy for environments where devices and gateways are shared

There have been a lot of industry watchers who have been wondering aloud how high the ceiling is for Kubernetes. Container orchestration seems like such a specific technology – how can this technology reach this type of ubiquity? Well one thing is clear – Kubernetes has jumped the datacenter and is now clearly in play in IoT ($1.2T market by 2022, according to IDC) as well. We are excited to be collaborating with the Kubernetes community to enable next generation of IoT applications.

To learn more, head over to the Kubernetes IoT Edge Working Group community page.

Have specific ideas for how you’d like to see Kubernetes evolve to meet your IoT use cases? Check out the this working document where you can get a sense of the progress so far, and the areas where you could possibly contribute your talents.

Written by Mike Milinkovich

September 26, 2018 at 7:00 am

Posted in Foundation, Open Source