This thread is quite old but I didn’t find any newer one regarding this topic. I read your posts and understand the concerns of both sides.
First, I would like to add another major drawback of the current approach: As a user who is willing to experiment with addons that are under development and “living in the wild”, it’s just extremely hard to find them if they’re maintained in fork 645 of the openhab2-addons repository. In addition, there is no issue management available on GitHub for these kind of addons.
Coming back to the developer perspective, I think there should be a clear and fair path from how a developer should start with binding development to how he gets his addon into the officially maintained status. If the chances of the own addon of being taken over into the official repository are low (because of a small audience and limited maintainer resources), it’s not a good approach to mislead the developer to the (in my opinion awful) approach of using a fork (where there is no possibility of tracking issues etc.) and let him wait until the cows come home. In addition, if his addon maybe gets more popular later on, there should be be a good way of handing it over to the officially maintained repo.
I would like to bring two ideas up for discussion. I think they’re less invasive as the approaches previously discussed and take the requirements of all three stakeholder types (user, addon developer, maintainer) into consideration:
It would be good to have a best practice documentation for “not so important” addons that have low chances of ever being reviewed and taken over by a maintainer. Or also for addons that cannot be maintained in the official repository because of licensing concerns. Cherry on the cake would be to have clear criteria which addons are “important” and which not.
A good approach for addons “living in the wild” in my opionion: Seperate repository with nightly Travis builds to check whether they’re incompatible API changes. Example:
Regarding the repository structure I have the following idea: Carving every “officially maintained” addon to a seperate repository owned by the OpenHab project (like openhab/milight-binding). To keep them maintainable within the existing Maven structure and the current CI approach, the openhab2-addons repo could include them as Git submodules.
This approach would have several advantages in my opinion:
First, this would enable the project to nominate addon-specific maintainers which are known of having a good API understanding and being able to produce good-quality source code. I think there are quite talented maintainers out there who just do not have the time to take responsibility of the overall project.
Second, this would enable the possibility to manage addon-specific issues and PRs seperately (very important in my opinion, currently it’s just a mess!).
Third, it would make it possible for addon developers to start with a seperate repository which can be handed over to the OpenHab project later on (by using the “Transfer ownership” functionality and adding it as a submodule to openhab2-addons).
Last but not least I think the overhead for maintainers would be minimized (compared to the current approach on refactorings e.g. just the “git submodule foreach” would have to be prepended to the Git commands that are currently used and having a complete checkout is quite easy).