[Grok-dev] On CMS's in Grok

Fernando Correa Neto fcdoth at gmail.com
Tue Apr 1 22:17:25 EDT 2008


On Tue, Apr 1, 2008 at 6:27 PM, Martin Aspeli <optilude at gmx.net> wrote:
> 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.

Why not? I mean, trying to duplicate or gather what was done in other
CMS's or whatever system it is is *always* worth it. I think you would
get pissed if some Alfresco developer comes to you saying such things.

>  Or the corollary:
>   Don't try to compete with Plone.

Don't put it that way. I would try:
Try to achieve what Plone has achieved with less lines of code, more
componentized/reusable code. If the resulting software is easier to
use, maintain, scale AND it still delivers what Plone does, then we
have a good replacement for Plone using our favorite programming
But I understand the appeal. I'd get disappointed with people if I saw
they moving away from my favorite platform. It's quite natural.

>  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.

Off course it is huge and has tons of features. But I think we should
never underestimate what people can do. Quite often we see projects
that start based on lots of great different ideas. Take Ajax libraries
for example. Imagine if we were stuck with just one library. Heh, of
course there are also benefits for having just one way and standard
plattform for solving our problems.

>  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.

Right. But it still isn't a good argument to ask people not to
recreate/duplicate/advance the ideas of other CMS's did already. What
if during this journey they come up with something revolutionary?
Isn't it worth it?

>  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.

Not only that. I am really convinced that with Grok or whatever
convention over configuration framework, you can achieve better
results today. I am not throwing Plone away, it is just what happens
with software. If you don't keep up, people run away to other
platforms and recreate what you already did and add lots of other
features because the new approach allows them to do it easily.

>  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.

It's all about the buzz. If you create something that is killer, you
are going to surf that wave for some time until someone else starting
surfing bigger ones. People wants to be Allan or Limi or Vidar and I
think it is very good that people thinks that way because when it
happens, there is a good chance that better ideas will born.
If you want to build a CMS, just build it and let's see how it comes
up. Maybe you'll fail, maybe you wont. And if you don't fail, the
chances are good that some other frameworks will evolve and will use
the architecture and maybe this is the case of Plone ;).

>  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.

That's true. But the contrary is also true. Try to steal all the tools
Plone, Vudo, z3ext and Silva build over the time and make it better.
If you can ;).


More information about the Grok-dev mailing list