Mr. Kreuzer, you gained your initial experience with home automation when you were young. How did you go about it?
I was interested in computers from an early age. My first was a Commodore VC 20, followed by a C64. I burned my own EPROMs for it, plugged devices into the parallel port and fixed small contacts to the door of my room. When the door was opened, music was played automatically.
Where did you go from there?
I mounted my first touch screen on the living room wall in 2000. It consisted of a 15-inch monitor and an an industrial touch panel. The uses to which I put it included media control.
A few years later I and my family were looking for a house. My preference was for a newbuild because I wanted to install as many cables as possible. In an existing building the cabling would have been much more difficult. Before the construction work began I looked into what was available in the area of home automation. We then used the KNX system. Amongst other features it made all shutters, lighting and heating switchable. What we lacked was a good control device. In those days it was usually a monitor firmly attached to the wall. But the monitors available at the time were very expensive. Two thousand euros each was pretty well standard. Apple launched an optimal and relatively low-cost control device, the iPod Touch, in 2007. What I needed was the right control software for it.
And it had to be open source?
I didn’t want a commercial solution because I couldn’t be sure that support would be available for the system for the next 20 to 30 years. What was more, it was not yet clear which provider would go on to integrate features that I felt to be important. So open source was the best solution.
Are there other reasons why the Smart Home or the Internet of Things harmonize well with open source?
Many manufacturers simply lack the market clout and size to take on the top dogs – Google with Nest and Apple with HomeKit – and establish a proprietary system in the market. Many alliances have been set up to try and challenge the top dogs, but they often have a strong business-driven and therefore a political focus. AllSeen and OIC, for example, have positioned themselves as separate camps even though both of them are effectively pursuing the same objective. So an open source project that is managed by a neutral organization is a very sensible alternative.
You said that you needed the right control software in 2007. Did you find it?
Yes. In the home automation sector, for example, there was MisterHouse, a Perl-based project. It could already do quite a lot and even had a Web UI for the iPhone. I used it for the control software that ran on my iPod Touch. To begin with, I really liked MisterHouse and its functionalities, but after six months the problems came to light. The huge Perl scripts could not be kept clean in the long term because, for instance, there were no good developer tools for debugging it. There was also nobody to keep the project together. There were many different forks with different further functional developments, but they were not merged and brought together again.
I then tested another project with OpenRemote. There too I was strongly involved and led architectural discussions. But the project would have had to be rebuilt from scratch to implement the modular architecture I had in mind. So in 2010 I decided to launch an open source project of my own, openHAB.
And that was where you then implemented your modular architecture?
Yes. I relied from the outset on OSGi, or modularization for Java applications, because with OSGi you can create clean interfaces via which developers can simply expand the system. openHAB developers can largely circumvent problems such as overlapping classes or merging code.
Does that mean the developers involved work mainly on individual modules?
Exactly. By and large, most active developers have their own area – usually links to another system, or bindings, but there are graduations. There is a core of around ten to 20 people who take part almost daily on the mailing list and answer queries submitted by others. Then there are developers who wrote a part of the initial code but then no longer had enough spare time and no longer do very much. Others use the system and hit on a bug that they analyze and suggest fixes or even supply a bug fix themselves.
How are decisions made within the community? Does the group deliberate or do individuals tend to take matters forward?
Core decisions are now made at Eclipse SmartHome because we transferred the core framework of openHAB to the Eclipse Foundation last year. It is a non-profit organization with well-defined processes for holding discussions and making decisions. A fundamental aspect is that all discussions must be conducted in public. New ideas and proposals may not really be rejected unless there are good reasons for doing so, such as because they would interrupt downward compatibility.
You realized with your project that there was a demand for the right home automation software. Why did you not set up a company of your own?
I first wanted to solve my own problems rather than develop a product, and commercial solutions were already available. I personally benefited from the form of an open source project. It was clear at an early stage that the project would go on to become so large that I would not have had the time to implement everything myself. And I would also be able to make use of developments by other developers.
Furthermore, I had always felt that the concept of open source software was very attractive. When you collaborate, it takes the world further forward than if many proprietary mushrooms spring up that then each try to do their own thing.
In addition to your role in openHAB you are a project manager for the Eclipse SmartHome projects and take the QIVICON platform forward at Telekom. How are these projects related?
The Eclipse SmartHome project was launched last year on the basis of the openHAB core framework. As a neutral organization the Eclipse Foundation is a good place for establishing common interfaces for extensions, for example.
At QIVICON it was realized that openHAB has many active developers who contribute and develop good ideas. Now that QIVICON is also based on Eclipse SmartHome, QIVICON has gained access to this large developer community. Many extensions implemented for openHAB 2.0 can in future be ported to QIVICON at no great effort or expense, and QIVICON’s variety will increase considerably as a result. Conversely, the developer benefits from being able to cover with a single implementation all platforms that are based on Eclipse SmartHome.
Who are openHAB and QIVICON intended to reach?
openHAB is aimed at technically experienced users who, for example, can set up a Raspberry Pi of their own and install the operating system, Java and, finally, openHAB on it. QIVICON in contrast addresses the mass market, meaning people who buy an all-inclusive package and expect it to function by plug and play.
Is this liaison between an open source community and commercial enterprises a viable model?
Many companies are marketing a simple version as an open source variant and a more comprehensive one as a commercial variant. Others provide the open source software and earn money by, for example, providing commercial support. The Eclipse Foundation’s general objective is to enable companies to collaborate in open source projects to which all concerned can then add proprietary extensions for their own purposes. In addition to Eclipse-IDE, the best-known example, that works very well in automotive or aviation industry projects. So Eclipse SmartHome is continuing to write a success story.
In connection with Heartbleed there has been much public discussion about the security of open source projects. How is openHAB dealing with it?
In much the same way as other well managed projects do. We have mandatory code reviews. In other words, every contribution is reviewed and commented on by another member of the team. That relates not only to possible vulnerabilities but also to abiding by syntax and architectural standards. Nevertheless, software can still contain bugs that can serve as a potential loophole or back door. That can never be ruled out entirely.
In the final analysis, however, that is a general software problem and is not limited to open source. Bugs like Heartbleed are just as feasible in closed, commercial solutions. It is just that vulnerabilities are harder to identify, if at all, in the latter – not to mention intentional back doors. So open source’s transparency is a definite added value where security is concerned.