Shared Maintenance for Blender Extensions: Forks?
To prevent add-ons from becoming abandoned, it would be helpful if Extensions could grant access to other “trusted” contributors.
This popular add-on is a good example: it hasn’t been updated for almost a year and is now facing major compatibility issues with Blender 5+...someone even submitted a PR to address the problem.
Suggestion solution
If the idea is to respect the add-on's IP or something along those lines, maybe there could be a versioning system that allows for forks?
Contributors cold submit a fork/fix via this button:
Forks could then be available from a dropdown in the Version history tab?
6 Comments
If you already go through the effort of making a fork, nothing prevents you from submitting a new extension for it already. And from a clarity and UX standpoint, I personally think it would be best. How would it be in practice? You go on an extension's page or browse it from Blender, and when downloading, you would actually get something else?
Plus, I suspect a fork submission system would add more trouble to moderation than it's worth, especially if you want to avoid abuses. E.g. preventing AI slop forks or people adding their own stuff unilaterally to an active extension the OP didn't agree.
For the case of an extension being unmaintained for a while to the point that it is not usable in modern versions, I think a clever and simpler system would be an "unmaintained" flagging system:
give users a way to flag an extension as unmaintained or broken on Blender version x.y.z
moderators can check the latest updates dates and activity on source repo to confirm
if confirmed, moderators could to do either or both of these:
And let the mods set the latest release's max version to avoid issues for people. Maybe a form of visual tagging that clearly indicated an addon as unmaintained or archived can be useful too, like we have on Github when a repo is archived, or Alternativeto for discontinued softwares:
I would suspect the flagging could also have some automation too. If we know there were X new Blender versions with breaking API changes but the addon wasn't updated since 4.2, maybe that should automatically raise a flag, and prompt the author to make sure their addon is still functional and update their extension to either fix the bugs, or at least update the min and max version according to the current states. And if no answers: autoflag the mods.
I agree with your second point,it would be quite tricky for moderators. That being said, I disagree with your first point. Submitting a fork as a new extension could be confusing, as you’d end up seeing the same “Modifier List” twice in the search results. Maybe it’s more of a UI issue... perhaps duplicated add-ons could display a “Fork” tag, prevent users from installing them twice, and also display a link to the original add-on?
I updated my answer in the meantime.
I would assume a fork should try to not be exactly the same. It's already quite common practice in software development to do so, even if the difference in "branding" is small. Looking at all the Neofetch alternatives shows that: fastfetch, nerdfetch, screenfetch, winfetch, rxfetch, freshfesh, ...
Because even if you do a fork that is supposed to be 99% the same thing, you wand people to find it on search engines, you want to show clearly it's the "same but updated one" or the "same but with a cool twist", and a distinct name that people will remember as such absolutely helps to do both differentiation and association if needed.
Buuuut, if we do get the flagging system I mentionned above, it could help in case of multiple extensions with the same name since it would indicate any unmaintained one, and version locks would be there too.
(out of topic, btw have you seen this ? :D)
I do like that flagging idea yes!
I have, that's awesome, thanks a lot!