[Grok-dev] Re: maintaining the Grok website

[Sebastian Ware]

15 sep 2007 kl. 13.27 skrev Martin Aspeli:

> Sebastian Ware wrote:
>> I think it would be very valuable to have the website run on a  
>> Grok  based CMS. We desperately need show case applications. On  
>> the other  hand I can see the benefit of a mature CMS such as Plone.
>> However, being able to boast that we are so confident in our own   
>> technology that we even run the Grok website on a Grok based   
>> application is worth a lot to those evaluating it.
>
> *shrug* - I think you're overplaying this card. It may be a neat  
> thing to be able to say, but it's not going to be the clincher. All  
> kinds of lame PHP projects run their websites on PHP, that's not a  
> good reason to chose them. :)
>

Shrug or no shrug. I humbly suggest that you are a bit off the mark  
by comparing Grok to "any lame PHP project". Rather, consider if Zend- 
corp ran their site on .NET. I think that would really make some  
difference. Even if they ran it on PHP4 it would signal that they  
weren't 100% commited to the latest versions of their framework and  
engine.

>> It will also make  a great sample application :)
>
> But there are lots of other great examples you could build. :)

After you, sir ;)

>
>> Just keep an open mind on this one.
>
> All Grok CMS' are vapourware at this point. The need for a good  
> website is immediate and ongoing.
>
> Plone has been building a CMS for a long, long time. You get  
> support, stability and maturity. The plone.org use case is quite  
> similar to the grok.zope.org use case, and honestly we're only  
> really starting to be happy with the range of features we need at  
> this point (we really want plone.org to move to Plone 3 soon). It  
> may seem simple at first, but you'll find that you need more and  
> more. Does your CMS do versioning, for example? In-place staging?  
> That's a tough use case to get right.

Change history is good, but I don't see versioning or staging as an  
important feature for the Grok-website. What Grok really needs is a  
really lightweight solution that has a smart knowledge base/commented  
API kind of thing. So I am guessing that a lot of the benefits of  
Plone are overkill at this point.

Lets keep it simple :)

>
> If you have to maintain your own CMS "for the sake of it", you'll  
> take away time that you could've spent improving Grok or making  
> other, more impressive demos. I think there are lots of other types  
> of applications where Grok really can help you build best-of-breed  
> solutions - why compete with Plone head-on?

I doubt this would take away time from making other more impressive  
demos ;) I also don't think you should feel worried about a  
lightweight CMS based on Grok competing with Plone.

I would rather say that this could offer adopters of Grok a  
lightweight and easily customisable CMS with a fully functional back- 
end that could quickly get them up to speed with a certain type of  
project. This would lower the barrier of entry by an order of magnitude.

I don't know the status of the other CMS' based on Grok. I have sent  
my code to Luciano because I am confident that he will make a sane  
evaluation of what use it might have. :)

regards Sebastian

>
> Martin
>
> -- 
> Acquisition is a jealous mistress
>
> _______________________________________________
> Grok-dev mailing list
> Grok-dev at zope.org
> http://mail.zope.org/mailman/listinfo/grok-dev