Hello,
I was wondering a question that I think is interesting.
If a developer no longer maintains an integration and we want to take it over, how does that work?
Because if we copy it to another repo and publish it, 2 integrations will appear on the store 
Same question but if 2 people publish the same external integration?
Thanks
Excellent questions!
You can go take a look at the Jeedom market and youâll see that itâs a bit of a mess.
After that, there are community and paid options, so you often find several plugins for the same service, and I havenât seen any solution, things come and go without disappearing in the same place.
I donât know, maybe there needs to be an « analysis committee » for duplicate integrations or those that have bugs and arenât updated, but in any case, thereâs a real issue here.
Personally, I wouldnât be surprised if an integration thatâs not well maintained gets removed from the store (still active for people whoâve installed it, but not listed / not installable). Otherwise, itâs going to be a jungle!
This is one of the weaknesses of Open Source. It depends on the time and investment of the person maintaining the project. It is always possible to give « maintainer » rights to several trusted people, which limits the risks.
Exactly, shouldnât we give the rights now to @pierre-gilles or one or two other trusted people?
What do you think?
Very good question, and it comes at the right time, before the catalog grows too much 
What already exists today
An integration is not « registered » anywhere: the indexer runs every hour on public repositories that have the GitHub topic gladys-assistant-integration, reads the manifest, checks the Docker image, and publishes the catalog. Direct consequences:
docker_image to your own registry, adding the topic, and publishing. No permissions to ask anyone.On the resulting duplicate
Yes, we end up with two entries, and no, I donât plan to deduplicate. A store without reviews that refuses duplicates is a store with an arbitrator, and the arbitrator becomes a bottleneck again. The real lever is the signal, not the filter.
I first thought of a « not maintained for X months » badge, but upon reflection, itâs a false good idea. Many integrations are simply finished: a Tempo or Free Mobile integration may not move for a year because it works, plain and simple. Conversely, a cloud integration may break tomorrow because the provider changed its API, without a single commit. The last release date measures neither, and the only way to remove the badge would be to publish cosmetic versions. Bad incentive, and unfair to those who did the job well.
What really distinguishes « abandoned » from « finished » is responsiveness: a repository without commits for a year and without open issues is fine, a repository with issues unanswered for months is much less so.
So I would rather go with:
1 and 2 answer @prohandâs scenario quite cleanly, without needing a commission.
I think 2) can be implemented later, because for now the project is still too small for such a value to be a real signal for a user coming from HA for example.
On the « analysis commission »
I donât think thatâs the right answer. The day we judge the quality of othersâ integrations, we recreate the model we just left, with endless debates. The Docker sandbox is there so that it costs the user nothing to try, and a poorly made integration cannot destabilize their instance. The only exception in my eyes: a frankly malicious image. Yes, we can set up a blacklist the day it happens.
On giving me maintainer rights
Thanks for the trust, but no The whole point of external integrations was precisely to get me out of the critical path. Being a maintainer of 40 repositories I donât know would only be a new form of the same bottleneck, and a maintainer who doesnât merge anything protects no one.
On the other hand, real protection is upstream.
Add a second trusted maintainer from the start, before you need it 
In this case, for scenario 1, a « not maintained » or « archived » tag should appear to inform users that the integration repository is officially archived and to allow them to hide it in Gladys.
Okay for scenario 2 as well, this would allow us to see if an integration is still being used and working properly.
For the trusted maintainer to be added from the beginning, we need to be able to find them
What Iâm afraid of with all this is that weâll see several external integrations arrive on the store and it will quickly become a mess 
Precisely, the integration store is a marketplace, a bit like Amazon or Carrefour.
If several integrations do the same thing, itâs not a bug: itâs exactly the point of this architecture! 
There needs to be competition between integrations. Itâs a free market, and competition is a good thing for the consumer. Just like at Carrefour, you can have 5 different brands of tomato sauce in the same aisle: if tomorrow there are several integrations for the same brand or service, it will be a gain for the end user, not a problem.
However, itâs up to us to build a platform that is transparent enough for this competition to truly benefit users: number of installations, ratings, votes, quality of documentation, last update, etc. So much information that will make it easy to compare different integrations.
But I think we should not try to restrict the store. It must remain open, free and as diverse as possible. It is precisely this freedom that will allow the best integrations to naturally stand out.
Ok perfect thatâs ok for me with the explanations
Thanks
Can you exclude an integration if it poses a security risk or a problem for Gladys?
Anything is possible