Life at Eclipse

Musings on the Eclipse Foundation, the community and the ecosystem

Archive for the ‘Foundation’ Category

Add Your Voice to the 2020 Jakarta EE Developer Survey

leave a comment »

Our third annual Jakarta EE Developer Survey is now open and I encourage everyone to take a few minutes and complete the survey before the April 30 deadline. Your input is extremely important.

With your feedback, the entire Java ecosystem will have a better understanding of the requirements, priorities, and perceptions in the global Java developer community. This understanding enables a clearer view of the Java industry landscape, the challenges Java developers are facing, and the opportunities for enterprise Java stakeholders in the cloud native era.

The Jakarta EE Developer Survey is one of the Java industry’s largest developer surveys. Since the survey’s inception, we’ve received thousands of responses from developers around the world, including 1,700 responses in 2019 — a clear indication the Java developer community recognizes the value of the survey results.

Last year, we were able to share critical insight into the state of cloud native innovation for enterprise Java development globally, including expected growth rates for Java apps in the cloud as well as leading architectures, applications, and technologies. We were also able to share the community’s top priorities for Jakarta EE.

This year, we’re asking developers to tell us more about their next steps for Java and cloud native development and their choices for architectures, technologies, and tools as cloud native resources for Java mature.

With this updated information, platform vendors, enterprises, and individual developers in the Java ecosystem will have a better understanding of how the cloud native world for enterprise Java is unfolding and what that means for their strategies and businesses. And the Jakarta EE community at the Eclipse Foundation will have a better understanding of the community’s top priorities for future Jakarta EE releases.

The Jakarta EE Developer Survey is your opportunity to add your voice to the global Java ecosystem and we’re counting on our entire community to help us gain the broadest possible view of the state of cloud native technologies in the context of enterprise Java. Best of all, this year we’ve organized the survey so it takes less than 10 minutes to complete!

To access the survey, click here.

Written by Mike Milinkovich

April 7, 2020 at 8:02 am

Theia: An Open Source Alternative to Visual Studio Code

leave a comment »

With the release of Eclipse Theia 1.0, organizations and vendors that build cloud and desktop integrated development environments (IDEs) have a production-ready, vendor-neutral, and open source framework for creating customized development environments for both desktops and browsers. Theia is an all-new code base with independent governance from the Eclipse desktop IDE.

Theia delivers an open source, extensible and adaptable platform that provides all of the capabilities of VS Code but which can be tailored to specific use cases. It can also leverage all of the extensions available for Microsoft Visual Studio (VS) Code — one of the world’s most popular development environments.

Industry Leaders Are Adopting Theia

The Theia project was started in 2016 by Ericsson and TypeFox. In addition to Eclipse Che using Theia as its web IDE, many organizations of all sizes rely on Theia as the foundational building block for their development environments:

  • Arm Mbed Studio builds on the Theia IDE
  • Google Cloud Shell runs Theia as its editor
  • The default IDE for Red Hat CodeReady Workspaces is based on Eclipse Theia
  • The frontend of Arduino Pro IDE is based on Theia
  • Gitpod’s development environment is based on Theia
  • SAP Business Application Studio (the next generation of SAP Web IDE) is based on Theia

Other prominent adopters include D-Wave Systems, EclipseSource, and IBM.

Last year, Theia’s momentum and adoption reached the point where the project team approached the Eclipse Foundation to host the project. With over 375 open source projects, we’ve established a track record of the vendor-neutral governance, processes, and the community building needed to further guide Theia’s growth.

Today, Theia is one of the Eclipse projects promoted by the Eclipse Cloud Development Tools Working Group (ECD WG), an industry collaboration focused on delivering development tools for, and in, the cloud.

Theia Goes Beyond VS Code

Theia is being developed by a diverse group of contributors, committers and supporting companies such TypeFox, Ericsson, Red Hat and ARM. With over fifty committers and contributors over the past three months, it is a fast-moving, welcoming, and open community where contributions are accepted from all.

Theia’s more than an alternative to VS Code. The main differentiator between Theia and VS Code is that Theia is specifically intended to be adopted by other companies and communities to build and deploy a modern web-based developer experience. VS Code is great, but it is only ever going to be a Microsoft product.

Theia is intended to be modified, extended, and distributed by folks who want to create developer tools that look as great as VS Code (including using the same Monaco Editor) and can make use of the VS Code extension ecosystem. Of course, it is licensed under the EPL 2.0, so it is easy for organizations or individuals to build and ship products using Theia.

Theia also provides important advantages that give IDE developers considerably more freedom and flexibility than VS Code offers. For example, Theia’s architecture is designed to be more modular and extensible than the VS Code so developers have a greater ability to customize their solutions for specific requirements. VS Code enables a great extension ecosystem. Theia goes beyond that and is designed to be modified and extended at all levels of its architecture.

In addition, Theia is designed from the ground up to run in both desktop environments as well as in browser and remote server environments. IDE developers can write the source code for their development environment once, then build a desktop IDE, a cloud IDE, or both, without rewriting any code. With Theia, it’s easy to move between desktop and cloud environments at any time.

Theia uses the Eclipse Open VSX Registry, an open-source alternative to the Microsoft Visual Studio marketplace. In the spirit of a true open source community, the extensions available in this free marketplace can be used in VS Code as well as in Theia.

Just the Beginning for Eclipse Theia

This first official Theia release confirms the technology is mature, stable, and ready for anyone and everyone to use as a foundation for their custom cloud or desktop IDE. Future releases will provide a desktop download for developers who want to use Theia directly as their development tool.

I want to sincerely thank everyone involved in bringing this important advance in open source cloud development tools to this critical point. With the excitement and rapid uptake that Theia has experienced, I’m sure this is just the first of many successful releases.

I encourage IDE developers to join the world-leading organizations that are already using Theia so they can start benefiting from its capabilities and flexibility.

To get involved with the Eclipse Theia Project and begin contributing, please visit https://theia-ide.org/.

For more information about the Eclipse Cloud Development Tools Working Group, view the Charter and ECD Working Group Participation Agreement (WGPA), or email membership@eclipse.org. You can also join the ECD Tools mailing list.

Written by Mike Milinkovich

April 1, 2020 at 12:06 pm

Posted in Foundation, Open Source

Real-World IoT Adoption

The results of our first IoT Commercial Adoption survey tell a clear story about what organizations are doing with IoT right now and their plans for production deployments. The goal of the survey was to go beyond the IoT Developer Survey we’ve conducted for the last six years to gain insight into the industry landscape from the point of view of a broader spectrum of IoT ecosystem stakeholders.

Here are some of the key findings from the survey:

  • IoT may well live up to the hype, if somewhat slower than expected. Just under 40 percent of survey respondents are deploying IoT solutions today. Another 22 percent plan to start deploying IoT within the next two years.
  • IoT investment is on the rise, with 40 percent of organizations planning to increase their IoT spending in the next fiscal year.
  • Open source pervades IoT as a key enabler with 60 percent of companies factoring open source into their IoT deployment plans.
  • Hybrid clouds lead the way for IoT deployments. Overall, AWS, Azure, and GCP are the leading cloud platforms for IoT implementations.

The Commercial Perspective Is Crucial

The survey asked respondents to identify the requirements, priorities, and challenges they’re facing as they deploy and start using commercial IoT solutions, including those based on open source technologies. The survey ran for two months last fall and received responses from more than 360 individuals from a wide range of industries and organizations. You can read the full survey results here, and I would encourage IoT ecosystem players to do that.

IoT Ecosystem Players Must Focus on Real-World Requirements

As our survey results revealed, each player in the IoT ecosystem has an important role in driving IoT adoption. Here are some key takeaways broken down by stakeholder group.

  • Software vendors should incorporate open source technologies into their solutions to give customers the flexibility and control they need.
  • IoT platform vendors should build offerings that support hybrid cloud environments to become more responsive to customer requirements. At least part of the reason multi-cloud adoption is still in its early stages is because — not surprisingly — the leading cloud providers don’t offer their IoT platform services on other cloud platforms.
  • IoT solution providers should be prepared for extensive and intensive proofs of concept and pilot projects before they get to the stage of full production rollouts. With companies reluctant to invest heavily in IoT before they’re confident in the return on investment, these practical and tangible demonstrations will be key to encouraging broader adoption.
  • Manufacturing organizations should implement IoT solutions that tie automation, asset management, and logistics together. The most innovative organizations will also rely on IoT technologies to improve their value proposition to customers, for example, by including preventive maintenance features on manufacturing equipment.

Get Involved in Eclipse IoT

It will take a diverse community co-developing a uniform set of building blocks based on open source and open standard to drive broad IoT adoption. If you’re interested in participating in the industry-scale collaboration happening at the Eclipse IoT Working Group or contributing to Eclipse IoT projects, please visit https://iot.eclipse.org/.

As an added benefit of membership, Eclipse IoT Working Group members receive exclusive access to detailed industry research findings, including those from the annual IoT Developer Survey, which are leveraged by the entire industry.

The 2020 IoT Developer Survey is coming soon. If you’d like to contribute questions or provide feedback, join the working group mailing list here.

Written by Mike Milinkovich

March 10, 2020 at 12:57 pm

Sparkplug: Standardizing Industrial IoT Communications

With the launch this week of the Sparkplug Working Group, we’re bringing together the industry leaders and technologies needed to drive development and broad adoption of the Eclipse Sparkplug specification for open, interoperable, Industrial IoT (IIoT) solutions that use the MQTT protocol.

MQTT is an open and lightweight publish-subscribe messaging protocol that was first developed in the late 1990s for real-time message transport in Supervisory Control and Data Acquisition (SCADA) systems. Because it’s designed for low-bandwidth, low-power environments, it’s ideal for IIoT and industrial automation applications that rely on data from massive numbers of sensors.

Sparkplug Augments MQTT With IIoT Interoperability Essentials

Today, MQTT is the dominant messaging protocol for IIoT applications, but it doesn’t define the data format and it doesn’t address issues around device compatibility and interoperability — capabilities that are essential in IoT environments where all device and software services must share a common data format and support the same life cycle stages of device information.

The Sparkplug specification will resolve these issues. It will define an MQTT topic namespace, payload, and session state management approach that can be applied generically. The goal is to provide standardization for most MQTT devices out of the box so vendors, manufacturers, and industrial end users can develop an ecosystem of solutions and devices that can easily interoperate.

Broad Support Across Industries

With the Sparkplug Working Group’s focus on specifications and implementations that rationalize industrial data and improve the interoperability and scalability of IIoT solutions, companies in industries ranging from oil and gas to energy, manufacturing, and smart cities will have an overall framework to support their evolution to Industry 4.0.

The breadth and stature of the Sparkplug Working Group’s founding members confirm the huge need for industrial system interoperability and the value of the Sparkplug initiative across industries. Founding members include global leaders, such as Chevron, Canary Labs, Cirrus Link Solutions, HiveMQ, Inductive Automation, and ORing.

These companies, and others, are embracing Sparkplug to take IIoT applications to the next level with MQTT implementations that provide valuable, real-time information in a highly reliable, scalable, and secure way.

Get Involved With Sparkplug

I’m very excited about the huge potential and opportunities that will open up for everyone involved in IIoT and industrial automation as the Sparkplug Working Group pushes forward to standardize MQTT device communications. This is truly transformative technology, and I want to sincerely thank all of the corporations and individuals who have brought us to this point.

To get involved with the Eclipse Sparkplug Working Group and contribute to the project, please visit https://sparkplug.eclipse.org.

Also, the Eclipse Foundation and our member companies will be showcasing the Sparkplug Working Group at the ARC Advisory Group’s 24th Annual Industry Forum, February 3-6 in Orlando. If you’re at the Forum, be sure to drop by Inductive Automation’s booth (booth #25) to learn more.

Written by Mike Milinkovich

February 6, 2020 at 8:08 am

Posted in Foundation, Open Source

Cloud Native for Java Day @ KubeCon EU

Cloud Native for Java (CN4J) Day at KubeCon + CloudNativeCon Europe will be the first time the best and brightest minds from the Java ecosystem and the Kubernetes ecosystem come together at one event to collaborate and share their expertise.

The all-day event on March 30 includes expert talks, demos, and thought-provoking sessions focused on building cloud native enterprise applications using Jakarta EE-based microservices on Kubernetes. CN4J Day is a proud moment for all of us at the Eclipse Foundation as it confirms the Jakarta EE and MicroProfile communities are at the forefront of fulfilling the promise of cloud native Java. We’re excited to be working with our friends at the CNCF to offer this event co-located with KubeCon Europe.

A Unique Opportunity to Engage With Global Experts

The timing of CN4J Day could not be better. With momentum toward the Jakarta EE 9 release building, this event gives all of us an important and truly unique opportunity to:

  •     Learn more about the future of cloud native Java development from industry and community leaders
  •     Gain deeper insight into key aspects of Jakarta EE, MicroProfile, and Kubernetes technologies
  •     Meet and share ideas with global Java and Kubernetes ecosystem innovators

The global Java ecosystem has embraced CN4J day and several of its leading minds will be on-hand to share their insights. Along with keynote addresses from my colleague Tanja Obradovic and IBM Java CTO, Tim Ellison, CN4J Day features informative technical talks from Java experts and Eclipse Foundation community members, such as:

  •     Adam Bien, an internationally recognized Java architect, developer, workshop leader, and author
  •     Sebastian Daschner, lead java developer advocate at IBM
  •     Clement Escoffier, principal software engineer at Red Hat
  •     Ken Finnegan, senior principal engineer at Red Hat
  •     Emily Jiang, liberty architect for MicroProfile and CDI at IBM
  •     Dmitry Kornilov, Jakarta EE and Helidon Team Leader at Oracle
  •     Tomas Langer, Helidon Architect & Developer at Oracle

Major Industry and Ecosystem Endorsement

Leading industry players in the Java ecosystem are also showing their support for CN4J Day through sponsorship. Our sponsors include:

  •     Cloud Native Computing Foundation (CNCF)
  •     IBM
  •     Oracle
  •     Red Hat

The event is being coordinated by an independent program committee composed of Arun Gupta, principal technologist at Amazon Web Services, Reza Rahman, principal program manager for Java on Azure at Microsoft, and Tanja Obradovic, program manager for Jakarta EE at the Eclipse Foundation.

Register Today

To register today, simply add the event to your KubeCon + CloudNativeCon Europe registration. Thanks to the generous support of our sponsors, a limited amount of discounted CN4J Day add-on registrations will be made available to Jakarta EE and MicroProfile community members on a first-come, first-served basis.

For more details about CN4J Day and a link to the registration page, click here. For additional questions regarding this event, please reach out to events-info@eclipse.org.

As additional speakers and sponsors come onboard, we’ll keep you posted, so watch for updates in our blogs and newsletters.

Written by Mike Milinkovich

January 28, 2020 at 7:00 am

Moving Forward With Jakarta EE 9

On behalf of the Jakarta EE Working Group, I am excited to announce the unanimous approval of the plan for Jakarta EE 9, with an anticipated mid-2020 release. Please note that the project team believes this timeline is aggressive, so think of this as a plan of intent with early estimate dates. The milestone dates will be reviewed and possibly adjusted at each release review.

If you have any interest at all in the past, present, or future of Java, I highly recommend that you read that plan document, as Jakarta EE 9 represents a major inflection point in the platform.

The key elements of  this Jakarta EE 9 release plan are to:

  • move all specification APIs to the jakarta namespace (sometimes referred to as the “big bang”);
  • remove unwanted or deprecated specifications;
  • minor enhancements to a small number of specifications;
  • add no new specifications, apart from specifications pruned from Java SE 8 where appropriate; and
  • Java SE 11 support.

What is not in the plan is the addition of any significant new functionality. That is because the goals of this Jakarta EE 9 release plan are to:

  • lower the barrier of entry to new vendors and implementations to achieve compatibility;
  • make the release available rapidly as a platform for future innovation; and
  • provide a platform that developers can use as a stable target for testing migration to the new namespace.

Moving a platform and ecosystem the size and scale of Jakarta EE takes time and careful planning. After a great deal of discussion the community consensus was that using EE 9 to provide a clear transition to the jakarta namespace, and to pare down the platform would be the best path to future success. While work on the EE 9 platform release is proceeding, individual component specification teams are encouraged to innovate in their individual specifications, which will hopefully lead to a rapid iteration towards the Jakarta EE 10 release.

Defining this release plan has been an enormous community effort. A lot of time and energy went into its development. It has been exciting to watch the … ummm passionate…. discussions evolve towards a pretty broad consensus on this approach. I would like to particularly recognize the contributions of Steve Millidge, Kevin Sutter, Bill Shannon, David Blevins, and Scott Stark for their tireless and occasionally thankless work in guiding this process.

The Jakarta EE Working Group has been busy working on creating a Program Plan, Marketing Plan and Budget for 2020. The team has also been very busy with creating a plan for the Jakarta EE 9 release. The Jakarta EE Platform project team, as requested, has delivered a proposal plan to the Steering Committee. With their endorsement, it will be voted on by the Specification Committee at their first meeting in January 2020.

Retrospective

The Jakarta EE 9 release is going to be an important step in the evolution of the platform, but it is important to recognize the many accomplishments that happened in 2019 that made this plan possible.

First, the Eclipse Foundation and Oracle successfully completed some very complex negotiations about how Java EE would be evolved under the community-led Jakarta EE process. Although the Jakarta EE community cannot evolve the specifications under the javax namespace, we were still able to fully transition the Java EE specifications to the Eclipse Foundation. That transition led to the second major accomplishment in 2019: the first release of Jakarta EE. Those two milestones were, in my view, absolutely key accomplishments. They were enabled by a number of other large efforts, such as creating the Eclipse Foundation Specification Process, significant revisions to our IP Policy, and establishing the Jakarta EE compatibility program. But ultimately, the most satisfying result of all of this effort is the fact that we have seven fully compatible Jakarta EE 8 products, with more on the way.

The Jakarta EE community was also incredibly active in 2019. Here are just a few of the highlights:

2019 was a very busy year, and it laid the foundation for a very successful 2020. I, and the entire Jakarta EE community, look forward to the exciting progress and innovation coming in 2020.

Written by Mike Milinkovich

January 16, 2020 at 12:06 pm

Close to the Edge

Today we are launching our new Edge Native Working Group to help drive the industry platform for edge computing. The new group has hit the ground running with everything needed to accelerate adoption of enterprise applications at the edge: a mature code base that’s already widely deployed in production environments, strong endorsements and participation from industry heavyweights, strong collaborations with other industry organizations such as the CNCF, and a deep understanding of the key challenges ahead.

But before turning to the details of the announcement, let’s talk a little about how edge computing differs from related technologies such as cloud and IoT.

To me, edge computing differs from IoT in that IoT is historically a bottom up approach. The people who talk about IoT are likely coming from an embedded systems or industrial automation background, and are looking for new, open stacks to connect their OT systems to modern cloud infrastructure.

Edge computing is more of a top down approach where people are looking for how they can take the new generation of cloud infrastructure and use it to solve problems at the edge of the network. Edge computing does not necessarily differ from cloud computing in terms of compute power (multiprocessor 64-bit x86 or ARM with gigabytes of RAM) or software stack (containers, Kubernetes, and microservices). The single most important differentiator between cloud compute and edge compute is simply “do you know (or care) where the resources are located”? If the answer to that is yes, then you are in the realm of edge computing. In addition, the requirement to deal with the transparent orchestration of microservices from cloud to edge is key.

Edge Accelerates Applications

Artificial intelligence (AI) and autonomous vehicle applications are two great examples of why there is massive interest in edge computing. Pushing applications out to the edge of the network is the only way to efficiently transfer and analyze the massive amounts of data AI applications rely on. And, it’s the only way to achieve the sub-one-millisecond latency autonomous vehicle applications require.

With the Edge Native Working Group, the global community can collaborate to evolve the commercial-grade, production-ready code base we already have in Eclipse ​ioFog​, Eclipse ​fog05​, and other projects to address technical issues that are specific to the edge:

  • Running applications on a wider variety of hardware than you would find in a data center
  • Dealing with the fact that at the edge, the physical location of your resources matters
  • Maintaining communications when you’re forced to rely on low-bandwidth, intermittent network connections while also scaling to scenarios that rely on 5G and other high bandwidth technologies
  • Ensuring the security of edge devices that are often installed in easily accessible locations (read the Edge Security Challenges whitepaper published by the Kubernetes IoT Edge working group)

Resolving these challenges will allow the Edge Native Working Group to bring EdgeOps — DevOps for the edge — to the world so developers can write software and can deploy, run, and manage it where it needs to, whether that’s on an MRI machine in a hospital, a motion-activated camera in a farmer’s field, or a fleet of vehicles.

The Market for Edge Computing Is Here and It’s Huge

Interest in resolving edge-specific issues is extremely high. Our founding member list is an impressive group of industry leaders, such as ADLINK, Bosch, Edgeworx, Eurotech, Kynetics, Huawei, Intel, and Siemens. We’re also actively engaged in discussions with other influential global players and expect to share news about additional working group members in the near future.

The stature and breadth of companies joining the Edge Native Working Group confirms the need for an open source industry group with edge code that’s ready to be used in serious deployments. According to a 2019 Allied Market Research report, edge computing is forecast to generate a market worth $16.5 billion within the next five years.

The business potential at the edge is as varied as the companies joining the working group. For a chip developer, the Edge Native Working Group offers access to an industry ecosystem that can showcase the speed of their products in AI and data analytics applications at the edge. A global telecom player can ensure its products are aligned with edge computing standards to enable 5G applications at the edge.

And on it goes, with the potential for companies in any industry to leverage the open platforms the Edge Native Working Group is developing to build customized edge applications for their specific markets and opportunities.

Get Closer to the Edge at the Eclipse Foundation

Critical new initiatives, such as the creation of the Edge Native Working Group, can only happen when Eclipse Foundation community members come together to drive them forward. I want to sincerely thank everyone involved in getting the Edge Native Working Group off the ground for their dedication and meaningful contributions. The tremendous interest and success we’ve experienced so far is a true testament to the value of the time and effort this very devoted team has committed to the project.

With the incredibly broad and bright future the Eclipse Edge Native Working Group offers, I encourage everyone to visit http://edgenative.eclipse.org/, review the ​charter​ and the ​Edge Native Working Group Participation Agreement (WPGA), or email us at membership@eclipse.org for more information. You can also join the working group’s mailing list to receive progress updates.

If you’ll be attending Edge Computing World on Dec 9-12 in San Jose, California, be sure to attend the Eclipse Edge Tools developer workshop on Tuesday, December 10 at 11:30 AM local time. Also, drop by and see us at our table in the main foyer on the second floor of the Computer History Museum, where we’ll be showcasing the ioFog, ​fog05​, and the Edge Native Working Group.

 

Written by Mike Milinkovich

December 10, 2019 at 7:00 am

Posted in Foundation