Archive for the ‘Foundation’ Category
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.
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….
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.
Jakarta EE Progress to Date
Last September Oracle announced, with the support of IBM and Red Hat, that Java EE was going to move to the Eclipse Foundation. Since then Fujitsu, Payara and Tomitribe have all joined the initiative with strategic-level commitments. The scale of this migration is huge, and if you’re interested in understanding the complexity of the undertaking, I highly recommend you read On Complexity and Good Intentions.
Roughly eight months later, let’s see how we are doing compared to the goals set out in Oracle’s original announcement.
- Relicense Oracle-led Java EE technologies, and related GlassFish technologies, to the Foundation. This would include RIs, TCKs, and associated project documentation.
This has been the major accomplishment to date. The Eclipse Enterprise for Java (EE4J) top-level project has been created, and thirty-nine projects established. We don’t yet have all of the source code moved over, but you can follow the steady progress on the project status page. All of the projects are using the same license: Eclipse Public License 2.0 plus (Secondary) GNU General Public License, version 2 with the GNU Classpath Exception.
- Demonstrate the ability to build a compatible implementation, using Foundation sources, that passes existing Java EE 8 TCKs.
This is what the project community is working towards next, and it is going to be a Very Big Deal. Keep in mind that to accomplish this goal, we are going to have to complete the creation of 39 projects, get them building on eclipse.org infrastructure, run the Java EE 8 CTS on those builds, and then get all of the projects together to ship on the same day. There is an enormous amount of work and learning to be done before this release becomes a reality.
- Define a branding strategy for the platform within the Foundation, including a new name for Java EE to be determined. We intend to enable use of existing javax package names and component specification names for existing JSRs to provide continuity.
In the first quarter of 2018, the Eclipse Foundation worked with the community to establish a new name and a logo for the future of this technology. So Jakarta EE was born, and we’re very excited about the new name and the logo. Folks who have been around the Java world for a long time will recognize the name “Jakarta,” as the Apache Software Foundation’s had a long-lived incubator under that name. With their kind permission what was old is new again. We’re really excited about once again seeing Java innovation happening under the Jakarta banner.
- Define a process by which existing specifications can evolve, and new specifications can be included in the platform.
The first step in creating this process was to establish the Jakarta EE Working Group, which will be the governing body for this community moving forward. This was completed back in March, and the various committees are hard at work.
Discussions to create the new Jakarta EE Specification Process are underway, and early results are promising. This is going to be a very large job, but one which is essential to the future of this technology.
- Recruit and enable developers and other community members, as well as vendors, to sponsor platform technologies, and bring the platform forward within the foundation. This would include potential incorporation of Eclipse MicroProfile technologies into the platform.
So far so good. Since the original announcement with Oracle, IBM and Red Hat back in September, here is the list of companies that have joined the initiative:
Strategic Members: Fujitsu, Payara, and Tomitribe
Participating Members: DocDuko, Genuitec, IncQueryLabs, Lightbend, London Java Community, Microsoft, Pivotal, RCPVision, SAP, UseOpen, Vaadin, and Webtide.
More importantly, we’ve seen a lot of developers from the Java EE community jump in and participate in the new projects as they’ve been set up. It has been great to welcome so many new people to the Eclipse community.
Eclipse MicroProfile has not joined the Jakarta EE initiative. But those conversations cannot even really start until the new specification process is available for that community to review.
- Begin doing the above as soon as possible after completion of Java EE 8 to facilitate a rapid transition.
We’ve all been busy! It’s hard to say if the transition has been rapid enough, but everyone involved has been working hard and making progress. The process has not been and will not be perfect. With so many moving parts, people, and technologies, perfection is the enemy of good. But we’ve been very excited by the process we’re making. In particular, we have been excited by the passion and energy of the Java EE community as they have embraced the future with Jakarta EE.
A New Logo for the Eclipse Foundation
Since the beginning of the Eclipse Foundation in 2004 we have had two corporate logos, both of which happened to be the same logo as used by the Eclipse IDE. For a long time that was a good idea, as the Eclipse IDE was definitely our flagship project.
However, as the role of our Foundation has changed, that has made less and less sense. With exciting new technologies such as Jakarta EE, IoT, machine learning, quantum computing, etc., tying our identity to just one of our 350 projects makes it a lot more difficult to explain. Our visual identity needs to line up with our role as a platform and environment for developers and organizations to collaborate.
To that end, we are going to soon be rolling out a new logo and website look-and-feel for the Eclipse Foundation. Our web team lead Christopher Guindon has blogged about what the new website look-and-feel will be like. It includes both a refresh in the look and feel, while still making it simple for developers to get to their favorite projects and downloads.
But first, I get the exciting job of sharing our new logo with the world. We really like it, and hope you do too!
Life at Eclipse 