cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ricardo Rocha" <rica...@apache.org>
Subject RE: [RT] Less is More, Finite State Machines and Balkanization
Date Sat, 12 Jul 2003 16:25:03 GMT
Antonio: I'm impressed me by your candor and sense of community. Your
comments are absolutely relevant.

It has taken me years to understand why and how open source is more
than just code and technology. I tended to think stricly in terms of
genericity, elegance, or economy of terms. The notion that <<bad code
and good ideas create communities>> was alien to me. Paraphrasing the
Matrix Architect, I found it unacceptable to release what appeared to
me as incomplete or imperfect code "for what was otherwise a harmony
of mathematical precision." Uff! Definitely, worse is better.

The "ugly, non-sense" discussions mentioned by Antonio are generally
characterized by over-focusing on technical arguments in disregard
for community goals. I dislike harsh language and irony, but in this
one case I agree with the "balkanization" part of this thread's title.
Should we make core abstractions pluggable just because it's possible,
even if it can confuse users and fragment the community? The Über-Avalon
syndrome? Definitely, less is more.


Ricardo


Antonio Gallardo wrote:
> 
> Sorry to include my "spoon" here, but I am feeling again that 
> this discussion is raising the level and will end in a ugly 
> no-sense discusion, that can have bad consecuencies for the 
> community. Maybe someone will be to angry that will decide to 
> go away again. I think we can discuss all of this more 
> friendly. I am not an older Cocoon community member but I 
> learned this rule:
> 
> 1-Does not interpret arguments against your proposal as an 
> attack to you. 2-Try to defend your proposal with direct arguments.
> 
> Remember, people always tend to hate and attack "changes", 
> this is part of any human being. Of couse many of us are 
> trying to be "open mind", but this is hard.
> 
> This remembered me a discusion about a little change I 
> suggested for the database block. In that discusion someone, 
> told me I dont know how to do database stuff! I know, I am 
> not the better database guy in the world, but I have working 
> in the database world more than 10 years. Well, I choiced not 
> answer this argument and continue with the discusion in the 
> correct way.
> 
> Now back to the things:
> 
> On one side I understand the Stefano concern of try to keep 
> the project in the correct line as he figured it. I know he 
> is the founder of the project and has a longer vision about 
> Cocoon than most of us. Please note this is the Stefano 
> position. His work is keep the project in the correct line.
> 
> Cocoon currently has many ways to reach the same goal. This 
> tend people to be confused and be concerned about the choice 
> they do and thought about what if "my choice" is not the good 
> one. If this is good or bad, please dont ask me. For both can 
> be good and bad arguments.
> 
> On the other side many of us is trying to give back to this 
> wonderful project some work back. We are trying to extend it 
> in the way we see it usefull for us and maybe for many other. 
> This is good too and Stefano know and support this.
> 
> I think the flow technology is not well defined or digested. 
> Still there can be others and better ways to follow. But 
> currently people is "crying" to have one full functional 
> solution of flow in Cocoon. After many discussion emerged one 
> of the proposals and we must end this implementation. If the 
> implementation of the picked proposal is not functional this 
> is always a step ahead for us. We will learned this is not 
> the correct path to follow. Please note I feel Flow is a key 
> innovation for Cocoon.
> 
> Please dont ask me what is the better path to follow in the 
> flow. If I know dont doubt I will tell you. I also know here 
> is better people that know more about flow than me.
> 
> My points are:
> 
> 1-Keep try the discusion friendly.
> 2-Lets end the current flow proposal and lets show if this is 
> the correct way. 3-There can be new proposal that can live in 
> the scratchpad, this is the way always averything started.
> 
> I hope this will be usefull.
> 
> Best Regards,
> 
> Antonio Gallardo.
> 
> P.S: Please does not bad interpret my english, I tried to be 
> the most respectfull that my poor english can allow to me.
> 
> 
> 
> 


Mime
View raw message