[Grok-dev] On CMS's in Grok

[Martin Aspeli]

Hi all,

In light of recent summer of code projects, and the three or four CMS 
projects that have been mentioned off the back of that, I wanted to 
write something to the list for comment. I realise this may sound a 
little arrogant or presumtive, but it's not meant in that way at all. I 
just want to foster some debate and see what people think.

To start with a controversial statement:

  Don't build a Grok CMS.

Or the corollary:

  Don't try to compete with Plone.

So ... arrogance and ignore aside, what do I mean by this?

Plone is a bit of behemoth. It does a lot. It is based on many years of 
experience and thousands of man-hours of development. Getting a system 
that does everything (or most things) Plone does, which is stable, 
tested and has the right integration points is ... well, it's a huge 
project. Building a community around that and building a brand around it 
is even more daunting. We welcome the competition of course, I just 
don't want anyone to underestimate this task.

The usual argument here is that Plone is overkill for many tasks. That's 
true, and to a certain extent we'd be happy if we could point people at 
a lightweight solution we'd trust when it's clear that people are trying 
to use Plone for things it wasn't designed for. The problem with this, 
though, is that "light weight" really just means "has the features I 
want and no more, but also no less". No-one wants a lowest common 
denominator CMS, since more fully-featured systems will then seem more 
attractive. I often say that it's easier to turn something off in Plone 
than to turn it on in Zope. If you listen to those demands, you'll end 
up building the union of the features that everyone wants, which lands 
you back at Plone.

The Plone people are also really excited about Grok and want to use 
Grok-like concepts to build Plone systems. We also want to share 
components and services more openly with other Zope and Python projects 
- both to give components away (which is what the plone.* namespace is 
about) and to integrate things not invented by Plone.

Now, Grok is obviously a good fit for CMS and content-centric 
applications, largely due to the ZODB and publishing concepts inherited 
from Zope. Grok is also clean, nimble and easy to work with. I'm pretty 
sure that if I ever wanted to build a home-grown CMS or CMS-like system, 
I'd start with Grok.

I think this is where Grok's niche may have the strongest potential. 
Don't set about building another general purpose CMS. The open source 
world has a million of them. Build the tools and services that people 
who want to build their own CMS applications need - perhaps because they 
are so overwhelmed by the number of options in the market and want to 
control their own destiny rather than having to take a bet on an 
existing platform.

By all means, drive those requirements with a sensible, minimalistic 
example application. But don't focus your energies on the front-end 
polish or a wide range of "tick box" features. Focus them on building 
the on the decade or so of experience that this community has with 
building real-world content-centric solutions. Build the things you wish 
you'd had back then. Let grok be the caveman with the space age tools.

And then, we over in the Plone community can steal all your tools and 
use them to make Plone better. And so can Vudo. And z3ext. And Silva. 
And anyone else.

Cheers,
Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book