2013-02-15, 05:18
We differ on interpretations of the "piracy" policy so some of my addons don't qualify. As for the remainder, the current setup doesn't make it very intuitive for the end user to tell the difference between the official repo and my private repo, so it's more fluid and user friendly to leave everything in my own repo.
The best solution I've come up to balance the differing points of view and user friendlyness is allowing private repos (but not necessarily the addons they contain) in the official repo. The pros:
1. Reduce the work load on team-xbmc (authors push their own updates)
2. Team-xbmc has a more direct approach available for indicating that addons are third party and not supported by the team (guaranteed to be shown with your preferred verbiage)
3. Adds a layer of separation between the foundation and any addons they disagree with, while removing a layer of ambiguity for the user. I liken this to the approach most linux distros have taken. They won't host certain packages for various reasons (copyright, ugly code, etc), but at the same time try to stay out of the way of users who are making a conscious choice to install and use those packages
The cons:
1. More users seeking support at xbmc.org, rather than fan sites. I count this as a con because there are some really strong fan sites out there with great communities, and I do think they would suffer from this. The increase in support requests would come from users who refused to read the information given, no matter how many alerts and popups we throw at them.
2. Still needs an implementation plan. For example, resolving conflicts from two different repos with the same script module version number but different code
Hope that provides some perspective and ideas
The best solution I've come up to balance the differing points of view and user friendlyness is allowing private repos (but not necessarily the addons they contain) in the official repo. The pros:
1. Reduce the work load on team-xbmc (authors push their own updates)
2. Team-xbmc has a more direct approach available for indicating that addons are third party and not supported by the team (guaranteed to be shown with your preferred verbiage)
3. Adds a layer of separation between the foundation and any addons they disagree with, while removing a layer of ambiguity for the user. I liken this to the approach most linux distros have taken. They won't host certain packages for various reasons (copyright, ugly code, etc), but at the same time try to stay out of the way of users who are making a conscious choice to install and use those packages
The cons:
1. More users seeking support at xbmc.org, rather than fan sites. I count this as a con because there are some really strong fan sites out there with great communities, and I do think they would suffer from this. The increase in support requests would come from users who refused to read the information given, no matter how many alerts and popups we throw at them.
2. Still needs an implementation plan. For example, resolving conflicts from two different repos with the same script module version number but different code
Hope that provides some perspective and ideas