OpenHAB: to Roadmap or not to Roadmap

Hi everyone,

I have suggested in different threads to create a poll among users about most needed improvements and features.

I have suggested creating a long term roadmap for openHAB.

I have consistently received pushback, with contributors explaining to me that this is an open source project, that the project is subject to willingness and availability of individual contributors. That there is no way to ‘force’ contributors into developing feature A and not feature B.

I’m intrigued by this… How did Linux get to where it is? Linus. How did Asterisks get to where it is? Digium. And I could go on.

My point is, OH already is a GREAT solution. It is not perfect, but it can get there with direction and a roadmap and a rallying cry to the troops out there to get on board.

IoT and Home Automation is a booming industry. So OH is in an amazing sweet spot right now. Why not appoint a ‘steering committee’ chaired by core contributors that sets out a roadmap and solicits help in implementing that roadmap? Why not go freemium? Why not pull in corporate sponsors?

I’m sure that the hardcore open source purists out there would like to lynch me for even suggesting this… But seriously, can we at least think/talk about this?

OH has a huge potential. It could become the MySQL of Home Automation. But I feel it needs a longer term vision in order to have a shot at that.

Feedback welcome, and please people, let’s try to be constructive here…

Arnold

Torvalds is Benevalent Dictator for Life. He gets final say in what does and does not get included in the kernel. He also gets paid to work on the Linux kernel and his other projects full time. In fact, most of the contributions are made by paid developers. Digium is a company who similarly pays developers to work on Asterisk full time.

openHAB has no BDL. The closest we have is Kai who has stated that he is just another contributor to the larger effort. We also do not have, as far as I’m aware, any company paying for openHAB or ESH developers to contribute to OH.

So, projects like these have much more leverage over dictating what does and does not get worked on because they can pay a team to develop specific things.

I’ve said it on other threads before. Want to decimate to group of developers who are willing to donate their time to work on your project? Tell them they can’t work on something they care about because it doesn’t fit in with the roadmap.

Another project with a company backing it with a team of paid developers.

I beleive the longer term vision is as follows (I could be wrong so don’t take this a gospel).

  1. Migrate the core of OH to the Eclipse Smarthome Project and place this effort under the umbrella of the Eclipse Foundation. This gives assurances that all the submitted code to the project will not be encombered by IP issues (e.g. a mix of not necessarily compatible licenses) to any companies who may want to build on the platform. All contributions to ESH must be signed off by the developers making the submission assigning ownership of the code to the Eclipse Foundation under the Eclipse License. This has been done.

  2. Maintain openHAB as the reference implementation of ESH. OH is the “see, look what ESH can be.” OH is also where some of the cutting edge capabilities reside.

  3. Support any companies who may want to build a home automation system with ESH. Here is where one starts to get those paid developers with company backing to start work on those parts of ESH that may not be as interesting to those developers who are donating their time.

That is the purpose of splitting OH into separate ESH and OH projects.

Because none of the leaders on this project has any interest in setting up a company.

If you or and a group of people have interest in doing so, I see nothing stopping you and ESH is well set up to support you. You could probably even start with OH itself though I don’t know the licensing issues with it right now, particularly with the add-ons. And then you would have the power to establish a roadmap and pay a team of developers to work on those parts that are not as attractive to those developers who donate their time.

But for the time being, attempting to enforce what can and can not be worked on to follow some roadmap dictated from on high will strongly discourage developers from contributing to the project. I see nothing good coming from it. Once you don’t have leverage to tell the developers what to work on a roadmap doesn’t provide much value. It becomes asperational at best, a joke at worse.

3 Likes

It has.

We have a similar situation for ESH. The majority of commits are done by the ESH team of Deutsche Telekom, that’s why there is also a “ToDo” list: Backlog · GitHub

Very good point! But: It’s not only the “leaders” (maintainers), it’s also the community. I definitely think the openHAB/ESH development needs more corporate AND (paid) non-profit support. Otherwise, it’s likely that it’ll be outworn by other open source solutions who do have more paid core committers and maintainers. The development pace is currently quite slow and this is, beside of openHAB’s steep learning curve, one of the major reasons why recent media coverage tends to recommend Home Assistant in favor of openHAB.

@ACobb: If you want a faster development and also influence in what is developed, you have these possibilities:

  • Develop things on your own (and the roadmap will be whatever you and others plan to develop on, that’s the status quo :wink: )
  • Bounty Program
  • Found a company and invest development resources into openHAB / ESH
  • Found a non-profit that supports the development or convince the members of the openHAB Foundation that the foundation should do so (currently, the foundation does not directly support the openHAB development)

I think without more full-time developers working on the project, a roadmap that contains any timeline won’t make sense.

OK, so that covers the openHAB 2.x add-ons. What about the openHAB 1.x addons, openHAB distro, Eclipse Smarthome, openHABian, VSCode openHAB extension, Android App, iOS App, Docker image? Kai has explicetly stated, when it comes to ESH, he is NOT BDFL. And ESH is the core of OH. I cant find the postings right now but I know he has said this twice on this forum.

We have a bounty program. Introducing BountySource for funded development

It hasn’t gotten much traction.