Let's admit it - having an additional plugin installed into your Moodle site is always a risk. One of the essential aspects (apart from the code quality itself) that potential plugin users have to consider is how well the plugin is being maintained. Does the maintainer release regular updates and bug fixes? Is the plugin updated every six months for the new Moodle major release? Is there a place to report bugs and feature requests? And when reported, are they reflected?
It's not that difficult to write a new Moodle plugin these days. Many students do that as a part of their school or thesis projects, for example. But can one rely on the author of plugin to provide sufficient (or at least some) support for it? To be a responsible maintainer of a plugin is much harder than to be an author of it. Many maintainers work on their plugins in their free time. And even if they are lucky enough to be paid for doing that, it's just time consuming (as everything). Unfortunately, I know this dark side of the truth personally. I am aware of all these feature requests for the Workshop, AMOS and other plugins I have written. And I know I will never be able to implement them all.
No matter how hard one tries to be a good maintainer of their code, the life seems to be driven by unpredictable algorithms. At certain moment, maintainers can realise they are not able to give enough love to their plugins any more. In the essay The Cathedral and the Bazaar, Eric Steven Raymond says "When you lose interest in a program, your last duty to it is to hand it off to a competent successor." And that is what Moodle plugins adoption programme is about. And by the way, Eric's essay is really excellent and if you mean it seriously with the open source development, you should read it.
So, the rules of the programme I am suggesting here are roughly like this:
- It's not a shame to give up of your plugin maintenance. You know that unmaintained plugin is worse than no plugin. You don't want to harm Moodle reputation just because your old code broke someone's site.
- If you decide to offer your plugin for adoption, let us know via a reply in this thread (preferred over a personal message or e-mail to make it all transparent). We will put your plugin into a special set in the Plugins directory so it is known and public that it happened.
- Once there is a volunteer who would like to take over the maintenance, please again reply to this thread. Note that it will help if the candidate proves their skills (via a reference or a patch for existing issue etc). So we all know the plugin is passed over to good hands.
- Finally, the successor is given the main maintainer role for the plugin with all the permissions (edit the plugin record, release new versions etc). The previous maintainer will be still listed as the original author in the directory. Note that the @author tag in the phpDocs block of a file should never be changed even after the whole file is rewritten eventually. It's GPL legal statement, not a credits line.
I believe this mechanism will allow to keep more plugins up-to-date and also give new developers a chance to join our growing community.