Good question and answer as we probably all received a request of new validation after conditions changed for Eclipse projects.
@kai or @maggu2810, what is the plan for the migration of the remaining org.eclipse.smarthome.core packages? I’m looking into it, but I haven’t found a way to access them yet through JSR223, which is currently breaking the Jython helper libraries, and potentially JS and Groovy too. I’ll submit a GH issue for this tonight.
What do you mean by “migration”?
What’s missing?
Is your point the rename of all packages? IIRC this will be done for OH3.
The repo and bundle name migration should be finished.
The only missing points I know about are the migration of some tests.
Yes, I was meaning the renaming of packages. I remember a conversation a while back but couldn’t find it. I was specifically asking about this due to a possible connection to this…
1 Like
I don’t see (but I could be wrong) any real relationship here.
The package names has not been changed and they seems to be no longer available.
So, IMHO it is related to the class loading itself (see my comment in the issue).
If we rename all the packages to org.openhab… they will still not be available (regardless if you are using the old or the new name). As long as the used classloader does not know about the classes, it cannot load them.
What I do not fully understand is:
You mention that there will be a lot of work now to establish processes, guidlines, etc. in openHab similar to what you had when hosting as an Eclipse project. Further it was mentioned above that “The good thing is: The eclipse foundation made sure we are not violating 3rd party rights / patents.”
So what would have been the blocker to move the openHab community into the Eclipse project. Thereby, you would keep the processes and the IP check. Now there will be a lot of work duplicating those processes outside of the EF.
I wasn’t involved with the decision but I can guess at a few reasons.
- ESH started from OH so it makes sense that it would come back to OH
- The bulk of the code and the bulk of the work in the openHAB ecosystem takes place in openHAB repos, not ESH, so migrating all of those to ESH might add up to more work than migrating ESH back to OH repos.
- As a brand, the openHAB name is much better well known than ESH.
- The openHAB Foundation is built around openHAB. It isn’t clear how or whether the foundation could be used in name and function with ESH.
Again, I wasn’t involved in any of these decisions, but these are some of the things that I’m sure were taken into consideration.
3 Likes
Hey Jonas 
,
You can check my findings below. I saw your mail on esh mailing lists but due to low probability of getting people involved didn’t reply there. Its great that you decided to come here and also show perspective from Eclipse point of view.
I think that fairly big trouble with ESH was/is strict formalization of contributions. I know it might sound ridiculous in first place but since we all live in era of github most of developers want to get their PR accepted and be done with issue they are willing to fix. With ESH, and openhab sadly too, this process is less dynamic. If I could quote Pieter Hintjens (R.I.P) - make progress before consensus, meaning try to get PRs accepted and acknowledge fact that some will require further fixes.
This is fundamentally different if you take a look on ESH and how its been looking a like in past years. openHAB is not much better in this I am afraid as I saw quite many extensions which are stuck in various “work in progress” state for months if not years.
Processes around project are important, IP clearance is great but, as we speak of developers who contribute code, making these fast & easy is equally important. If getting your code in project is difficult (each fix requires PR despite of having automatic checks) then getting a contributor/commiter badge is even harder. That’s kind of investment which only some companies can pay. I barely can see individuals who will spend nights to pass that. This kind of “inner” dynamics causes people to stay away from project and commercial entities too. You ain’t get dopamine out of it, you quit.
Frankly speaking I think next shortage of ESH was simply lack of user community. This is major difference between Eclipse Project and openHAB. First was positioned as framework while second was aiming to become a complete (DIY?) solution.
I am not sure if this is not the biggest failure of ESH as a project which led to current situation where absence of one company puts entire project on the knees.
I raised my concerns about possibilities for commercial adoption of openHAB without IP clearance, however current mood is to not guarantee any of that. Again, this is for me strange as it makes harder to convince companies to build solutions on top of OH, I also see in it some fairness (might be strange to you). Beside DTE, Markus company (maggu2810) and few others who paid most of costs there were companies who used ESH and did not contribute much back to projects… I’m not here to judge who, why and if these companies should actually do anything.
Now all potential commercial adopters have to decide if they stay with IP cleared ESH which might be slower in development, or have more vibrant code where they need to pay their checks by making IP clearance on their own.
Part of problem also remains in what was possible and what wasn’t within ESH. ESH was locked down with OSGi 4.2 specification which will turn 10 years this September. Setting a 10 year old API baseline for project in 2019 is not something which is common in Open Source landscape, especially if there are new releases of standard.
I must note that I have no problem with this particular specification. I worked with it till 2015 with no issues, however question is who pays for this requirement - one who requires it, or everyone else who wants to contribute to project?
Your sincerely,
Łukasz
2 Likes
Thank you for you detailed answer. I actually believe that there are some misunderstandings about how “formal” code contributions must be in an Eclipse project. IMHO, an Eclipse project, compared to any plain GitHub project defines two things regarding contributions:
- Committer vs. Contributor
A number of people are committer and can directly commit, another group are contributor and their contributions need to be reviewed by committers. New Committers are elected by existing ones. If you do not want to grant write access to your GitHub repository to everyone, you will need some similar structure for every Open Source project. I do not see a big formalism here, the rules are really simple. - CLA
As a contributor and committer you have to sign a CLA in which you basically agree to publish code under the respective license. Most GitHub projects with a reasonable maturity level have something very similar, too. So again, I do not see a big “formalism” here.
Please don’t get me wrong on this, I am not trying to tell anyone what to do. However in many messages on this thread, it is mentioned that the code can evolve “more freely” in openHab compared to an Eclipse project. I want to understand on what exactly this statement is based on.
2 Likes
If you do not want to grant write access to your GitHub repository to everyone, you will need some similar structure for every Open Source project. I do not see a big formalism here, the rules are really simple.
I think it’s in the details of this:
If you do not want to grant write access to your GitHub repository to everyone
There is a huge difference between giving everyone write access (aka trust by design)
and adding a even a small hurdle
Hi Yves,
I just checked the contribution guideline of openHab (https://www.openhab.org/docs/developer/contributing/governance.html)
This seems to be pretty much exactly the same rules as at Eclipse. There is an CLA defined, there is an election process for “maintainer”. even the three core principles are the same. I do not see how this is “giving everyone write access”.
At the end, I believe that the Eclipse ecosystem would benefit from hosting such a great community such as openHab and vice versa I believe that openHab could make use of the benefits that the Eclipse ecosystem provides, especially because the core principles and rules seem to be exactly the same.
More important, and that is why I raise these questions here: If there are specific things / rules / guidelines in the Eclipse ecosystem that motivate a community such as openHab to stay outsite and basically fork, it would be interesting for the Eclipse community to know about these and ideally fix them. That is why I am interested in the details
Thanks!
I don’t think it comes down to core principles and rules, those are indeed similar. But, for me, it boils down to brand and identity. openHAB (yes that’s how you write it 
) and ESH are 2 different communities. With openHAB it feels to be part of something. With ESH it feels much more like some ‘corporate’ organisation. As an individual I have a harder time identifying with such an organisation. Actually if you say eclipse I think IBM. This maybe totally unfair and doesn’t have any rational base, but that’s my association. (I’m not saying that is bad, it just feels more like work and not fun). What doesn’t help is if I go to the ESH forum it looks dated. It’s very hard to read, and doesn’t really invite to ask questions. I even wasn’t aware until recently there is also a mailing list. But it’s 2019 and who is using a mailing list today? I haven’t’ been involved very long with either communities, but I have contributed both to ESH and openHAB. But ESH never felt like a community, more like work. (Probably also because it never promoted an end product that appeals the end users). So to succeed in an environment that targets and would appeal to individual developers it should at least display a much more modern identity.
3 Likes
Again, I wasn’t part of the decision and don’t know all that went into it. But I think at least part of the answer to your question about how OH can evolve more freely are in Kai’s OP.
Emphases is mine.
I don’t necessarily think there is anything about the over all governance of Eclipse that is a problem. The problem was that openHAB was split in half. Speaking from just a user who supports others on the forum, just figuring out which repo to direct others to to file an issue was a chore. Some bindings were over at ESH, others over here in the OH repos.
hilbrand’s comments are not the only one’s I’ve heard regarding the forum and email list approach on the ESH project. The lack of a vibrant developer community on ESH, which is partly driven by that unnatural boundary Kai mentions is also hindering OH’s forward progress and flexibility.
Ultimately I think the major drivers had to do with what I mentioned above. openHAB is better known brand and since the bulk of the existing work already takes place under openHAB it was less work to move ESH to openHAB than to move openHAB to ESH. The openHAB Foundation is also a major concern and it’s not clear how that would work with ESH.
The following is going to be just my opinion based on my interpretation and interpolation from comments I’ve seen from developers. The core of OH was initially moved to ESH because of the promise that we could encourage commercial use and, more importantly, contributions. And at first that seemed to work out. PaperUI was initially developed and contributed in such a way.
However, over time, that approach hasn’t worked out. Many of the companies using ESH are not contributing back. Others who have contributed have stopped. And in some cases we are left with code to support that no one in the OH community can maintain. For example, PaperUI is apparently built using a JavaScript framework that none of the OH maintainers knows or is willing to learn. Why is PaperUI so far behind and frankly sucks in so many ways without forward progress? Because the company that initially contributed it isn’t maintaining it any more and we are stuck with this thing we can’t maintain and improve ourselves.
As a result, the extra work created by the “unnatural” barriors between the two projects is no longer coming with any benefits to openHAB. And because of the branding and the foundation, it makes more sense to move everything over to openHAB than it does to move everything over to ESH.
I fully get that the boundaries were creating overheads. I also understand that openHAB is the better brand. I also agree that ESH obviously did not have any significant community, as we have seen the drop of one company killed the project. Not to mention: I also agree the default forum at ESH is ugly.
What i essentially wonder about is whether it would be beneficial for the openHAB community to join the Eclipse community (e.g. as a working group), pretty much like the IoT and the JavaEE communities did over the last years.
That’s a question well above my pay grade. I don’t have any major opinion either way. I’d have a lot of questions about exactly what that looks like, but ultimately I have no power. As I’m fond of saying, you don’t have to convince me. 
I do recommend starting a new thread for this though. Tag the key players and make your case. What benefits would come to the OH community? What would it cost (in effort obviously) the OH community?
1 Like
This seems to be pretty much exactly the same rules as at Eclipse. There is an CLA defined, there is an election process for “maintainer”. even the three core principles are the same. I do not see how this is “giving everyone write access”.
I was talking in general. I still consider it possible or at least easier to move to “giving everyone write access” on the openHAB github then on the eclipse project.
What i essentially wonder about is whether it would be beneficial for the openHAB community to join the Eclipse community (e.g. as a working group), pretty much like the IoT and the JavaEE communities did over the last years.
I was not involved, yet what I read is we have a vibrant openHAB community and a eclipse community that is not involved in openHAB, why would the vibrant community move to the non vibrant site, risking everything.
from my distance side, it looks like openHAB did indeed try to join the eclipse community and it did not work out and now they are leaving.
As the Executive Director of two technical trade associations and as a contributor to the OH documentation (until I ran out of bandwidth :-(, I would share a few observations.
- A key difference between OH and ESH from a contributor perspective was people. @rlkoshak, @Kai and a number of others in the documentation team immediately made me feel at home.
- Response was quick - really quick! You felt like people were here and engaged. Try to make your first documentation contribution, and you got instant, positive feedback (i.e. nice try - here is our process, we love your contribution, could you please do it this way. Prospective contributor thinks, “hum - that’s not too bad. Sure I’ll do that”).
Contribute to ESH and after a while you get back a contributor agreement to sign. To try to help with some grammar errors in documentation. As someone said, it felt like a corporation. OH feels like a community. - Low barrier to contribution. Figure out a simple process, clone a repo, create a PR, sign off your work, and sometimes in an hour, the review is complete and when you look, your work is already published to the world. Nice. Nothing like positive feedback to make you feel like contributing again (hey! I am making a difference!). Contribute to ESH and do you get the same very fast positive feedback? Meh - not so much. Your contribution may hang around for so long that when you finally do get a response, you have to go look to see what it was you contributed.
- Quick support for issues. Everyone knows that @rlkoshak is a star, but there are many others who troll the community looking for questions they can answer. And believe me - when you are new to a project, and you see a question you can answer, your fingers fly across the keyboard the first time you do it, hoping that some OH Ninja doesn’t beat you to post a response. You can contribute, and that builds a sense of community that sticks.
- Taking but not giving back in a ‘corporate’ open source environment - yeah, that’s a thing. But not unique to ESH. In the community-driven open source world people contribute because they believe in the project, they want to see their contributions out there making a difference, and because they likely consume the work of the project themselves. In the corporate world, entities contribute to a project because it serves what I call their “enlightened self interest”. I run into this all the time. My trade associations have companies that compete very strongly against each other. They are in the trade association because they have mutual pain, and they think by contributing they can lessen their own pain, and that contributing does not advance their competitor too much. Many companies will only be in ‘monitor mode’ listening in and taking from the group but not contributing. That is just the way it is. And no corporation is going to finance an open source project unless they have figured out a commercial angle for it. Take the OpenVAS security vulnerability scanner. It was the core of a commercial product. Greenbone, the company, decided things were not working out, left some stuff public (now the scanner is available through a maintained package in the Kali Linux security distro), and is selling vulnerability scanning appliances and services. Frequently corporate open source projects take a tortured path into oblivion. Let’s set OH up for success in a true open source community, not tie it to a corporate “open source” environment where it dies a lingering death.
Having been a frequent contributor to the OH documentation, I would ask (beg?) the AC to keep it very simple to contribute, keep the process very lightweight, worry less about the legal parts to avoid feeling corporate, and make the whole thing feel like a comfortable and familiar home for anyone who is willing to give up some of their nights and weekends to contribute.
Low friction to contribute. Community feeling. Fast and positive feedback. A familiar and lightweight process. Modern environment and best practices in tooling. Keep it simple.
My two cents.
31 Likes
Hi all,
can you clarify something about licensing?
Having eclipse smarthome under the eclipse foundation was meaning that all the component included were of the right license.
This will be the case for openhab-core?
There will be a simple way to exclude all the non EPL-2 libraries for example?
There’s a plan to move all the license troubling components to for example openhab2-addons?
from a commercial point of view will be very difficult to integrate openhab-core if it still contains dependencies from for example GPL-3 libraries
Thanks for your work
Nick
openhab-core is Eclipse, Apache, MIT license only, that has not changed. Contributed code must be Eclipse License v2.
openhab2-addons allow more open source licenses, but generally also only the listed ones. The NOTICE file of each bundle tells you the story.
I don’t think there are GPL libs in OH core or official addons. Peace of mind. 
When using third party non-official addons in your solution, check their license terms.
If you don’t have intentions to sell your solution, you can combine any kind of code.