Long story short, I’ve opened an feature request under:
Let’s just see, if, when and how the reaction will be.
All members of this discussion are invited to vote, comment and support this issue, if you feel the need for it.
1 Like
Sorry for pulling from github here, but I think its something which is fairly subjective on how we approach community and people.
A github comment froml @glhopital for reference:
Lets face truth, there is not much framework evolution in core. To avoid delusion - I mark bold new features coming into openHAB core:
- openHAB 2.5 Release | openHAB (github) - split from ESH, Ephemeris, 46 new addons.
- openHAB 3.0 Release | openHAB (github) - removal of compat layer, repackaging (esh → oh), new ui, semantic tags, blocky. In total 86 new addons with scriping rules. No new core features.
- openHAB 3.1 Release | openHAB (github) -ui translations, metrics. No new core features, even if metrics are new contribution this module could live in addons without loss, its there just to provide micrometer packages. 42 new addons.
- openHAB 3.2 Release | openHAB (github) - rule engine enhancements, 18 new addons, forum marketplace (even if its not listed as new feature, its notable).
To me this list seem rather short in new features. Obviously there are important improvements and changes such as repackaging and UoM migration, but in practice these are not moving core anywhere beside place it was left after ESH migration. These three new features we saw in core from 2.5 release in December 2019 are not evolution. This is stagnation. There is also a visible descent in contributed addons (46 in 2.5, 86 in 3.0, 42 in 3.1, 18 in 3.2) after migration to 3.0 have been made. I, as a random folk visiting forum from time to time, see much lower activity than it was in the past.
To re-enumerate above. Over years which passed from ESH split there was very few new things. Namespace migration in 3.0 - no functionality. Ephemeris - new functionality which does not integrate with calendar bindings till today. Often there are enhancements in core, but they are primarily cosmetics which do not bringing a lot of new functionality to addons, ie. new event kinds published by core are rarely taken by addons. I don’t think core maintainers will ever be able jumping over multiple repos to bring new functionalities while working on core, that’s not going to happen. If you would for example introduce an automatic take-polling-thing-offline mechanism in OH core, would you feel yourself responsible for modifying 250 out of 350 bindings to use it? There is separation of addons and core repos for reason and some bindings lag behind cause these are low interest ones and they do their work without being up-to-date with core. Same applies to external addons, they might lag behind just like some of “official” ones.
If it happens that core is moved ahead, ie. there is a persistence or config layer change, in most of the cases work is really about solving compile errors.
Looking at build - there is a bunch of things enabled by default, with no info how nor build profile to quickly disable all of them, which slow down build in a dramatic way (SAT checks by default). There are also policy changes which break build for no valid reason (again SAT, nullnes) and so on. There was also a history truncation for addons repository which, I as an author of lengthy maintained addon (such as modbus), would be very unhappy for. SCM history is the only one reliable connection we have to the past. Github might come and go, but git/svn log is there for everyone, hopefully forever. Each time when you do advertisement of official addons keep in mind all the cost it brings, not only compile and copyright fixes once a year.
The way how OH build is structured reflects how dependencies are managed. Because addons did not manage nor declare ie. commons-lang as their own dependency, they all relied on commons-lang promoted to them by openHAB core. When some core artifact removed it, openhab-runtime-base feature was stripped, multiple addons were affected leading to domino effect. In many ways, current core construction leads to problems which force very specific solutions just to avoid long needed OH core restructuring.
Whole openHAB as a system is relying on “individual efforts”, stale PRs are not going to solve your primary concern, cause that’s how this system development works. You also note that you use some of external addons, but why you, as an developer and core maintainer would want others being blocked from a) doing their own thing b) trying others thing?
I get, that you all are concerned about quality of addons provided by OH, but external addons are not your concern. They are concern of users who deploy them and external contributors.
You have to make your mind. You either build a open source platform or a product. If you do the second, then being a gardeners dog is expected, but then you should stop fooling everyone around, that its community driven project. Then its clear to everyone that its somehow somebody’s interest driven.
If you do a open source project, define clear and objective rules, make distribution channels and stop acting as an guard of clueless minions running opensource software. What you do now looks to me like a fear of publishing complete set of linux kernel header files cause people then will write their own drivers which could break somebody’s operating system. 
A final thought - the contribution criteria can be defined in one of two primary approaches. First - define things which are prohibited (libertarian way), or second define things which are allowed (authoritarian way). Write and publish guide, let other people do rest of work.
5 Likes
So, we are one week later. And the issue is, chirp, chirp, chirp, without any reaction. And in my personal experience this is just the standard way of dealing with user effort.
2 Likes
Maybe its good idea to look at history of openWRT and LEDE projects: LEDE and OpenWrt [LWN.net]
History there describe issues with an infrastructure (not affecting OH beside cloud stuff I suppose), but also contribution and patch acceptance criteria. Technically speaking LEDE become a public fork of the openWRT project with an aim to democratize project work.
As you can see similar things are happening in open source universe.
Luckily for WRT users after a year and a half a merger plan was made. A lot, if not most, of the points risen by LEDE founders was integrated back and overtook openWRT codebase which been archived.
I don’t think OH is in such a risk, cause there are very few truly active core maintainers and even less businesses relying on it. Yet LEDE was announced after openWRT turned 12 years old which is happening this year for OH.
2 Likes
So more than one month has passed. There has been lot of discussion here in the forum and on the issue. But so far no reaction on the issue from the maintainers/the project. It has no one assigned, no labels attached, no project linked and is still open.
I’m doing software professionally and have learned, that technology or solutions are never the problem, but persons and culture is. If I see a team, that is not capable of giving a reaction to a users request withing a month, there is usually the house on fire from either management, product owner or scrum master.
So my conclusions are clear then. I will withdraw my request and close the issue having learned once more that openHAB has lost openness and engagement in collaboration with non project members.
That said I will no go on celebrate my fathers day, having a nice barbecue and the one or other beer.
Cheers!
This is simply not true. I have replied five times in the issue and three days ago offered to review and merge if a contribution is made that fulfills some requirements. There is no need for any other maintainer to step in and I have seen no objections from core maintainers that would prevent a merge.
9 Likes
You have a wrong approach on how open source software moves. You can have great ideas, if you’re the only one interested in them an no one , even you, volunteers to jump in, who do you expect can designate a volunteer to do the job ???
I’ve got tenth of PR ongoing, in mind or draft - so much that I don’t even spend time on my own openHAB.
I don’t even imagine any core maintainer coming to me saying : please, work on this, one month elapsed !
6 Likes
Damn. That’s a bit extreme considering one of the maintainers has responded affirmatively that he would review a PR with the desired functionality. Frankly, if I were a maintainer, I’d be insulted by your comment.
8 Likes
This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.