Life at Eclipse

Musings on the Eclipse Foundation, the community and the ecosystem

Archive for the ‘Open Source’ Category

IoT and Edge Developers: Let Your Voices Be Heard

Today, the Eclipse IoT and Edge Native Working Groups have launched the 2021 IoT and Edge Developer Survey. This is the seventh year for our annual survey, which has become one of the most widely referenced technical surveys within the IoT & Edge computing industry.

This year’s survey expands on previous editions to be more inclusive of trends in edge computing technologies. Our goal is to present a better understanding of the challenges developers face within both sectors, and to provide insights into the technical issues faced by their respective developer communities around the world. 

We welcome your participation. Your input will help IoT and edge ecosystem stakeholders with the data to align their strategies with latest trends and apply investments where needed most. Start the survey now.

You Can Influence Industry Direction

Developers, service providers, technology manufacturers, and  adopters within the IoT & edge ecosystem can all influence industry direction through survey participation. Last year’s survey received more than 1,600 responses, with the results being shared by more than 20 media outlets.

The 2020 IoT Developer Survey results revealed that IoT and edge application development is increasing at a rapid pace, fueled by growth in investments into predominantly industrial markets. It also indicated  that smart agriculture, industrial automation, and automotive are key target industries for application development.

Our expectation for the 2021 survey is that it will offer even more visibility around IoT & edge development trends, and what those trends mean to stakeholders. The survey results will also be used to help the Eclipse IoT and Edge Native Working Groups with their open source roadmaps as they work to address the evolving needs for IoT and edge development tools, architectures, deployment technologies, security, connectivity, and other requirements along the edge-to-cloud continuum.

The Developer Survey Complements the Commercial Adoption Survey

The results of the IoT and Edge Developer Survey will help complete the picture painted by our recent 2021 IoT and Edge Commercial Adoption Survey. That survey found that IoT and edge computing technologies are being adopted at an accelerated rate by a growing number of organizations. The results also revealed that 74 percent of organizations factor open source into their deployment plans, a 14 percent increase over the 2019 IoT Commercial Adoption Survey results.

With a deeper understanding of the unique challenges faced by IoT and edge developers and the latest commercial adoption trends, the entire ecosystem is better informed and better able to meet the growing demand for IoT and edge solutions.

Complete the IoT and Edge Developer Survey by October 5

The 2021 IoT and Edge Developer Survey is open through October 5. Please take a few minutes to complete the survey now, while it’s top of mind.

As usual, the survey report will be published under the Creative Commons Attribution 4.0 International License (CC BY 4.0), which means that the entire IoT and edge ecosystem can benefit from the insights it provides. Stay tuned for additional blog posts and promotional activities once the report is available.

Written by Mike Milinkovich

August 26, 2021 at 8:05 am

Posted in Foundation, Open Source

Shaping the Future of the Eclipse IDE

I’m very pleased to share the news that multiple Eclipse Foundation members have joined forces in a new working group focused on advancing and sustaining the Eclipse IDE used by millions of developers the world over. The Eclipse IDE Working Group members will leverage our governance framework to openly collaborate and ensure the Eclipse IDE software suite continues to meet developers’ needs for high quality tools.

To achieve this goal, the working group members — which currently includes Bosch, EclipseSource, IBM, Kichwa Coders, Renesas, SAP, VMware, and Yatta Solutions — will provide governance, guidance, and funding to the communities that deliver and maintain the Eclipse IDE software components. They will also oversee the related planning, delivery processes, and delivery technologies for the software suite. The projects that make up the Eclipse IDE such as Platform, JDT, and CDT are already wonderfully active, diverse, and vibrant. The working group will further support and strengthen their contributions by providing additional resources.

This is great news for everyone who already relies on the Eclipse Platform, desktop IDE, and underlying technologies as well as those who are thinking about adopting the software. With the focus and open collaboration the working group structure enables, everyone can rest assured there is a strong, shared vision for the future of the IDE and its related components. The software will remain relevant, sustainable, and high quality as it evolves.

In the 20 years since the Eclipse IDE was first released, it has become one of the world’s most popular and prolific desktop development environments. With tens of millions of downloads and billions of dollars in shared investment, the Eclipse IDE is a critical platform for millions of developers globally, so it’s very important that it remains vital.

Check Out the Latest Eclipse IDE Release

We timed the announcement of the Eclipse IDE Working Group to coincide with the latest quarterly Eclipse IDE simultaneous release to highlight how robust this community is. The Eclipse IDE 2021-06 release is the result of a huge collaborative effort from our dedicated community that encompasses:

·      More than 70 participating projects

·      110 committers

·      174 contributors

·      Almost 80 million lines of code

Congratulations to all of the committers, projects, and Foundation staff involved! 

I encourage everyone to check out this latest Eclipse IDE release. It provides a number of new features that will help you develop modern, world-class applications, including:

·      Java 16 support

·      Improved Eclipse Java development tools (JDT) capabilities such as new cleanups and enhanced debug capabilities

·      Mac AArch64 (Arm64) support for Apple M1-based systems

·      Improved embedded terminal support, including the ability to open files and links with Ctrl+Click, and remembering working directory, shell, and other settings

For more information and the links to download the software, visit the Eclipse IDE 2021-06 release page.

Get Involved in the Eclipse IDE Working Group

If the Eclipse IDE is important to your organization’s development efforts, joining the working group is a great way to help support and shape the evolution of a resource your teams rely on.

To learn more about how to get involved with the Eclipse IDE Working Group, visit the Eclipse IDE Working Group website, or see the working group’s Charter and Participation Agreement. Working group members benefit from a broad range of services, including exclusive access to detailed industry research findings, marketing assistance, and expert open source governance.We also welcome companies that want to support the Eclipse IDE without joining the working group. To learn more about sponsoring the Eclipse IDE, please see the working group’s Sponsorship Agreement. Individuals can also donate to the Eclipse IDE.

Written by Mike Milinkovich

June 17, 2021 at 8:03 am

Posted in Foundation, Open Source

How Real Is IoT & Edge Commercial Adoption in 2021?

Our 2021 IoT and Edge Commercial Adoption survey results are out now. 

In this second edition of the survey, we wanted to gain a better understanding of the overall IoT & edge ecosystem challenges and concerns of today’s organizations. This year’s survey not only focuses on how today’s organizations are perceiving IoT and edge adoption on a macro level, but also to gain valuable insights on the overall IoT & Edge ecosystem’s challenges and concerns. We found — as organizations adapt to market changes and a world impacted by COVID-19 — that IoT and edge adoption has risen. 

Here are some of the key findings from the survey:

  • IoT technologies are being adopted at an accelerated rate. 47% of respondents currently deploy IoT solutions and an additional 39% plan to deploy within the next 12 to 24 months.
  • Edge computing adoption is also picking up. 54% of organizations are either utilizing or planning to utilize edge computing technologies within 12 months. Another 30% have plans to evaluate edge deployments over the next 12 to 24 months.
  • 74% of organizations factor open source into their deployment plans, a 14% increase over the  2019 survey. This clearly demonstrates that the dominant IoT & Edge platforms will either be open source or based on open source.
  • The top 3 IoT and edge operational challenges are: 1) End-to-end IoT solution monitoring and management; 2) Device management; and 3) Securing the network / devices / data.
  • There is a trend towards a Hybrid Cloud strategy. 44% of respondents suggest that their IoT deployments are using, or will use, a Hybrid Cloud (i.e. composed of two or more distinct cloud infrastructures such as private and public), an increase from 22% in 2019.

Reading Between The Commercial Lines

The survey asked respondents to identify the requirements, priorities, and challenges they’re facing as they are planning, implementing, and managing commercial IoT and edge solutions, including those based on open source technologies. The survey ran for two months in early 2021 and received responses from more than 300 individuals from a wide range of industries and organizations. You can download the 2021 IoT & Edge Commercial Adoption Survey Report now.

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

  • Enterprises:
    • Should select vendors and service providers that embrace open standards and the use of customizable, production-ready open source building blocks. Open source enables scalability and flexibility in IoT and Edge solutions, while avoiding the lock-in and cost issues associated with proprietary solutions.
    • Should start planning deployments of IoT and edge technologies at scale. The ecosystem has matured significantly, allowing enterprises to be more ambitious in their IoT and Edge initiatives. With a robust ecosystem, industry leaders can confidently deploy and start realizing the full benefits of the technology.
  • Solution Providers:
    • Should incorporate open source platforms that are capable of running seamlessly across all environments (i.e. at the edge, on-premises, and in the cloud), with a focus around hybrid, multi-cloud and private cloud offerings that enable customers to avoid using a public cloud for their mission-critical data.
    • IoT-focused solution providers should add edge computing into their offerings. Enterprises are increasingly becoming aware of the benefits of edge computing, including reduced latency and bandwidth savings. To stay competitive,  solution providers need an edge computing strategy if they do not have one already.
  • Platform & Software Vendors:
    • Should implement data security and sovereignty solutions across devices and applications. Organizations must pay particular attention to their ability to retain control over data flow and storage, e.g. for data gathered from IoT sensors and devices.
    • Should create offerings that optimize certain workflows and/or mitigate specific challenges.  While Enterprises and Solution Providers are adept at integrating and deploying the various components, broadscale adoption will be accelerated through targeted platform innovations that simplify critical processes and resolve deployment challenges out of the box. 

Be Part Of Something Big

It will take a diverse community co-developing a uniform set of building blocks based on open source and open standards to drive the broad industry adoption of IoT and edge technologies. If you’re interested in participating in the industry-scale collaboration in open source IoT and edge technologies, please visit Eclipse IoT and the Edge Native Working Group to get involved. As an added benefit of membership, Eclipse IoT and Edge Native members receive early and exclusive access to detailed industry research findings and expert guidance.

Written by Mike Milinkovich

June 10, 2021 at 9:01 am

Posted in Foundation, Open Source

Tagged with ,

On Patents and Specifications

We’ve been fielding a number of questions lately about the intersection of our spec process and patents. A couple of these community discussions have gone off in directions that are off target, factually incorrect, or both. Therefore, the purpose of this short FAQ is to explain the patent license options provided by the Eclipse Foundation Intellectual Property Policy for use by specifications developed by specification projects under the Eclipse Foundation Specification Process (EFSP). 

Disclaimer: This is not legal advice. I am not a lawyer. It has not been reviewed by counsel. Consult your own attorney. In addition, this note does not form part of any official Eclipse Foundation policy or process, but rather is provided for informational purposes only to aid those involved in our specification projects to better understand the EFSP and the choices available. I’ll update the content as needed.

One important point to keep in mind when reading this: we believe that the EFSP fully complies with the Open Standards Requirement for Software established by the Open Source Initiative. In other words, the EFSP is designed specifically to be open source friendly.  

Why do specifications require patent licenses?

The purpose of every specification is to stimulate the development of implementations. These implementations may be derived from open source code maintained at the Eclipse Foundation or elsewhere, or they may be independently developed. They may be made available under open source licenses or proprietary. In order to facilitate and encourage these implementations, all specification processes provide some notion of patent licenses from the parties involved in developing the specifications.

What types of patent licenses are used by various specification organizations?

There are a wide variety of specification patent license options available from various sources. 

Some terms that you may hear are:

  • FRAND means fair, reasonable, and non-discriminatory licenses. This means that before you can implement the specification you are required to obtain a license from the patent holders who developed the specification. FRAND is generally considered to be antithetical to open source development, as it requires permission and money to implement a specification or potentially even to use an implementation of such a specification.
  • FRAND-Z is FRAND where the cost of the license is set to zero. Note that although this removes the cost concerns of FRAND, permission may still be required for use and/or implementation. 
  • RF or royalty-free provides a priori royalty-free licenses from the participants developing the specifications to downstream users and implementers. This is considered a best practice for enabling open source implementations of a specification. All Eclipse Foundation specifications are developed on a royalty-free basis. 
  • Non-assert is another legal mechanism which provides a result effectively similar to royalty-free. A non-assert says that a patent holder will not assert their patent rights against an implementer or user. 

Do these licenses mean that an implementer or user can never be sued for patent infringement?

No. The patent licenses are intended to ensure that an implementer or user doesn’t need to be worried about being sued by the parties involved in developing the specifications. It does not provide protection from uninvolved third parties who may believe they have intellectual property rights applicable to the specification. 

Note that the above implies that it is in the interests of the entire community and ecosystem that many participants (particularly patent-owning participants) be involved in developing the specifications. It also explains why it is in the best interest of the community that all participants in the specification process have signed agreements in place documenting their commitment to the patent licensing under the EFSP. 

What patent licenses are granted by the EFSP?

The patent licenses provided via the EFSP apply to all downstream implementations of Final Specifications, including independent implementations. They cover all patents owned by each Participant in the specification project that are essential claims needed by any implementer or user of the specification. Note that the licenses cover the entire specification, not just to the parts of the specification that a participant may have contributed to. We provide our specifications two options for patent licenses: the Compatible Patent License and the Implementation Patent License. The differences between those two are explained below.

But my open source license already has a patent license in it. Why do I need more than that?

The patent licenses provided in open source licenses such as APACHE-2.0 grant a license for contributor-owned patents which apply to their contribution either alone or as combined with the work. The patent license is only to that program/implementation. Note that the APACHE-2.0 patent license  “…applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work…”. Relative to the EFSP, such grants are deficient in both scope (applies only to their contributions) and target (applies only to that implementation). 

What is the difference between the two patent license options provided by the EFSP?

The only difference between the Compatible Patent License and and the Implementation Patent License is the timing of when the patent license grant comes into effect. In the Compatible Patent License, the license grant only happens when the implementation has demonstrated that it is fully compatible with the specification by passing the relevant TCK. The Implementation Patent License provides immediate patent licenses to all implementers, even to partial or work-in-progress implementations. The first choice emphasizes the importance of compatibility. The latter choice emphasizes the importance of open development. Both are valuable options available to Eclipse specification projects. 

Is one of these patent license options better than the other?

No. There are perfectly valid reasons why a specification project may choose either one of these options. Both options provide downstream implementers of the specifications royalty-free licensing to the patents of the participants who developed the specification. The Implementation Patent License favours open development as there is less concern that a work-in-progress implementation does not have access to the patent licenses. Where there is a strong emphasis on desiring compatibility across all implementations, the Compatibility Patent License is a valid choice. Another scenario is a small company with few patents. They may also prefer the Compatibility Patent License to ensure that they’re not providing an open-ended patent license to any competitors who may only partially implement the spec. 

Does the Eclipse Foundation recommend either of these two choices?

As an open source foundation our default preference is the Implementation Patent License as we always want to promote open collaborative development. But as described above, there are perfectly valid reasons why a specification project may prefer the Compatibile Patent License. Ultimately it is up to each working group to make their own selection.

I’ve read the EFSP and I don’t see anything about patent licenses. WUWT?

The patent licenses are provided in the Eclipse Foundation Intellectual Property Policy. A future version of the EFSP will make this clearer.

Is the Eclipse Foundation itself granted any licenses to patents? 

No. The Eclipse Foundation itself does not acquire any patent rights in the specifications. The patent licenses are granted from the participating patent owners directly to implementers and users of those specifications. More specifically, the patent license grants are “… to everyone to make, have made, use, sell, offer to sell, and import…” implementations of the specifications.

(Updated on 2021-07-05 to add two FAQ entries.)

Written by Mike Milinkovich

May 13, 2021 at 3:20 pm

Open VSX: A Vendor-Neutral Home for VS Code Extensions

With the transition of the Open VSX Registry from TypeFox to the Eclipse Foundation, the industry now has a vendor-neutral and publicly hosted open source alternative to the Microsoft Visual Studio Marketplace for VS Code extensions. The move increases transparency and flexibility for extension users, extension publishers, and tool developers.

Overcoming Single-Vendor Marketplace Restrictions

While the Microsoft Visual Studio Marketplace is a great resource for developers that use Microsoft VS products, its terms of use states that extensions can’t be used with the increasing number of open source tools and technologies that support the VS Code extension API.

In addition, because Microsoft doesn’t provide access to the source code for the Visual Studio Marketplace, there’s no opportunity to contribute new features and enhancements, or to reuse the source code to create an internal extension registry for in-house developers.

The Open VSX Registry is built on the Eclipse Open VSX project. It’s visually and functionally similar to the Microsoft VS Marketplace, but the extensions can be used with any editor that supports VS Code extensions — from VS Code and forks of VS Code like VSCodium, to Eclipse Theia, Eclipse Che, Gitpod, Coder, and SAP Business Application Studio.

The Eclipse Open VSX source code is open to all, so anyone can reuse and enhance the marketplace technology to meet their specific needs. They can even create an internal, private extension repository that’s connected to the upstream public Open VSX Registry.

Providing a Level Playing Field for All

Following a true open source model, all aspects of the Open VSX Registry are guided by the community based on our proven governance framework and processes for entrepreneurial collaboration. These vendor-neutral processes bring important benefits. For example:

  • No single company or vendor owns the Open VSX Registry servers, operates the service, or has more control over the service than any other participant.
  • Any individual or organization can influence how the Open VSX Registry evolves by participating in design discussions and contributing code to the Eclipse Open VSX project.
  • There’s a public record of all extension ownership claims by extension publishers to avoid conflicts over ownership.  

Driving Open VSX Registry Innovation and Collaboration

The Eclipse Cloud DevTools (ECD Tools) Working Group will manage the Open VSX Registry, driving further platform growth and marketplace adoption. With members that include Broadcom, EclipseSource, Ericsson, IBM, Intel, Red Hat, SAP, and Typefox among others, the ECD Tools ecosystem is very well positioned to support and advance the Open VSX Registry over the long term.

I want to thank all of the ECD Tools ecosystem members and Eclipse Foundation staff who worked so tirelessly to enable the smooth transition of the Open VSX Registry to the Eclipse Foundation. And a special word of appreciation to the TypeFox team who built and nurtured the Open VSX Registry from the ground up. Your contribution reflects the true spirit and values of open source communities and will benefit all.

Read the Open VSX Registry White Paper and Get Involved

To help everyone with an interest in the Open VSX Registry fully understand its benefits and potential, the ECD Tools Working Group has created a free white paper you can download here.

I also encourage you to:

Written by Mike Milinkovich

March 30, 2021 at 7:33 am

Posted in Foundation, Open Source