Increase openness and competition on components developed outside the official source code repositories

I must say that until recently I had assumed that the AC discussions (as limited as they are) were visible to everyone, and not just the select few. I really think that the points @splatch makes about openness are good points - we should welcome everyones opinion - not just the select few.

IMHO it would be useful if the AC had a broader member base, and it was a majority rule. With a broader membership, and possibly removal of veto (or only having it in very special cases) we could have a more open, and more progressive development.

The description of the AC on Github states -:

The purpose of the AC is to be an authority to appeal to when there is an impasse among the developers and maintainers of the various parts of OH or to help maintainers from different parts of OH to come to a decision on how to address a cross cutting change.

Maybe AC should be renamed to the “Complaints Department” :slight_smile: . Seriously though, I’m not sure that this description is consistent with the system “Architecture”?

I think that maybe the reason that the AC forum is not getting much use is that, given that the any “impasse” between “different parts of OH” is almost certain to include the core maintainers, and the core maintainers sit on the AC, there is no point to bring issues to the AC if they are already rejected by core maintainers.

1 Like

That is actually being discussed in one of the open issues. I’m very sensitive to conflicts of interest and it doesn’t feel right for someone to be a party to the issue and judge at the same time. There should be some sort of recusal and code of ethics in place.

3 Likes

Thanks Rich. I had another read through that discussion in the AC and see you raised almost exactly the same point :+1: . I guess my only comment here is maybe “being discussed” might be a little optimistic since this discussion seems to have finished at the beginning of February :wink: .

I guess maybe we’ve hijacked the original post a little here which was more focussed on binding development outside of the OH addons repository. However, I’ve personally been involved with OH for around 10 years now, and it does feel like things have plateaued in some areas, and there needs to be some change to facilitate further development and innovation. I think some open discussion on this is healthy :slight_smile:

6 Likes

I agree with most of what @splatch and @chris said. The “unanimous vote” rule essentially grants something similar to a BDFL status to the AC members as they can block every decision. This is even more true if two out of three core maintainers are members of the AC, because openhab-core is where the most important decisions are made. I would prefer the AC to make decisions based on a majority rule and have all openhab-maintainers as a member. To keep it manageable, all issues brought to the AC should have a two-week discussion period and a one or two-week vote period afterwards.

I also think that the group of maintainers (especially in core, but also in other repositories) needs to be larger. There are 26 open PR in core and 92 in addons of which some have not even received a single comment since several month (like Add osgi support for ThingHandlerService implementations. by cpmeister · Pull Request #1941 · openhab/openhab-core · GitHub or more recent [dbquery] JDBC database bridge by lujop · Pull Request #11428 · openhab/openhab-addons · GitHub). Obviously the amount of work cannot be handled by the current members of the respective groups (no offense intended, everyone’s time is limited and we are all volunteers) .

5 Likes

Thanks Chris for coming back to my original topic. And your are right. I mainly want to focus on the development and governance of external bindings. I only can repeat that IMHO there should be much less governance and more support for supporting external development.

Let’s take the example on the two best known digital assistants, Siri and Alexa, and how they address their openness and acceptance in terms of governance and support for development.

Whereas Alexa provides the cloud infrastructure and stable APIs and SDKs with nearly no restrictions on the addons (as known as skills), Siri is a closed system fully under control of Apple.

The differences are quite remarkable. Siri as a closed and governed system lacks innovation velocity and solution broadness especially if cooperation with non Apple development is needed. Alexa on the other hand is thriving on solutions and integrating areas of functionality in such way that even Amazon would not have guessed.

To take a strong position on my case: for me openHAB is much more like a Siri than an Alexa when it comes to supporting external functions to complement the openHAB plattform.

From my point of view there should be a distinction between Core and Addons. For the first part, I think that the current governance rules are needed to keep the openHAB platform sound and safe.

For the addons I would like to see a much more open approach. For the first steps, I would like to see the openHAB bill of materials (BOMs) brought to a state that you can actually use them as a addon developer outside the maven addon reactor project.

I really like the new market place. I think there should be less official openhab addons and utilize the marketplace more.

Regarding building an addon independent of openhab take a look at jrule GitHub - seaside1/jrule: OpenHAB Java Rule Engine
It can be built standalone or inside the big openhab-addons project.

Pr for the change: Fix Windows support by LumnitzF · Pull Request #24 · seaside1/jrule · GitHub

Thing is, you inherit a whole bunch of settings (bnd, compiler, header files, static analysis, null annotations) and plugins which might be (or are) irrelevant for your thing. I am referring to this point: jrule/pom.xml at main · seaside1/jrule · GitHub.

The directory plugin fix you mentioned is there to manage paths for some of the checks. So PR you mentioned really solves a problem which comes from how openhab addons pom is structured. It is really not suitable for external development and that’s what Frank is rising up. What he/we need is a BOM (bill of materials pom) which says that openHAB core 3.2 consists of this and that artifacts (config, discovery, thing, item etc), and 3.3 will ship this and maybe some more (think of ephemeris module which was added to core). Maybe some additional BOM with external dependencies would help too. After all these are pulled and managed in by core build itself. That’s all.

Instead of arguing, why not come up with a PR to suggest a solution without breaking existing addon builds.

1 Like

Not sure what you mean by arguing, so far most of above feedback indicates that there are gaps primarily in policies which hold on multiple areas - especially build, code and documentation.

If you ask me why not coming with PR:

  1. Because it is not clear if this change would be accepted in first place. It requires some touch in OH core build which I do not maintain nor have a badge. I don’t think anyone is willing to wait (especially me) 2 months until it will be reviewed and rejected because of typo or copyright date.
  2. I brought very similar topic in this forums earlier and it was left without resolution: Maven BOMs without dependencyManagement, not picked, guided or lead by any of core maintainers.
  3. There is split brain problem in handling external addons. As far I remember some of addons were pulled down from marketplace as cause they clashed with official ones, there is also no clear statement that forum is fine to discuss issues related to them.
  4. Investing time in preparing code changes without a clear acceptance policy, as it could always be vetoed by single maintainer or AC member for any reason, is bigger waste of time than complaining on how it works. Until there is a clear, objective and publicly written definition of acceptance criteria, what is welcome and what’s not for OH core, I don’t think there is a point in committing any time into OH core.
  5. I made this work already for my own addons, why I would waste time on this again given above points?
5 Likes

Neither do I. But nevertheless I have made PR’s to core, and have had them succesfully merged. So why not just try it. In my opinion, if you are honest, precise, and polite, in explaining your intentions, then maintainers are willing to support it. In my opinion also, making multiple smaller changes, is easier than making elephants.

4 Likes

Absolutely - and so have many others. The problem is that there are also many instances where PRs will sit for months or years without even a comment. I have personally had a number of such PRs and issues, and this means that people don’t want to waste their time submitting PRs that will not even be considered.

This is highlighted above by @J-N-K - I note that one of the PRs he linked was raised in December 2020 and has had no comment. I think this is the sort of issue that needs to be resolved - it’s not meant to criticise individuals who are volunteers, but more to motivate and empower people who want to contribute.

6 Likes

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:

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. :wink:
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. :wink:

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.