A separation of repos could by overcome by the application layer. Puppet was already mentioned above. Those guys have created PuppetForge. Within the application you can search for modules and install them with a snap.
Every module developer can register its module on puppet forge. Once done its searchable & installable via the application.
The so called ranks seem to me like tagging which is just additional information for the enduser to know if the addon is used frequently or not. Tags can be changed easily, so “down ranking” an outdated module should be very easy.
Third, when doing installation of addons via the application it should be fairly easy to track at least the “number of downloads” to calculate a rank or popularity. Or if an enduser is willing to offer such information from his/her system also the status of an addon could be reported (numer of items/things created by an addon within the installation, etc).
I also like the idea of migrating into “gemeinnütziger Verein”. As a particiapant I went through that with another open source project and it went quite well.
I also see @Kai’s points and I would love to see openhab move to a “e.V.” That would make donations a lot easier and everybody can have an impact on the organizational structure.
Through the discussion I see a lot of “technology related” points. IMHO we should first decide on the core principles of the future organisation/architecture and then look after the technology that would solve the problem.
The areas I see: "openHAB": Should have a stable core that is maintained by a few experienced people who manage release cycles etc. It should be extensible via “Add-ons” that can and should have different level of maturity depending on e.g. standardization in the industry, number of possible users, contribution possibilities of the author. In the end this will perhaps result in a kind of “attribution” or perhaps a ranking. [quote=“Spaceman_Spiff, post:14, topic:4048”]
“fully-reviewed and actively maintained”
“fully-reviewed and not actively maintained” //Maybe this could be a tag to the repostory
“not-in-depth-reviewed, but successfully tested”
“not-reviewed and not tested”
and maybe “development phase”
[/quote]
+1 @Spaceman_Spiff
Contributers/Maintainers: Everybody should have the possibility to contribute easily (as it is today). That means people who have developed a certain solution should be able to make it public and let others use it. The code should be open source of course for the reasons already being mentioned (security, enhancements,…)
Users: An end-user should be able to easily find and get that “add-on” and add it to his system. Call it a “marketplace” (why not?) And he should also see the utilization of that add-on to decide what he can expect from it.
One repo per addon works excellently for jenkins and puppet (which was mentioned here many times). While setting up the build jobs might sound like lots of work, I would offload this to a robot / shell script. If you decide to go this way, I would offer my help in setting up the necessary infrastructure as this is what I am doing all the time in my day job.
My main argument in favour of seperated repos (which would then be part of the “openhab” organization on github) is that you can leave the resposibility for issue tracking and defining release schedules to the maintainer of each addon. And, if and when one maintainer loses interest, another can jump in and continue work.
Code quality could be defined via some kind of reputation metric. Again, this works just excellently for Jenkins and we should steal (oops, get inspiration from) the best
Thanks for all your input. Ok, so I might have @hakan prove me that this many repos can be handled through clever automation - if this really works well, I agree that it might be a good option after all.
Nonetheless, I think we still will have different ranks/levels of integration of the bindings. If anybody is free to open a new repo under the openHAB Github org and just put any code in there, this simply won’t work out. So there has to be some governance and this usually means manual effort. And believe me: Without our code reviews, the openHAB code base would be a real mess today and I would never have had the chance to build something like the openHAB 2 compatibility layer, which relies on the fact that some principal architectural rules have been followed throughout the code. And this is something that you cannot check automatically, you really need a peer code review.
So this brings me back to why I originally started this topic: Every change we discuss now is merely a workaround for the fact that we have not enough maintainers, who are willing and capable of doing code reviews. Ideally, all code that ends up in one of the openHAB org git repositories should be clean and reviewed. Everything else is imho a compromise.
So to reach our most pressing goal, the 1.8 release: Are there any volunteers for reviewing open PRs that currently exist? I would prefer to only start with bigger changes once this is out of the door.
How would you like us to notify that a review is done? Small comments like you do, and after the review comments are incorporated by the author, a “LGTM” comment with a notification to you? Or setting a label “ready-to-be-merged” on the pr?
The jenkins way is to have the original author work on his repo until something is presentable, and then fork that into the main organisation by a robot. Afterwards, the original author gets push permissions to that repo.
We could add any levels you like, for example allowing only PRs which have to be reviewed and approved, much like it is now, only with the difference that addons live in their own repositories.
After a developer gains enough fame and sense of code quality, give him push rights…
Cool
Well, in order to not have two people reviewing the same PR, the first thing to do is to have a PR assigned to you.
So my suggestion would be that you leave a comment on the PR you would like to help out on and @teichsta makes sure that it is assigned to you. And then, yes: Check the code against the guidelines and leave comments for the author. Btw, if you are good in automation scripts, you might want to create a separate topic to discuss about what of the review could be automated. I think there are many possibilities, like checking license headers, JavaDoc, illegal package imports etc.
as soon as you give a hint which PR your are going to review i’ll assign to you and set the “review-in-progress” label. Good look with your first binding review @hakan. Let me know if you have questions. Questions around binding reviews should be discussed here in the community. Please tag your thread with “review” and invite me to the discussion.
I have bootstrapped a “gemeinnütziger e.V.” some years ago. One crititcal thing to consider is the goal of the organisation - there is a fixed list of organisation purposes that you must fulfill in order to reach charity status. If you need help doing this, especially in terms of a “Satzung”, please don’t hesitate to contact me.
@gonium Thanks for the hint. Yes, I have seen that there are rather fixed templates that have to be used. Will come back to you when thing get more concrete.
I would agree about the non-profit judicial status. Certain things are likey less “business” oriented, but I’d say that it is the best suited approach to an open source community driven initiative.
I just read an article by a guy called Martin Fowler on Design Stamina Hypothesis; it talks in part about technical debt acrued through software design (or lack thereof). I agree with what he is saying, but beleive that this concept goes much farther, as running a project or a business isn’t just about software development, and ALL parts of an organization need to be aligned in order to optimally design and deliver solutions. A business case that ever-so-slightly misses the mark, coupled with a great dev. team and good software design doesn’t mean that the project will be successful.
Which leads me to my pondering… idea… could certain supporting organizations lend other types of resources which could assist, strengthen, and enable the core team to be more effective and productive? Examples of what I am thinking are business/management consulting (the model/design of the org./project to work with as little friction with its parts as possible), project management (this is a job in itself), legal counsel (for the organization structure change). I’m sure a certain phone company would be able to justify allocating some more man/woman-hours to the project.
I agree that the whilst the docs are a big help, but they are also a big problem.
Especially when it should be the definitive “voice” and resource.
The apt-get install is a prime example as it is always plagued with issues https://github.com/openhab/openhab/issues/1429 but to most users, especially new ones. It is seen and should be seen as the “Apple/Play Store” and things that come from it, should be up to a working standard.
Because as interesting as it is, and whilst I obviously appreciate that putting “things on screens” is complicated. This readme is more than a little confusing
Curiously I started messing around with migrating the wiki to a docs based system a few weeks bac, but still keeping the process relatively automatic. The Github Wiki is beautifully simple, but by only allowing one level of navigation, is a little too simple
I had some success using both Jekyll and Readthedocs. I can send dev links if you PM, they are obviously not for production yet.
I do think there should be some sort of styleguide about wiki entries, to cover use of markdown and tone of voice. I am happy to help with this (I am a front end designer/developer). There are a lot of assumptions made about the knowledge of the reader in the current docs. Even if we don’t cover the basics every time, we should reference where the user can find out about the assumed thing… (if that makes sense)
Ideally for each pull request or binding, part of the code review should include the docs and making sure they have been updated and reviewed.
I would second hakan’s suggestion. Maybe you should consider ranking add-on “owner” and not the add-on itself. I would think that this might scale better. If you assign an owner per repo, then as the owner proves that they can follow the same governance and code reviews that you would expect, you raise his/her ranking. This way, you are not acting as a bottleneck for code review, but still have a high degree of confidence that committed code is adhering to strict standards for owners with Rank 1 standings.
I think, that it is a good idea to better involve the community, but I am not sure, if a “gemeinnütziger e.V.” is the best legal entity to do this. There are some liability issues for the board of a e.V. which I thought you wanted to avoid with founding a UG.
Maybe there should be two entities, one wich protects against liability questions and one to collect financial support for openHAB. This issue needs some thought.
And just to mention it: Maybe a “gemeinnützige GmbH” is suitable.
This is something I would love to see as well - therefore I think that not only individuals should be allowed to become members of such an organization, but companies as well. Nonetheless, I think this is a difficult path as I would want to avoid that anybody with specific commercial interests influences the project for his own benefit.
What makes you so sure? As long as companies do not have any direct business value from such an investment, I doubt that it will be easy to have them allocating resources for an “idealistic” project.[quote=“sam, post:28, topic:4048”]
I had some success using both Jekyll and Readthedocs. I can send dev links if you PM, they are obviously not for production yet.
[/quote]
I would be interested in your results there. Btw, there is a guide in German at readthedocs already: https://openhabdoc.readthedocs.org/de/latest/. I like this website/tool, but I am not sure if it is something one should be dependent on for the main documentation. I therefore rather prefer Jekyll with our own hosting of the generated documentation in the end.
I think you are missing my main point here: A person who proves that he knows about all relevant guidelines, the architecture and the legal issues does that by successfully reviewing the code of OTHERs and thus the other contributions are the ones who are good and can be trusted, once all review comments are incorporated. This person is then clearly a good maintainer and these are the people I am looking for. Nonetheless, his own code would still have lowest rank as long as no other maintainer reviewed it - the 4-eyes principle is imho very important.
Well, this adds a lot of additional work on the project - already running the UG involves a lot of efforts that are not directly related to moving the project forward, but which are purely administrative.
This is actually what we had planned for the UG, but the tax authorities are not really willing to go this way.
Anyhow, the problem that it isn’t scalable would remain. You cannot easily add members and re-assign the responsibilities among them.
Regarding “liability”: “e.V.” would be the right organizational format as it’s an legal entity on its own.
Regarding “non-profit”: this has to be defined in the charter and needs to be approve by the german tax authority.
So finding 7 people for the foundation of the “e.V.” shouldn’t be a problem?
I think most of the addons should be broken away from the main code base.
It seems that a Kodi type architecture would be well suited for openhab. Move the addons into their own repositories (perhaps with a few of the core ones remaining in the main repo), and let users add various addon repos to their runtime as they see fit. Some will take the plunge and use unmature addons, and others will stick only with what is stable. Each addon will develop its own quality reputation.
Additionally it would be great if there was a way to write addons in python instead of java. It would make basic development much easier, especially for newcomers.
If these two goals could be achieved it should take a ton of weight off the core developers as far as maintenance is concerned, and it should make addon development quicker and easier. Openhab could start growing much faster…
At the same time it will deteriorate the code quality and stop the growing of the openHAB code base as addons will be all over the place, but not part of the project. This is the risk that we have to balance against.
As the discussions are now rather mixing different topics here, I would like to close this topic and started 3 separate ones in its place - so feel free to follow up on these:
