The Road Ahead - Reintegrating ESH

Announcements
,
1

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 to org.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 at org.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

72 Likes
2

Sounds like a sensible approach and direction!

Thanks for the effort that everyone puts into this project!

(I was dreading I would have to manage both Brexit and no more openHAB at the same time!)

2 Likes
3

@Kai while I understand motivations and reasons of such a move I would like to raise a question on what to do with commercial deployments?

As you mentioned ESH was meant to give a space for companies who use framework to share development cost. It didn’t happen at scale which would let project survive after major player decided to step back. That’s why we now have a move to OpenHab.

Since companies should avoid mentioning of OpenHab to do not confuse their users, what can they say now, after a switch? On which framework their product is based upon? At this moment OpenHab is solution based on ESH and its about to become a framework again.

From development point of view I also see a dangerous situation that ESH which been used in OpenHab (not vice versa) will now get forked by companies leading to further fragmentation of community and slow down of project development.

Amount of governance and processes involved in managing such big project can not be underestimated and might be too much for small entity such openHAB Foundation e.V. Are you sure you want to go this way? Wouldn’t it be better to stick with bigger foundation or grow first e.V. in order to not fail during transition?

Kind regards,
Łukasz

4

@splatch As mentioned above: We want to continue keeping openhab-core as a framework, so other adopters will still be able to use this as a basis and it won’t be tied to the openHAB distribution. From the wording, those would then be “based on the openHAB Core Framework”. But effectively, most companies anyhow do not do any mention, so there isn’t really much change.

Regarding governance: As no company is willing to actively participate, the openHAB community is anyhow already maintaining this code - so moving it will make a lot of things much simpler. And note that openHAB has more than 30 different repos/components by now and all of them require some clear process/governance, so this is anyhow something we have to deal with - and now is a good moment for it.

6 Likes
5

Please make textual configuration the default way to configurate things! There are so many restraints using gui based configuration and as someone who has to maintain multiple instances this only creates problems.
A nice compromise would be a configuration format which is human and machine readable (e.g. yaml).
The configuration gui could then just create/modify those files. More advanced users can create files directly while newbies could use the gui to create the files.

13 Likes
6

Let us not discuss such things here.

3 Likes
7

Where´s a good place to discuss this topic or things like changes of the oH startup process in oH3?

8

There are plenty of discussions in the forum around those topics already. What is missing is a way to come to decisions that’s why I was saying above:

Before going into any discussions & decisions on this, I would like to establish some more formal governance

So please be patient for a few more days. The right place will then probably be https://community.openhab.org/c/development/architecture.

3 Likes
9

See Next generation design : Ideas & Discussions for a discussion on this that has already taken place.

The startup process has at least one open issue on ESH’s Github which will presumably be moved to OH during this transfer process.

:+1 This. Yes. We come up with great ideas but there is no one to say “yes, do that”. I look forward to seeing what the governance mechanism looks like and what the flow would be from discussions like the one I linked to above would go from discussion on the forum to issue on github to implementation to release (particularly this last part).

As someone who has self dubbed himself the non-technical user advocate, I’d like to be kept in the loop on this. I’ll definitely be watching the architecture topic area.

I think this will be painful in the short term but put OH in a better place for the long term. I look forward to what the future brings! Thanks for the announcement!

9 Likes
10

Yes, an exciting announcement indeed. Thank you for the update on openHAB’s future. Happy to pitch in on removing the references from the documentation.

3 Likes
11

Hello @Kai

thanks for the update. Somehow it is a pitty and in the other hand there is a big chance to make things simpler.
You can fully count on me, as maintainer and also on home-iX with our support in this hard time and path. We need to make sure to keep the Framework approach for companies using OH-core than. On the other hand I agree, we must louder communicate and spread the word. A good thing is, that I assume that most commercial usage will than need to mention OH and not ESH anymore. At least on our side we will start to communicate this, when we really have this situation.

I see much potential in it and we remain strong.

Lets make the best out of it!

BR Mehmet

5 Likes
12

Hi,
what about the Eclipse Marketplace?
Will it be removed from OH2 ?
BR massi

13

Good question. Yes at some point it will as the future of the Eclipse Market place itself with regards to Smart Home is not clear. If Eclipse Smart Home would discontinue it would not add any value to have the Market Place for the eclipse organisation. Since it’s a (under)valued way to get new (beta) bindings to users I would expect there will be a replacement in openHAB.

14

Yes, the Marketplace will stay available for openHAB 2.x, but for openHAB 3 we will come up with a replacement for it.

1 Like
15

Short progress update:

7 Likes
16

Please also add documentation regarding migration path from ESH to Openhab-core ?

We were using https://github.com/maggu2810/smarthome-packaging-sample-karaf for building ESH solution now do we get a new Openhab-core packaging solution.

We feel it is a good move to bring ESH under OH roof and now communication will be much smoother and clear.

Thanks.

1 Like
17

Great thanks - best directly liaise with @Confectrician on Migration due to ESH reintegration.

2 Likes
18

@Kai: Thanks for your work as a ESH-Project Lead!

Anyway - I guess in 5 years tons of homes will be connected and smart. Please let us take care that companies can use openhab or an openhab-based system as the core of their maybe commercial system! Will that be still possible if ESH is getting stopped?

1 Like
19

@Kai: I have just read your post to the ESH mailing list. Did you receive any feedback from the ESH community?

20

@Kai: can you please clarify and reassure us that you will continue being involved in openHAB as much as before and that you only give up with ESH ? At least, that is what I hope…