[development] RFC: Candidate 'premium' modules

[Boris Mann]

On 15-May-06, at 5:30 PM, Karthik wrote:

> Premium modules are those that are:
>
> a) release-critical - A new version of Drupal cannot be released
> unless these are up-to-date.

Not going to happen. We *have* to decouple contrib from core,  
otherwise we create an expectation that that entire universe of  
modules will be carried along by us, the developers,  
automatically....a kind of tragedy of the commons, where the  
expectation will be set without necessarily any support.

If you DO want to have a release critical aspect, then make a  
distribution, as CivicSpace does.

> b) quality controlled - these will be 'core modules' in all but name.
> c) well maintained - HEAD, current release and previous release should
> all be maintained preferably by a number of maintainers.

This are not controlled in any way by the Drupal community. Pretty  
much, economic factors will determine this (I spoke about this at  
length with David Geilhufe of CivicSpace the other day). I think we  
can get there by each publicly supporting (code or financial) which  
modules we (as individuals, dev shops, consultants, etc.) believe to  
be critical and need to be of consistently high quality.

For what it's worth, here's what we're thinking for a "Drupal Base"
* core
* views
* viewfeed
* image
* img_assist
* tinymce

I think this is a useful discussion in getting peoples' views on  
modules (albeit somewhat non-development), so below are my notes on  
your list. -1 indicates I don't believe it's ready to be a premium  
module today, +1 indicates I think it should be a premium module.

> actions

-1. Evolving. Lots of interesting functionality, perhaps part of a  
higher end "big enterprise" set of use cases.

> casetracker

-1. Evolving, not quite there yet.

> cck

+1. More complex use cases. Don't necessarily want to overuse this in  
contrast to, e.g., page, blog, event, image.

> ecommerce

+1. Specific use cases. Good candidate for a Drupal Ecom install  
profile.

> event

+1. Needs refactoring -- turn it into a calendar "view" to display  
CCK and event-enabled content.

> flexi*

-1. I understand that lots of people have used this in the past. CCK  
is the clear path forward, I for one am uninterested

> i18n

+1. Should be headed towards core and/or a Drupal i18n install profile.

> image

+1. Move image.inc into core, have image.module be somewhat minimal.

> og

+1. It already is a premium module, modulo some of its recent very  
rapid development which has led to some instability.

> project

Neutral. I understand its supreme importance for drupal.org, I have  
seen little evidence of use outside of drupal.org.

> sections (when it is done)

-1. Has this ever had an official release? taxonomy_theme seems like  
a very good, robust solution here.

> subscription

Neutral. I'm still unhappy with what is happening here.

> trackback

-1. Can we say spam? Appropriate for a Drupal for Bloggers install  
profile.

> views

+1. Fast track for core for some components. It already is a premium  
module.

> voting api

Neutral. Good functionality