[Grok-dev] Re: maintaining the Grok website

[Martin Aspeli]

Sebastian Ware wrote:

>> The pragmatic question here should be, what system gives us the  
>> best tools for meeting our web-site building needs. And "best" here  
>> must include some notion of support, maintainability, and proven  
>> stability.
> 
> I agree in most. But then again, proven stability is kind of saying  
> that anything that hasn't been around for a while is out of the  
> question. So anything based on Grok would be disqualified out the box.

That's a bit of a circular argument, though. :-)

> I have personally designed and been involved in one of the most  
> extensive scalability test performed on the .NET platform. The  
> purpose was to evaluate how well object-relational mapping scaled. I  
> agree with your concern, but the scalability and stability issue is  
> on the table for every Grok app out there. If we have to look into  
> this, there is an opportunity to learn more before the adopters are  
> stuck with the problems. This is both good and bad.

Yes, true, but one of the things we learned from Plone was that having 
plone.org also be the developer's test bed was a really bad idea. When 
plone.org dies, we look bad. If it has endemic stability issues, we look 
really bad. Once we stopped doing live migrations on plone.org and 
hoping for the best, we ended up doing a lot better.

>>> 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 :)
>> It's not simple to maintain something yourself. I guarantee you  
>> that you're going to need or want more features that you initially  
>> foresee. You're going to end up re-inventing things that are  
>> already in Plone. I don't buy that it's "overkill". That word has  
>> lots of negative connotations. It's true that you may not need  
>> every feature of Plone, but that doesn't mean it's not well suited.
> 
> I agree. But I am bit more into the agile idea of "lets cross that  
> bridge when we reach it".
> 
>> Also, Plone has spent a lot (!) of time on usability. Even if most  
>> people here could put up with something that wasn't very end-user  
>> focused, they're still going to be more productive if they have  
>> tools that are easy to use. Getting solid, good usability takes  
>> time. I haven't seen your CMS, so I can't comment on it, but I know  
>> that I've never seen a brand new system, written by a single  
>> developer, that got the usability right on the first attempt.
> 
> I know what you mean. Seeing is believing. I agree with that 100%.  
> I'll rest my case when Luciano says what I sent him sucks... :)

Please don't take this the wrong way (I realise there are probably other 
pressures), but I actually find your approach here a little 
disappointing. I'm glad you're sharing, but it's clearly not open at 
this point. All we have is your word that this is even a feasible 
product. That's not a problem per-se, and I realise you're willing to 
open source it, but the problem is that either you have to be solely 
responsible for maintaining it (which I doubt you have the capacity to 
do, regardless of your intentions, which I know are good), or you have 
to let the community own it. For the community to own it, they need to 
shape it, not just have the code dumped in their laps. Starting out open 
and growing in an open way usually leads to better results than starting 
out closed and relicensing once the big decisions have all been made.

> I think you should keep thinking about the Plone solution. If my (or  
> another lightweight Grok based CMS) turns out to be up to scratch  
> within the next week or two I think it should be given a fair shot,  
> but otherwise I don't have any personal objection to idea of using  
> Plone 3.

Sounds like we agree more than than we let on. ;-)

Martin

-- 
Acquisition is a jealous mistress