The Rate of Innovation

[kgoderis (Karel Goderis)]

I want to share a concern that lives within our community for a while, and that has been debated before, but no solution has been decided upon:

How to increase the rate of innovation to openHAB/Eclipse Smarthome? How to speed up contributions?

The rate at which new stuff is incorporated, wether bindings or other add-ons, is very small. It hinders further development of the platform, it slows down the migration from OH1 to OH2, and so forth

Are we too much of perfectionists, trying to get code perfect before we get it in? Are we too restricted by our self-imposed project framework (ESH), or the commercial interests of some (ESH being used in commercial products) ?
It is also clear that the resource bottleneck as we know it (and debated it) will not be solved easily, if at all. Let’s face it, it won’t be solved period.

Therefore I am wondering if we should not opt for a different governance model all together, knowing that each approach will have advantages and disadvantages. Why don’t we add new code the repo’s as it is (for anything that does not change the core or the API)? if problematic, it will be fixed by the author or those concerned? If it is not beautiful (e.g. code formatted), it will be done afterwards. Why can’t we add totally new functionality as it is, and just mark it experimental? At least it allows people to play with it, comment it; instead of being on the drawing board too long and so forth. Let’s dare to make mistakes

K

[Marty56 (Martin)]

Reducing the quality of the officially released build is not a desirable option.
I would even go into the opposite direction. If a contribution has serious bugs and it is not maintained anymore, this contribution should be removed and properly flagged as instable. This would avoid users from running into unresolved problems discovering flaws that others already have failed to resolve and where on the other hand there is not hope that those flaws will be fixed anytime.
Examples that would fall into this category would be the GreenIT UI or also the Sonos 1.x binding.

[marcel_verpaalen (Marcel)]

Thanks Karel to bring this topic back,

I think indeed it is a discussion that is needed once more.
Though earlier we hinted at this, with the karaf framework available that allows online repositories, we should make it much more easy to contribute experimental / not fully checked stuff.

I think having the ESH framework under some control is useful, so we all build on the core, but esp bindings should be easy to contribute. Now with many OH2 bindings in the forever PR waiting mode it is dis-encouraging people to contribute, hence hindering the innovation.

[chris (Chris Jackson)]

I can understand the sentiment with this, however, in my opinion it’s in no-ones interest (commercial or otherwise) to have a core that isn’t properly managed. It needs to be stable, and it needs to not be subject to feature bloat, and it needs to be documented and understood… I’m also not saying that all of this is where we are today, but I believe it’s the plan, and I think it’s right… So, I would advocate that core elements are controlled as they currently are (be it ESH core, or OH core).

However, where I would agree is for bindings. This is likely where the majority of problems lie anyway - they are numerous, and often they can’t be tested by the maintainers, and they can be hard to review. Here, I would agree that for the majority of bindings there’s a strong case to let the community “sort it out”. If a binding is poorly written, and popular, then it will likely get attention - if it’s not, then does it matter as it’s probably only used by a few people anyway…

As @marcel_verpaalen mentioned, with Karaf it should be possible (I guess?) to manage this better. Why do we even need to include every addon into the openhab repository? Why not keep some of them separate - it would make maintenance easier. I would like to think that Karaf could handle multiple repositories, so maybe we can just update where Karaf gets its list of bundles to link to multiple places (I know little about Karaf, so maybe this isn’t possible). Or maybe it’s possible to add an option where the user can type in the repository link into the UI, and Karaf loads directly from there…

For ‘non-core’ bindings we could still have a wiki/doc page in the main repo so that people have a central place to find information, but code maintenance could be elsewhere…

Just some thoughts really . Maybe someone with some knowledge of Karaf can comment on the options we have available?

[tarioch (Patrick Ruckstuhl)]

I fully agree with @chris comment. Keeping the core stable and “restricted”, but opening/splitting the bindings makes a lot of sense to me. That way you can also split up maintenance of the bindings for people actually interested and owning the hardware for the binding.

[kgoderis (Karel Goderis)]

Thanks all for the responses

It does make sense to separate the flow/evolution of bindings from the Core(s), but even at the level of the Core(s) I think some organised form of freedom should be possible. I sometimes have the impression that we (collectively) try to get the Core too perfect, changing little details left and right, but forgetting sometimes to focus on major pieces of work. Just one example, and not because I was at its origin, but some considerable time ago we discussed a Notification infrastructure. Well, it is still on the drawing board, whereas it would have expected it to be part of the distribution, even in an experimental format. I think it is ok to flag stuff experimental, and it better to have it in there than not having it in there. Another example: we have seen a major contribution on Automation, but in order to reder it useful in the “userspace” some additional code has to be written. Without that, imo there will be little usage of this nice feature.

I mean, looking back, and just being objective, I can only tell that my ESH/OH2 installation has not evolved in the last 18 months, (and admittedly, I am maybe one of the first ones to run an operational environment on OH2) and that most of the stuff I use is not in the official repo (yet). I have so many ideas on how to evolve/add to OH2, but it does not make sense if it is not to the benefit of the community… And the stuff that is ready, can not be contributed because it depends on other building blocks that are stalled…

I know we are all volunteering in ESH/OH2, spending a lot of spare time (that should normally be allocated to wife and/or kids), and so on, but the last thing I want is to be frustrated by all of this, and getting the feeling that all the efforts that I put in are simply a waste of time…

[kgoderis (Karel Goderis)]

@Marty56 @marcel_verpaalen @chris @tarioch

Now that openHAB 2.0 is released, I think we should address our concerns.

@Kai I am the last person wanting to point a finger at you because I know how much the burden of OH/ESH is weighting on you, your professional life and family life. Knowing that the IoT space is moving very rapidly now, with a lof of initiatives by the major companies like Apple, Google, Amazon,…, the only thing we do know is that this will not slow down, but accelerate. You mentioned that we now have 130 bindings in the repo, with 200 on the horizon. I think it is safe to say that it won’t be possible for a few individuals (e.g you mainly) to keep on maintaining this, and it also safe to say that 200 is an underestimation

Although I understand the interest (personally, the ESH consortium, commercial usage) to have clear cut APIs in the ESH/OH2 .core, we should organise ourselves differently. You are a perfectionist, which is what made the .core so good. However, I think it is ok to (1) delegate responsibility for each binding to one or more persons, with a clear mission to keep up some coding standards, review changes, improvements, new features and (2) step a way from “perfect” code in these bindings. We should enhance the collaborative nature of OH2 Add-ons repo, and give bindings owners the ability to merge PRs for their bindings. I think we are all sensible enough to do that in an orderly manner, without creating a havoc or whatever. On a personal note I find it ridiculous to have PRs for bindings awaiting to be merged for over more than 2 (!!) years

Doing nothing is not an option.

I do not want to impose the mechanism that needs to be used, I am not a software engineer by profession, but I want to keep it fun for myself. If that would not be possible anymore, then that will be the end for me with respect to openHAB

[Lolodomo]

There is clearly a bottleneck with today 113 PR waiting for a merge (Eclipse SmartHome + openHAB2-addons). I think it is generating a kind of frustration for contributors including myself.

[MHerbst (Martin Herbst)]

I also agree fully with @chris. Having different levels of core components plus different versions of bindings would only lead to confusion and at the end to an unstable product. Therefore I would not change the rules for the Smarthome development. Maybe the introduction of automatic code checks can speed up the reviews process.

The situation in openHAB is a bit different. We have more code contributions from more developers. That means a lot more work for code reviews. I agree with @kgoderis that it sometimes takes too long until new bindings or new binding version make their way into the official distribution and that it can be frustrating.

I don’t really like the idea of freely selectable repositories because it is not guaranteed that these binding versions are compiled against the correct base versions of openHAB and Smarthome.

My idea is simular to Google’s approach with Android apps. In Android you can decide whether you want to see and install beta resp. alpha versions of apps. We could go a similar way by having 2 or 3 code repositories. The “release” repository remains as it is now with the same level of code reviews.

In the beta and alpha repositories we would only use automatic code reviews (via Checkstyle, Findbugs, PMD …) and of course an automatic build. If the code passes the automatic checks and builds it wouldl be merged automatically and then available for installation.

openHAB users can then decide whether they want to see and install add-ons from the beta or alpha repos or only release versions.

[splatch (Łukasz Dywicki)]

My view on that is completely different since I see problem differently. Knowing projects having lots of components/integrations I can guess that 80% users uses less than 20% functionality and 20% of bindings generates 80% of intrest. This means that quite big amount of code is checked in once and not maintained any longer. To identify hot spots and most important bindings which are important to our users we would need comunity survey.
It is clear that bindings which are developed by unpaid members strongly depend on their free time and will to keep contributions. In many cases there also physicsl limitations such lack of test devices to cover vider set of hardware vendors. We wont change that for sure.

Pending pull requests queue is number visible outside but did anyone go there and verified if these are abandoned or not? For example there is modbus binding for oh2 which author could not complete since quite long time. There are also important components living outside project (for example zwave device db), and we have no troubles there at all.

Because Eclipse SmartHome defines an framework for writing extensions we dont need to worry about OH2 compatybility that much. I belive current version is fine, quite stable and reliable and can stand for long time. This means that binding authors can build their extensions against framework and just throw them in without any supervision or control from people having “commercial interest”. There are bindings which upgraded/first versions are offered for tests before even addons PR gets accepted. People who are interested get then earlier and everyone is happy.
Having some form of marketplace would be great but we need to know this is piece of infrastructure which needs to be developed by someone. From other hand this could become yet another layer of control over community and offered binding donations.

[MHerbst (Martin Herbst)]

@splatch

Pending pull requests queue is number visible outside but did anyone go there and verified if these are abandoned or not?

You are right. There are several PR with a state of “awaiting feedback” since quite a long time. Maybe we should close such “Zombie” PRs after some weeks of inactivity automatically.

[marcel_verpaalen (Marcel)]

I would also very much encourage to rethink the way the PR’s get included.
I’m all in favor of a very solid, api stable core, with strong review, …this is what ESH is all about.

However, for bindings in OH I think we should be much more flexible. Let the user decide how much 'risk’he/she would like to take.

So we have our existing set of reviewed bindings, great.
But please have beside them beta bindings repository, which receive only basic checking.
And 3rd , as @MHerbst described : alpha repositories we would only use automatic code reviews (via Checkstyle, Findbugs, PMD …) and of course an automatic build. If the code passes the automatic checks and builds it would be merged automatically and then available for installation.

My simple question… what is the major concern? Resources? Stability? limitations of the current setup? something else?
I think we would all appreciate to understand that. At least we can have a meaningful discussion to address the concern.

[Kai (Kai Kreuzer)]

I really find it weird that in all that discussion nobody tries to find a way to help getting code reviews done quicker. But this is actually the whole issue, isn’t it? If there were maintainers that check the code and confirm that it

• respects the license
• does not have any unclear legal conditions
• follows common coding guidelines
• is written in a way that it complies to the architecture, so that it does not break unexpectedly if some internals of the framework are changed
• is written in a way that others have a chance to understand, fix and further maintain the code
• that it comes with documentation for the end user

within a few days, there wouldn’t be any reason for discussion, right? It really makes me wonder, if I am totally insane that I am spending my time doing this job, while nobody else cares about it and only see the frustration of the contributors, but not my frustration about having put so much effort into it in vain?

An no, to be very clear: NOT enforcing above rules, i.e. ending up with code that has no clear license, imposes legal risks, which is unmaintainable and an awful example for others (who will happily pick it up as a starting point for their own developents) IS NO OPTION.

Btw, the complaint that it takes so long is imho only valid for “full” new binding contributions. Whenever small new functions are added or bugs are fixed, the PRs are imho usually processed very quickly, at least that’s what I am trying to do.

So the really sad thing is that there aren’t any volunteers for openHAB 2 reviews (meaning looking at code from others and not only on his own - btw, ANY good project, be it open or closed source should really have a peer review process in place, this is enormously helpful for the code quality).
It actually works better on openHAB 1 add-ons, so I wouldn’t want to give up for openHAB 2 add-ons yet. In the meantime, I have tried to find other helpful measures to speed up reviews, like automatically checking the “boring” parts, which will be a huge step forward. You are all cordially invited to help reviewing and testing this feature, I am so much looking forward to have it in place.

So having said this (and I hope the plea for more active maintainers has been heard), I also see that openHAB is continuing to grow in popularity and even if we manage to have more maintainers, it will be difficult to keep up with growth.

For this, I have some good news:

Having some form of marketplace would be great but we need to know this is piece of infrastructure which needs to be developed by someone.

I have found “someone” that developed exactly such a piece of infrastructure: The Eclipse Foundation!
I have created this issue for ESH today, which will mean that once it is implemented, openHAB can install content from the Eclipse IoT Marketplace. Everyone is free to upload content to the Marketplace, mark it as alpha, beta, production or whatever and does not even have to make it available as open source - so this is the right place where nobody has to worry about source code quality, yeah

I think this will help a lot to grow the openHAB ecosystem in a way that not everything has to live within the official openHAB repositories. Nonetheless, I very much welcome every contribution to the repos as PRs, since this is really handing over the code/value to the community as a whole - where it can continue to live and grow and change the people maintaining it. It is simple “there and free”, while content on the Marketplace can disappear at any time or turned into commercial offerings once enough people from the community have helped to identify and fix bugs.

FYI: The current plan is to have the Eclipse IoT Marketplace as well as the ESH integration ready (meaning also available in openHAB) by end of March.

[cschneider111]

I wonder if a similar approach like in Apache can be done. People who want to be committers have to sign a committer license agreement and automatic checks for the license make sure every file has the correct license.

If someone produces good patches he can be voted in as a committer and from then on can work using commit then review style. Committers can then also act as reviewers of pull requests. So that could allow to spread the work over more people.

I think a completely different approach could also be done. As openhab now is based on karaf we could allow to add feature repositories from anywhere. So people could create their binding on github, post the releases to maven central and users could install the binding right away. This could also allow to create bindings in a simpler way with a pure maven build (no tycho). Of course then all apis must be available from a maven repo … not sure if this is the case already.

Openhab could then host a list of such feature repo urls to make it easier to find them. At karaf we already have such a list with lots of external feature repos.

Christian