Looking inside open source innovation

James Kirkland is one of the architects involved in the new open source Kapua project on Eclipse.org. In this blog post he discusses how innovation happens when industry leaders collaborate to make their customers successful.

Over the years, I’ve seen the beginning of a lot of open source projects, but the thing that excites me about the new Kapua project is that until now Eclipse IoT has been a set of individual projects that didn’t interrelate or even interoperate. (Read the Eclipse Foundation’s press release.)Kapua is the first attempt to create an ecosystem of projects that come together to provide functionality that is exponentially greater because of that integration. It’s an example of the sum being greater than the individual parts. The contributors came into this collaboration with the clear intention of solving broader IoT challenges in a unified way rather than each re-inventing the wheel on their own.

The higher goal of this project was to come up with a working IoT platform that would be able to meet the challenges of enterprise IoT. Previously you could take some of the Eclipse IoT projects and put them together with a lot of effort and additional coding to build out an IoT platform. This first release of Kapua code delivers a minimalistic IoT cloud-based management platform for managing IoT devices. This first step was to ensure that you could set it the device management platform, get it working and test it out. The Kura project used the same approach, of quickly getting to the first code release and to something that could be installed on a Raspberry Pi so that developers could easily get to a proof of concept stage for their own IoT gateway projects.

The functional goal was to use Kapua as the integration point for all the services under the Eclipse IoT banner. And to do it in such a way that the solution was not monolithic–that services could be plugged in and out according the needs of a given use case or the technology preferences of the developer.

To jumpstart the project, the companies involved contributed code they had developed within their own walls and proven out with their customers IoT deployments. Whenever you take a project and set it free you always run the risk of someone running with it and pushing it into the direction they prefer. We all had to build trust by doing small things together at first, like integrating just two projects, Camel and Kura. We became comfortable with each other’s work styles and that we were all going to live up to our commitment to collaborating. Then everyone does contribute within their individual areas of expertise. Even if the contribution is not code, but QA or test cases or documentation, it’s still expertise that an individual company might not have access to. Once you do that you’re able to build something bigger than any one company could build on their own–or even two companies.

Visit the Kapua project page and start participating.


Join the Red Hat Developer Program (it’s free) and get access to related cheat sheets, books, and product downloads.

Share