Dear openHAB community,
The one or the other might have read my mail on the Eclipse SmartHome (ESH) mailing list that I am retiring as a project lead of ESH.
I can imagine that this announcement will bring up many questions in the openHAB community. That’s why I would like to give you some background on this decision and share with you the plan about what this means for openHAB.
As a bit of history: Eclipse SmartHome had been initiated 5 years ago by taking the openHAB core code base and run it as a separate project. The idea behind this was to allow other (also commercial) solutions to build on this code base and especially to collaborate on it for the benefit of everyone. This worked pretty well over the years and I think many features of openHAB would not have been possible without this collaborative setup. If you have closely followed the activities at ESH in the recent months, you will have noticed though that the number of active maintainers has decreased and that the majority of contributions meanwhile originates from the openHAB community. This effectively means, that although there are commercial companies using ESH, those are rather passive users of the code, who might do a contribution here and there, but who are not actively engaging themselves in driving the project forward.
Looking at this situation from an openHAB perspective, this does not seem beneficial for us anymore. Running ESH as a separate project means a lot of effort wrt project management, infrastructure management like builds and releases, etc., which is “unproductive” overhead and time that could be spent more wisely. Being non-commercial, the openHAB community has no interest in taking on this additional effort, since ESH is mainly meant to be used for other commercial solutions. What’s even worse than the additional efforts is that the split of ESH & openHAB creates some “unnatural” boundaries, which keep people from crossing it (like not fixing bugs in ESH while being users of openHAB), just like it is a permanent source of confusion about where to discuss/report/fix things.
We should therefore use the situation as an opportunity to simplify the openHAB project organisation by reintegrating the ESH code into the openHAB project itself. The idea is to move all “core” ESH bundles to openhab-core and all ESH add-ons to openhab2-addons and continue their maintenance there. We would like to keep openhab-core in a “framework-style” similar to ESH, so that it is possibly to package it in different ways and that it is not only usable by the openHAB distro. The good news is that this will allow us to have @maggu2810 (as the only left ESH committer) join the openHAB community as a maintainer - his knowledge in OSGi and Karaf is a huge asset.
What are the next steps?
Starting today, we work on integrating the ESH code into openHAB. For this reason, we would like to ask you to NOT CREATE ANY FURTHER PRs OR ISSUES FOR ECLIPSE SMARTHOME. We will inform you here, once the code has successfully moved to openhab-core and openhab2-addons - the plan is to finish this latest by end of January. Wrt all currently open ESH PRs, we will individually discuss with the authors, how to proceed with those. The ESH issues will stay open and we can keep referencing them when working on fixes. New issues should all go to openHAB repos, though.
Some details on what needs to be done:
- openHAB repos should switch from EPLv1 to EPLv2 (which I did for openhab-core already) to be compatible with ESH code
- Code from https://github.com/eclipse/smarthome/tree/master/extensions will be merged into https://github.com/openhab/openhab2-addons/tree/master/addons, which includes a refactoring of its namespace from
org.eclipse.smarthome
toorg.openhab
. - Code from https://github.com/eclipse/smarthome/tree/master/bundles will be merged with https://github.com/openhab/openhab-core. While bundles are renamed to
org.openhab
, the core packages will be kept atorg.eclipse.smarthome
for compatibility reasons (so that existing add-ons still nicely work without any changes). The namespace of the automation component will be refactored, though, as hardly anyone depends on it (yet). - We use the opportunity and change the openhab-core build system from Tycho to pure Maven with bnd. This is more modern, brings us many additional features and is highly favoured by many community members as it is easier to get into and understand for non-OSGi developers. The openhab2-addons repo won’t be changed yet, but it is planned in the future as well.
- Instead of the ESH IDE setup, a new “openHAB Core” IDE setup (using bndtools) will be provided for developing the core code. Pure add-ons development can continue with the existing “openHAB IDE setup”.
- Instead of the Eclipse Forum, development related discussions will be done in the openHAB forum - a new “Development” category has been created today for this purpose. Please note that this is for general discussions/questions. If there are concrete bugs & issues, this should preferable directly go to the according issue tracker on Github.
- We will need to update our documentation and remove any references to ESH - any help is highly appreciated here!
The Road Ahead
Having the framework code under our control, I think it is a good moment to start planning how openHAB should evolve in future. There were many discussions in the past about the bad UX especially for newbies, with too many different UIs and options and the tricky balance between textual and GUI-driven configuration. Imho we should not make any fundamental changes to openHAB 2, but we should start talking about an openHAB 3, which can bring simplifications by reducing complexity (like retiring UIs, removing Xtext from the core, etc, tbd.) with the cost of breaking backward compatibility (while keeping a migration path for everyone).
Before going into any discussions & decisions on this, I would like to establish some more formal governance process for openHAB in general - similar to what exists at the Eclipse Foundation with the “Eclipse Development Process”, which clarifies, which people are allowed to actually take decisions and how such a process looks like. I definitely want to distribute the responsibilities, so that the project can better scale - all based on the principle of meritocracy. I’ll come up with some suggestions on such a process document soon and will keep you posted.
Summary
You see that quite some changes are lying ahead of us, but I am convinced that they will help to better evolve openHAB and serve its growing community. And please be re-assure, that although I step down as a project lead of ESH, I stay fully committed to openHAB and its community!
Stay tuned for updates on the process here.
Cheers,
Kai