[Zope-CMF] Sneak preview - workflow

[Paul Everitt]

seb bacon wrote:
[snip]
> DC should do whatever they need to do to keep profitable.  If this
> means closing off some of the CMF code, then so be it.  I wouldn't
> want DC to struggle because of the Open Source decision, and I'm
> immensely grateful for what we've already been given.

I'll second Shane's thank you on this, it's much appreciated.  Of course
you're at the pub now, so my appreciation must await your return. :^)

> Having said that, however:
> 
> 1) DC committed themselves to OSS for a very good reason - essentially
>    the ones you outlined above.  DC opened up the previously closed
>    software, ZEO, for the same reasons.  Either those reasons still
>    stand and the original business model (consulting, etc) remains
>    sound, or the OSS experiment was a mistake.

Uhh, it doesn't have be that black-and-white.  There's other ways to
look at it, that I'll try and share in this exchange.

Namely, we have a platform/product strategy.  This is a fairly common
strategy in technology product management.  Without belaboring the
concepts, suffice it to say that our platform *must* be Open Source. 
It's likely that our products *should* be Open Source as well.  But the
distinction is illustrative.

There are some cases where certain things might not be appropriate for
Open Source.  First, face it -- it costs money to give things away for
free.  The zope-cmf email just before Shane's announcement bemoaned the
lack of documentation.  If something is of limited interest and we can't
justify the packaging, we likely won't throw it over the wall.  But we
might reuse it in a consulting engagement.

In other cases, there's a concept of an accessory, something not
required for the platform to be competitive.  But as Shane has noted,
we're of mixed opinion about this, and thus we've only made one stab at
it (ZEO).

On other cases, such as Zope Studio, it's basically a fact that DC is
unlikely to embark on such an enormous expense without recovering those
expenses.  But we're like to help someone else, whether they charge or
not.

The lesson to learn from this: have an unwavering commitment to a base
of Open Source, let a bunch of companies tinker around with other
approaches *atop* that base.

> 2) However, if DC sees add-on modules as part of consulting work, that
>    makes sense.

This certainly is the first step, at least for me.  There's stuff that
can exist as "consultingware" that avoids the packaging hassles.

>    Isn't Workflow part of the core, though?  It is core features like

I think workflow is core.  Here's the no-b.s. view on CMF and Open
Source.

There exists a conceptual "scorecard" for how CMS offerings get rated in
shootouts.  This "scorecard", though varying from one reviewer to
another, centers on a relatively consistent set of features and
services.

Our goal -- and you folks heard it hear first -- is to be the "Linux of
Content Management".  This means Open Source, it means community, it
means a bunch of companies making money in a bunch of ways.  Most
importantly, everything needed to compete on the basic CMS scorecard
should be available free and Open Source.

>    this which will encourage new users to embrace the CMF and help
>    develop it further, make it more stable, popular, and feature-rich,
>    and ultimately help DC sell 'modules'.
> 
> Thanks for opening up this question.  As long as DC keeps transparent
> its decision making process where these decisions effect the rest of the
> community, I'm happy, and I'll support whatever DC's conclusions may
> be (although I'd be very sad to see your latest work get closed off,
> and personally, I think it would be a mistake).

OK, then we'll avoid that mistake. :^)

> However, I'm a bit confused: could you explain how this is a new
> direction? In particular, what are the business requirements driving
> the recent flurry of CMF improvements?

See "Linux of Content Management".

--Paul