There should be a way for people to take over, or simply update extensions that are not being maintaned anymore (in case the original maintainer is unreachable for monthes after the extension is not compatible with the latest version of mozilla/firefox.thunderbird) I have an updated version of some extension that is not being maintained anymore. My update adds some functionality and makes it compatible with Firefox 1.0 I tried contacting the original author first so that he updates it on u.m.o but he seems not available (or maybe buzy /not interrested) I tried asking on IRC about what to do, but it seems there is no official way to do that.

Depending on the lisencing for the extension, you may be able to simply submit it as your own extension and give credit to the original author. If your extension is compatible with newer versions of firefox and the old one isn't, then people will download yours.

Cameron unfortunately it's not that simple! When i try to submit the modified extension i get "ERROR!! This extension does NOT belong to the author logged in. Terminating..." probably caused the UID is the same. I suppose one could just fork the project and chaneg the UID thus creating a different extension with similar code but it would not be the right thing to do ... users who install the new version just to get compatibility with the latest firefox would still have the old version installed and active but not working, because they are two different extensions now. In my case I just hosted the extension on a different server and I keep pointing the users who complain to the modified version. Maybe there is not much one can do but this bug is just to point to the problem especially when extensions are not compatible with the latest firefox versions. example of extension suffering from this bit rot is nuke anything, first compatibility issue with ff1.0 (when i filed this bug) now with ff1.03/1.04 just read the the user comments on u.m.o

(In reply to comment #2) > I suppose one could just fork the project and chaneg the UID thus creating a > different extension with similar code Sorry i wasn't more concise - this is what I meant. Rename it as "Patrick's Nuke Anything" or whatever. Add a note in the developer comments about uninstalling the original extension before installing yours and away you go.

(In reply to comment #3) > (In reply to comment #2) > > > I suppose one could just fork the project and chaneg the UID thus creating a > > different extension with similar code > > Sorry i wasn't more concise - this is what I meant. Rename it as "Patrick's Nuke > Anything" or whatever. Add a note in the developer comments about uninstalling > the original extension before installing yours and away you go. > Ya'll are making this far more compicated then it needs to be. Solution. Delete any extension that is incompatible with any insecure versions of Firefox (i.e. most all of them) if it's not been updated in months and the author doesn't respond....

*** Bug 331710 has been marked as a duplicate of this bug. ***

My current policy thinking is this: - authors should be able to delete their association with an extension - authors should be able to add other co-authors for their extension ? authors should maybe be able to remove other co-authors, though I suspect we should leave that in the admins' hands - extensions with no authors should be marked as "inactive", and indicated as such in the UI (possibly by just not showing anything in the listing except the "history" link?) ? when an author orphans an extension, he/she should maybe be able to say "someone else can adopt this extension" so that we can help match them with new authors I'll think about this a bit more, but I suspect the above is what we'll enshrine as policy pretty shortly, and then file bugs on implementing the changes required (including WONTFIXing 324671).

Note that bug 324671 has a committed fix, mostly following shaver's comments in comment 6. Will leave this open until policy is finalized, though.

AMO bugspam. Correcting QA contacts on OLD bugs (mozilla.update@update.bugs) -> Correct QA contact (policy@add-ons.bugs) Filtermeplzkthx

Here's what I've got in the draft I'm working on (about which more in bug 245198): "Creator responsiveness We expect that add-ons on AMO will be maintained to ensure compatibility with new stable/security releases (e.g. 1.5.0.5, for add-ons that are released for use with Firefox 1.5), and that add-on creators will respond appropriately to feedback regarding major issues (especially security and stability issues). Failure to respond to requests for fixes to significant issues, especially those related to security or application stability, may result in an add-on being removed from certain listings, having warning text added to the description, or having the add-on removed from the site altogether." I don't think that we are going to make a crisp policy for "how unresponsive" an author has to be before we flip the (upcoming) "inactive extension" bit. Human judgment will be required here, as in virtually all interesting cases.

In the majority of cases, the reason that an extension does not get updated is because the author looses interest in supporting it. Once an author looses interest, he/she would usually be happy to let someone else take over. With this in mind, extension authors could be given the option to agree to the following when they submit an extension: When their extension supports a version of Mozilla software, and a new version of that software is released, if the extension does not work properly for (three?) months after the release date AND no attempts are made by the extension author to update the extension or transfer ownership to anyone else, then the author grants AMO the authority to delegate control of the extension to someone else. If the author opts out of this agreement, then the above circumstances would result in the extension being delisted from AMO as described in comment #9.

(In reply to comment #9) > Here's what I've got in the draft I'm working on (about which more in bug > 245198): > > "Creator responsiveness > > We expect that add-ons on AMO will be maintained to ensure compatibility with > new stable/security releases (e.g. 1.5.0.5, for add-ons that are released for > use with Firefox 1.5), and that add-on creators will respond appropriately to > feedback regarding major issues (especially security and stability issues). > > Failure to respond to requests for fixes to significant issues, especially > those related to security or application stability, may result in an add-on > being removed from certain listings, having warning text added to the > description, or having the add-on removed from the site altogether." > > I don't think that we are going to make a crisp policy for "how unresponsive" > an author has to be before we flip the (upcoming) "inactive extension" bit. > Human judgment will be required here, as in virtually all interesting cases. > Whom would be responible for contacting the author. A number of them have no contact information publicaly listed on AMO.

(In reply to comment #11) > Whom would be responible for contacting the author. A number of them have no > contact information publicaly listed on AMO. > AMO Admins would be - we have access to the email address the developer signed up with, even if they choose not to make it public.

shaver, isn't remora beta already out, because the blocking‑remora‑beta? flag is still set.

Hi, having got (or had) a few extensions installed that are long-'abandoned', and having manually fixed them for my own use, I have a few thoughts: - 1) a user such as myself might be able to update the maxversion of an extension or fix a simple bug, and want to share the updated version of the extension with others on AMO but not want to take full 'ownership' of the entire extension and be the go-to person for future updates, bug-fixes, development, etc. Currently, that does not appear to be possible, and that is not good. (note: often seen solution: AMO users post their modified xpi to a free file host and post link to it in the original extension's AMO review comments section; while this works, it defeats the purpose and perceived 'safety' of AMO). - 2) If a user such as myself did do what was suggested in Comment #1 - and submitted my update/continuation of the extension as my own, various issues would occur as a direct result: a) users who'd had the old version installed would NOT be automatically notified that there is now an update (or am I wrong, would it, if I used the same ID?); b) there'd be no automatic notification on the original extension's AMO page that a newer, working version of the same extension was available elsewhere, and if I were to leave a comment as a 'review' on the original extension's AMO page, it might easily be buried by other user comments; c) the History and download stats accumulated by the original extension would be 'lost'.. they would not be transferred to the updated-extension's AMO page; d) title duplication might/would occur - leading to confusion.. case in point: 'URL Suffix' extension, has 2 entries by different authors + a 3rd version called 'URL Suffix - continued' : https://addons.mozilla.org/en-US/firefox/search/?q=suffix - 3) If an extension deemed 'abandoned' was simply deleted from AMO, as suggested by 'Scott' in Comment #4 - that would be most unfortunate, as someone else might have the same idea for the extension and do a search on AMO, not see anything resembling their idea (as it's now been deleted), and have to 're-invent the wheel', so to speak. There ARE good extensions out there that are for whatever reason abandoned, it's not just the '****' ones that go extinct. Perhaps the extension's original author got hit by a bus and died, perhaps they're on deployment in Iraq or Afghanistan, perhaps they're in jail for a year or 2, perhaps a lot of things -- point is deleting the extension from AMO unfairly punishes by the author and the Firefox community. A better solution is 'putting up the extension for adoption', ie: making it available for other contributors to continue, without negating the massive contribution of the original author. - 4) Although an extension author must choose a 'Licence Type' before submitting his/her extension to AMO, as far as I can tell, there is currently no way for a mere user like myself to see (on the AMO extension page, or elsewhere?) which licence type the author chose for any given extension. I looked, I did not see. Maybe I missed it, if so, it needs to be more prominent/discoverable. - 5) There is currently no automatic procedure in place for an extension to be identified as 'abandoned', and no way for AMO users to manually flag it as such. For that matter, the same I believe could be said about extensions that are no longer 'compatible' due to application updates. In both cases, this needs to change. Is there a way for AMO to read the 'maxversion' info from the extension xpi (or from info submitted manually by author at the time of extension upload) so that after a period of time following an application update, say 14 days of CurrentAppVersion > ExtensionMaxVersion, a notification can be automatically sent out to the extension author alerting them that their extension is no longer compatible and that they need to acknowledge this fact via reply, or their extension will become 'available to contributors' from a date perhaps as short as 2 weeks later. Interested parties could then update the extension on the current AMO page without the issues mentioned in my points #1 & #2, above. The same could be done for instances where the maxversion was set to a wildcard (ex: "3.*") so that if no extension update occurred for almost 1 year, a similar notice would be auto-sent to the author asking them to re-confirm their active involvement in the extension. If they don't reply by the 1-year deadline, the extension would be deemed 'abandoned' and become open to contributing developers. That's all for now.

> #1 & #2, above. The same could be done for instances where the maxversion was > set to a wildcard (ex: "3.*") so that if no extension update occurred for > almost 1 year, a similar notice would be auto-sent to the author asking them to > re-confirm their active involvement in the extension. If they don't reply by > the 1-year deadline, the extension would be deemed 'abandoned' and become open > to contributing developers. Also you have to be careful of certain situations where for example: 1. The author has abandoned AMO but not the extension, and has continued to update his extension on another website such as mozdev. 2. (Real case) Author was on active duty in (I think it was Afghanistan) was injured in a firefight and captured by insurgents, eventually rescued a year later, and then spent several more months in hospital before managing to get hold of a computer and connect to his extension website. Mozdev has an abandoned project takeover procedure developed and (after some unfortunate actual incidences[1]) updated/modified . Perhaps AMO could learn from Mozdevs mistakes. I think Brian King is on the Mozdev board. [1] Fortunately Mozdevs projects (including the project websites) are under version control so when the original author eventually turned up it was relatively easy to back rev all the files in the project back to their original state. Phil

Our policy regarding abandoned add-ons (as I see it): 1) Abandoned add-ons remain listed because they can still be useful to some people. We only take them down if there are any updates that are required for the add-on or its descriptions and the author is not responsive. 2) We *always* respect the original author's source code license. If there's no license, the assumption is that the code is copyrighted and should not be duplicated. 3) If an author wants to take over an abandoned add-on, these are the steps that should be followed: I) Try to contact the author through the information provided in the add-on page. II) If there's no luck, the author can contact amo-editors or amo-admins. We can try to contact the author with the additional information we have. III) If there's no luck, the only option is to make a new listing. And if the licensing doesn't allow to fork the add-on, the new author has no other choice but to rewrite it all. This may be worth posting in our policy section. I don't see any other steps that are necessary before closing this bug, so I think that's all we need to do.

We have a short version of that here: https://addons.mozilla.org/en-US/developers/docs/policies/maintenance#section-transfer We can add more detail to that section if needed.

Jorge, if more documentation is needed, please post the changes you'd like. If current docs are sufficient, please close the bug.

I believe the documentation is sufficient.

Verified per comment 20.