New strategy for making plugins. This starts at the Make New Plugin page. See Client Type Modules
You fill out a form with basic info like the plugin name and what it does. You also describe what markup keywords will have special meaning and what data sources you consume and/or provide. Then press download to get your new plugin. Drag that to your plugin assets folder and you are operational. See About Map Plugin
You may have to say for which version of wiki you are making plugins. There could be many as we explore improvements in the plugin api. But no problem, if you change your mind you just choose a new version and press download again.
Your plugin will come with a pretty good About page. Remember those details you entered? This will be compressed into the plugin source code using the page shorthand we developed for the seran outpost. There will be standard stubs for the things your plugin actually does. These might even survive api version changes. Anyone thinking of changing the internal api can just regenerate a bunch of plugins and see if this reuse strategy works.
# Proliferation
I can foresee a proliferation of read-only sites offering read-write services though one-off plugins.
Say I created a database and wanted visitors to enter information using a read-only plugin with a read-write action. This plugin would only work when viewed with my site as origin. But the page upon which the plugin appeared could be forked into the federation where I would be soliciting participants. Other origins would not have the plugin (or the read-write database) but they could suggest interested parties open a new browser tab where they could complete the requested participation.