Archive for the ‘Foundation’ Category
Eclipse Foundation on the move!
After 15 years at 102 Centrepointe Drive in Ottawa, the Eclipse Foundation is on the move. We will now be located at 2934 Baseline Road, Suite 202, Ottawa, ON, K2H 1B2.
Back in 2004, when we took the space current space on Centrepointe, there were only three of us on staff. Fifteen years later we have been joined by over 20 more staff in the Ottawa office, where we now occupy all three floors of our building. With this growth, we have simply outgrown our existing space.
On May 6th, we move to a new office space nearby that allows us all to be on one floor and doesn’t significantly increase travel time for anyone on our team. The decision to move to one floor was largely based on research that shows that having employees on one floor improves collaboration and offers more opportunities for interactions, thereby building relationships. Our new office also allows room for us to grow as we continue to grow. These fresh new facilities offer several benefits for our company, such as a free gym, lots of green space (think outdoor meetings where creativity can bloom), an on-site cafeteria which provides healthy food options, several in-office meeting rooms and a large boardroom where we can host our larger meetings…and have a few parties for our hard-working staff.
If you are in the area, please drop by and say hello. We would certainly welcome the opportunity to show you our amazing new digs!
The 2019 IoT Developer Survey Results are Live
After months of hard work, the 2019 IoT Developer Survey results are live today. This year marks the fifth year the Eclipse IoT Working Group has asked the global IoT developer community to share their perceptions, requirements, and priorities. The survey has proven to be an influential assessment of the IoT market as viewed from the development front lines. Access the full findings of the 2019 IoT Developer Survey here.
Over 1,700 individuals took the survey between February and March 2019. Just like in previous years (see results from 2018, 2017, and earlier here), Eclipse IoT collaborated with key IoT ecosystem players like Bosch and Red Hat to maximize the reach of the survey.
The key findings this year include the following:
- IoT drives real-world, commercial outcomes today. 65% of respondents are currently working on IoT projects professionally or will be in the next 18 months.
- IoT developers mostly use C, C++, Java, JavaScript, and Python
- AWS, Azure, and GCP are the leading IoT cloud platforms
- Top three industry focus areas remain the same as last year: IoT Platforms, Home Automation, and Industrial Automation / IIoT.
- MQTT remains the dominant IoT communication protocol leveraged by developers
- The Eclipse Desktop IDE is the leading IDE for building IoT applications
IoT gets real(er)
Consistent with our findings last year, two-thirds of the respondents to our survey develop and deploy IoT solutions today or will be doing so within 18 months. This continued focus on building and deploying real world solutions is reflected in the increases in developers’ focus on performance, connectivity, and standards shown in the survey.
C and Java dominate
C won out as the programming language of choice for constrained devices, while Java was most popular for gateways/edge nodes and IoT cloud. Neither of those findings are surprising. C and C++ have long been the languages of choice for small embedded systems where minimizing memory space and power consumption, and maximizing processor utilization are key. Java is the dominant language and platform where the memory and processing resources are larger, and the complexity of the systems are greater. In particular, Java is the language of choice for most cloud infrastructure projects, so seeing it lead in IoT cloud is consistent with that.
AWS, Azure, and Google hold on to the lead
As expected AWS, Azure, and GCP maintain their status as the leading IoT cloud platforms. The list of three and their rankings are entirely consistent with their relative weights in the cloud computing marketplace as a whole, so there is no surprise to see this reflected in our results.
A continued focus on platforms, home automation, and IIoT
IoT Platforms (34%), Home Automation (27%), and Industrial Automation / IIoT (26%) were the respondents’ three most common industry focus areas. These areas are likely to continue to be key targets for IoT developer activity. The fact that IoT Platforms is consistently year after year the number one focus for IoT developers is interesting. It implies that enterprises and industrials are putting resources into building their own IoT platforms for use by their companies. To me this suggests that industrial IoT is going to be a huge opportunity for hybrid cloud, as companies build and run IoT solutions on-premise based using modern, open technologies.
Security is (still) top of mind
Security is still the top concern for IoT developers. Communication Security (38%) Data Encryption (38%), and JSON Web Tokens (JWTs) (26%) were the top three security technologies cited in the survey, with virtualization also starting to play a stronger role in IoT Security.
MQTT is still the dominant IoT communication protocol
HTTP (49%), MQTT (42%), and Websockets (26%) were the top three communications protocols used by IoT developers. The growth in MQTT adoption over the past seven or eight years has been phenomenal, and I like to think that the Eclipse IoT community with its Eclipse Paho and Eclipse Mosquitto projects had a small part to play in that. Having robust open source implementations available has certainly been part of the MQTT’s success. Looking forward that main challenge we see for further MQTT adoption is the lack of interoperability built into the protocol. While MQTT is a great lightweight, low latency protocol it does not provide any guidance on the topic structures and payload definitions used by any device or application. This means that no two teams using MQTT would expect to have their systems be able to reliably exchange data. The Eclipse Tahu project defines the Sparkplug protocol — created by Arlen Nipper one of the co-inventors of MQTT itself. Sparkplug defines the topic structures and payload definitions necessary for out-of-the-box interoperability of SCADA systems. We are hopeful that Sparkplug could spur MQTT to even greater adoption in industrial IoT use cases.
The Eclipse Desktop IDE is the leading IoT IDE
45% of respondents use the Eclipse Desktop IDE. It is not at all surprising that the Eclipse IDE has a strong franchise with IoT developers, given the dominance of C and Java. The Eclipse CDT project has long been hugely important in the embedded software space. The past decade CDT has been used by virtually every chip, SOC, and RTOS company as the basis for their toolset. Those developer solutions also typically use additional tools such as the Target Management Framework, and Remote Systems Explorer that were specifically designed with the embedded developer in mind. That, coupled with the Eclipse IDE’s broad use amongst professional Java developers makes its leadership in IoT clear.
In addition, close to 10% also use Eclipse Che, our community’s next generation cloud-based tooling solution. It really seems part of the future of IoT is in the cloud, one way or another.
Access the full findings of the 2019 IoT Developer Survey here.
Thanks to everyone who took the time to fill out this survey, and thanks again our Eclipse IoT members for their help with the promotion.
We are very interested in hearing your thoughts and feedback about this year’s findings. And, of course, we are always open to suggestions on how to improve the survey in the future!
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.
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..
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.
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.
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).
Conclusions
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.
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.
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 license@eclipse.org 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!
Life at Eclipse 