Although a relative newcomer to OpenHAB (5 months) I have invested hundreds of hours and thousands of dollars in my OpenHAB installation. As a result, I am reading this thread as a stake holder with great interest and at times great concern. Having professionally managed a software development group in a past life I understand the difficulties of maintaining legacy code, even when it is critical to the enterprise. Being a user community of volunteers only further complicates matters. It is in no one’s interest to have only one, or even a few, people who understand and can maintain the code. When these few individuals have other priorities, progress on OpenHAB slows. This is to be expected as we all have lives away from OpenHAB.
From what I have read, not every post in this thread but more than 50%, it is a done deal that the 1.x compatibility layer will not be maintained going forward unless a new Maintainer steps forward, which is unlikely. Therefore, the question before the community is how do we move forward without totally stranding early adopters who are heavily invested and still using 1.x bindings. And let’s not forget as early adopters they helped to grow OpenHAB to what it is today.
If I may be so bold as relative new comer, allow me provide a somewhat different perspective of OpenHAB and what has attracted me to adopt and invest in this platform. For many this a hobby, but for others like me, our OpenHAB installation is an appliance just like a refrigerator or microwave oven. It runs my house. Just because Samsung or Bosch introduces a new model appliance with wiz-bang features doesn’t mean I have to run out tomorrow and buy it, especially if my current appliance remains functional for my needs. Likewise if I don’t need the new features of OpenHAB 3.0, no one is forcing me to change. As long as 2.x remains an available option I may be content to stay where I am. If I decide to get a new piece of hardware that is not supported in 2.x, then that is my choice and I will be faced with decision as to how best to move forward. Given my current investment in time and money, this will be critical juncture as to whether to stay with OpenHAB or move to another platform. To be brutally honest, if I wanted a bleeding edge, YAML/python based, unstable platform on which to build my implementation I would have chosen Home Assistant, not OpenHAB. I chose OpenHAB because it is a stable platform that has evolved steadily, but carefully, over years of development and that I can trust in my home, uses broadly accepted and used programming languages such as JavaScript, has a terrific and broadly based user community, and while the initial learning curve was steep it was manageable. It is hard for me to imagine anyone in the foreseeable future without a technical grounding being able to use any Open Source Solution to develop a true automation system. This is why the commercial systems, such as Crestron, can charge as much as they do. I’d love to be proven wrong, but I don’t see it. This stuff is complex and well beyond the average Alexa user.
So if the intent of OpenHAB 3 is to make it easier for developers to develop and maintain code, I am all for it. If the intent is to add bells and whistles, and the latest hardware du jour, to compete with Home Assistant, et al to attract new users, then I would be reluctant to follow that path. Sometimes being an astute follower, learning from the mistakes of others, can be more beneficial than being on the bleeding edge, especially if alienates or loses a chunk of the current user base.
I think Kai may have already declared this, but my vote is to maintain version 2.x in near term but add no new features. If 3.x bindings are backward compatible with 2.x (ie 2.x and 3.x bindings are interchangeable as seems to be the proposed development path since the solution for 1.x bindings in 3.0 is to convert them to 2.x bindings) then that would be great. The focus for 3.0 should be as the next generation platform with a modern, well documented and maintainable code base so that anyone with a little programming expertise can help maintain it going forward and no one individual is overburdened. This is realistically at least 12-18 months away as far as I can tell. Going forward for the foreseeable future, continue to make 2.4/2.5 available for dl for all platforms but marked as EOL with no active development or on-going maintenance. Nothing lasts forever, not even my refrigerator, so at some point we all have to make a decision whether to migrate or find another alternative that better meets our needs. For sure this will be easier for some than for others, depending upon the investment. Nonetheless at that point down the road we will have no option, but each of us will be better informed as 3.x will be mainstream and well implemented just as 2.x is today.