The Movable Type and Professional Network Wiki has been moved to wiki.movabletype.org.
Plugin Certification Whiteboard
Michael De Soto at 2006-09-22 01:19:20.
The following is (for now) to be used as a scratchpad and whiteboard for collecting requirements for a "Plugin Certification" program. This will help define criteria by which one could easily determine to what extend a plugin is supported by the MT platform.
Please contribute your ideas below.
From Byrne: I added the Bronze/Silver/Gold levels thinking that might be a good way of having tiers of certification.
Bronze Certification Requirements
- Distribition contains:
- a README file
- a LICENSE file
- Distribution conforms to documented/recommended directory/file structure
Silver Certification Requirements
- Works with all databases
Gold Certification Requirements
- Paid Level of Support and Certification?
- passes a security audit
- has been tested by Six Apart
- Six Apart download page lists compatible version numbers of Movable Type
Some things to think about
From Michael De Soto: Plugins should either be certified or not certified. Otherwise you risk adding to SA's workload to verify all the different tiers.
And what about companies that insist on only using "Gold" level products under the assumption that anything less is inheritly less secure? And if the plugin is less secure, do you want SA certifying it at any level?
My final thought would be to require certified plugins to work with all databases (and other criteria). SA shouldn't be putting their weight behind plugins that only work in some circumstances.
Su-- Including Oracle, or should that stand separately? I'd venture most developers will never get near an Oracle system to check this.
De Soto: True. Oracle is a specialized type of thing. I'm assuming that most plugins only make use of the API and that this isn't an issue. Am I wrong to assume that? Of course Extra Fields or Right Fields or whatever it's called is going to be a special case. Isn't this an outlier?
From Dan Wolfgang: I have to agree with Michael: certified or not certified. The confusion that comes along with different levels of certification is just too much--why should a user care if my plugin meets a higher level of certification? How do simple plugins fit into the mix--a plugin meets Bronze certification, and doesn't use a database, for example, such as for the Silver level. What level can I label it as? I vote certified, or not.
- README guidelines
- Include plugin name, author name, plugin URL, and documentation URL.
- Support contact information
- LICENSE
- ...examples? Links to licenses we can adopt? Creative Commons is all that pops into my head.
Su-- Let's clear something important up: Creative Commons licenses are not for software; they specifically make no mention of source code. There is one, which is nothing more than a wrapper around the GPL. That said, it will be important to point people to some explanation of their licensing options. There are a few places I've encountered that provide plain(er)-English explanations of licenses, though I can't dredge one up right this moment. One can be settled on as this progresses, though.
- ...examples? Links to licenses we can adopt? Creative Commons is all that pops into my head.
From Su: I think paid support should just be listed as a bonus feature if available rather than a certification requirement of any level. It doesn't seem to quite fit, not to mention that you(6A) backing it up like this would sort of make you responsible not only for having checked that the plugin works as advertised, but that the dev is living up to some promised level of service, which seems a bit much.
Appended to Dan's listing of a plugin URL above: An actual plugin URL(as in the cool ones that never change), not a blog post announcing the particular version of the plugin at the time that will never be updated when a new version is released.
From Skot: Some notion of forward portability would be nice to know (although perhaps impossible to predict.) It'd be nice to know how "API compliant" the plugin was, and therefore how likely it is to be incompatible with the next major revision of the core. The much missed TypeMover, for example, was well outside the API, so future compatibility was always a bit tenuous.
Michael De Soto at 2006-09-22 01:19:20.
