[theforum] weo 2b: to OSS or not?

Martin Paul Burns martin.burns at uk.ibm.com
Tue Nov 9 02:43:52 CST 2004

Dave wrote on 09/11/2004 03:07:10:

> Elfur Logadóttir wrote:
> > .:| Madhu Menon <webguru at vsnl.net> wrote:
> > .:| > The "start from scratch"
> > .:| > approach is not always a good one, especially if you're
> > .:| not going to involve the original developer(s).
> >
> > Is anyone really considering starting from scratch?
> > I'm not. I'm considering using drupal out of the box, with the
> > developed modules that can be downloaded from their website.
> Well, you are right.  If (but only if) Drupal or any other canned
> solution *meets* the requirements, and doesn't require extensive
> customizations, then absolutely that is a huge win.

Slight tweak: provided $tool meets *enough* of the (yes, as yet
undocumented) requirements, and provides a framework that evolters can work
within to meet the rest, that's good enough for me.

> Does Drupal offer user management features similar to what WEO does now?

Zope/CMF does. Don't know enough about Drupal, but would expect so.
(NB Plone is at heart a development of Zope/CMF)

> If not, would all evolt member have to re-register?  Can it support our
> current article workflow, which as I understand it, goes something like:
>     1. member-only submission
>     2. notifying content group of new submissions
>     3. restricting read access to content-users for review
>     4. allowing content group and original author only to revise
>     5. notifying content group of all revisions
>     6. allowing content group to approve and publish
>     7. notifying content group of new articles published

Zope/CMF does out of the box, with the exception of the notifications,
which a 10 line script will do. I've already written something almost

> I believe there are similar stories for newly submitted deo links

deo is out of scope (and PHP anyway)

> apparently complaint-comment messages posted to articles.

me, I could lose this for release 1.

> In the example scenario I made up above, for instance, the Content
> group, being volunteers, might just
> a) decide not to review anything since they will be expected to rewrite
> themselves any articles they feel need rewriting, with the result that a
> backlog of articles never gets reviewed and approved or

Largely, we do this already

> b) go ahead an approve articles that they really feel need revision
> because suggesting revisions mean more work for them, not the author,
> resulting in a lower standard of published articles on the site

Largely, for minor revisions (mostly HTML coding and wording tweaks), we do
it. For major ones, we tend to reject altogether.

Remember who the active content group are (in rough descending order of
* Chris Heilman
* Garrett
* Stef
* Joel
* William
* Jeff
* Me
* Madhu

I can't see us having a problem with there being enough willingness to work
with $tool.

> I think we have to port and run, because we have code that runs, that we
> can port, and provide the exact same features on the new server 90 days
> from now that users now enjoy on this server.

If we do that, I'll put money us *still* being on the interim solution in
12 months' time.

> I
> just doubt that any canned system is going to have the same features
> that have built into WEO, specifically to meet evolt's purposes.

Very few of the features we have are truly unique to evolt, beyond simple
configuration (eg exactly *what* the workflow stages/transitions are, as
opposed to support for a stages & transitions workflow). What we have now
*was* unique when it was 1st built - then, any half-way capable packaged
CMS cost you $100k - but is now commodity.

>  If it
> did, that would be quite a content management system (or quite a
> coincidence).  The fact is that most users of web-based CMS's are single
> users, using the CMS to manage small to medium size sites, possibly with
> features to support interactions with many anonymous visitors and some
> registered users.  This is how you are using it, right?  You like it
> because it meets *your* needs;  All software is custom software.  Drupal
> just happened to be customized for people like you.  Software gets
> developed to deliver the features that the majority of users want.

Plone was built specifically for larger scale, many user participation
sites - intranets particularly. I have a feeling that now Drupal has ACLs,
it's also pretty capable at that scale.

But generally, the processes for managing a multi-contributer site are very
similar for everywhere. Any CMS that addresses workflow, roles-based
security and (ideally) version control will be very well suited to our

> But having evolt admins as 100% it's users, the WEO backend code was
> developed to meet just the needs of evolt admins, and contains features
> that individual webmasters would never want (like notifying one user
> group plus one member of one kind of update, and fixing some bug where
> the admin group must be notified via a message to a mailing list, but
> the mailing list software bounces machine-generated notices because they
> look like spam, or some such.  Or bounces to that list need to be caught
> and resent or else no one knows about the article at all.

Mailing lists functionality is out of scope, and already handled by
mailman, not weo (including the UI).

> okay, you're right.  no one is suggesting rewriting the code from
> scratch.  Again, I just doubt that any off the shelf solution is going
> to meet the complex needs evolt appears to have.

Again, the primary needs evolt has are not at all complex or unique.

> Someone go make a list of everything WEO does, so we can cut it to only
> what it must do, and decide if Drupal does that... Drupal experts?  WEO
> admins?  Evangelists of all types?  Are there multiple levels of weo
> admin users?  I've heard the ominous term "godmin" bandied about... Is
> such a Deity Mode a must-have feature of evolt?

User management, essentially. Again, if $tool can't do it, it's not a
mature tool.


More information about the theforum mailing list