[RT] Allowing for controlled evolution

[Berin Loritsch <bl...@apache.org>]

This RT is Inspired by Stefano's post, but without references to Avalon,
flow, or other hotly debated topics.  The goal here is to hone in on the real
requirements of community dynamics while allowing Cocoon to metamorphose into
a butterfly.

It appears that the Cocoon community has a little bit of friction, though not
at combustion level yet.  We need to address that before it escalates.
Community dynamics is the most important part of an open source project, because
with increased infighting and competition for attention there is a directly
proportional increase in the likelihood of forking and community split.  We
want to avoid that at all costs.

I would take the comments from myself, Leo(s), and Nicola on this subject very
seriously.  We have learned a few things about it.


COMMUNITY IS PARAMOUNT
----------------------

Community consensus for the core parts of what gives Cocoon its identity is
very important.  Not everyone comes from the same corner of the world--which
is a great strength and an achiles heel.  The key solution to this challenge
is to extend respect to others first, and assume the best.  If things are
worded in a caustic manner, or someone seems a little "dense", have patience
because they are probably working through communication issues.  Long term
patterns in behavior are more telling than short term mistakes.

Identify your identity.  What makes Cocoon what it is?  Work toward solidifying
that and protecting that.  Just do it nicely.


TECHNOLOGY MUST EVOLVE
----------------------

Most people site the "Rules for Revolutionaries" (no link for you, sorry) as
justification for declarying a "fork" or exploring wildly different ways of
achieving the same goal.  The problem is that forking and revolution is only
acceptable in very small quantities.  Too much revolution provides for the
high mutation rate that Stefano mentioned in his other thread.

So how do we allow for new ideas without killing the community and project
at the same time?

The solution I have found to work is to identify up to three alternatives for
the same problem.  Remember Leo's goal/position post?  You will find that
certain ideas will resonate immediately because they are not radically different
from anything most people have dealt with to date.  You will find that other
ideas will catch on after time.  Lastly, you will find that the remainder of
ideas will die on the vine.

Why three alternatives and not more/less?  Typically because three alternatives
provide the following qualities:

* There is a real need for a proper abstraction.  As the alternatives evolve,
   so will the abstraction.  That is a good thing until you release.

* It provides enough variance while allowing for the community to still remain
   informed about the different ways of doing things.

* It allows you to find what the real problem areas and strengths are for the
   implementation.  Some ideas are great on paper, but lose alot in the
   translation.

* When the time comes, the community can remain informed enough to make the
   decision for one implementation to be the "blessed" one, or to merge the
   different approaches into one.


IDEAS MUST ABOUND
-----------------

As soon as ideas stop comming, the project dies.  If there is no where to go
with the technology then there is nothing to do, and interest leaves along
with the users and developers.

Always consider alternative views even when you don't understand them.
Different styles of programming allow for elegant solutions to problems you
may not of thought of.  For example, it was once thought that physical disk
location of files was good enough for mapping the URI space.  Life proved that
URIs last longer than information, and the URI contract is truly important.
As a result there were relocation protocols incorporated into HTTP servers,
and many servers provided ways of mapping the URI space to the actual pages
served.

Different programming paradigms/patterns/languages allow for different sets
of solutions that were not practically possible otherwise.  For example, the
difference between procedural and object oriented programming allowed for
developers to look at the problem space from a different viewpoint.  The
difference between declarative programming (rule-based programming) and
functional programming (think procedural and OO) allows the developer to
attack a different set of problems more easily.

Respect the idea, and the idea presenter.  You might learn something.  Even
if you don't, you will learn about new ways that Cocoon may be used that you
haven't thought of before.  When you see the final product you might finally
"get it".  Continuations are something that unless you use are difficult to
grasp.  That is why it took a while to come to fruition.  Now that we have
it, many people can't imagine how they would live without it.  Other ideas
will be like that.


-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin

Re: [RT] Allowing for controlled evolution

[Stefano Mazzocchi <st...@apache.org>]

Please allow me to give some comments.

On Monday, Jul 14, 2003, at 16:10 America/Guayaquil, Berin Loritsch 
wrote:

> This RT is Inspired by Stefano's post, but without references to 
> Avalon,
> flow, or other hotly debated topics.  The goal here is to hone in on 
> the real
> requirements of community dynamics while allowing Cocoon to 
> metamorphose into
> a butterfly.
>
> It appears that the Cocoon community has a little bit of friction, 
> though not
> at combustion level yet.

I don't percieve this.

There has been disagreement (and this is natural and healthy) and this 
turned into frustration for a few people (sorted out and resolved with 
prompt apologies) due to lack of understanding and the general 
distortion that email enforces on the communication channel, expecially 
for people with different levels of english fluency.

There has been even more friction in the past, but it has been resolved 
and also improved the relationship of the people involved.

Having said this, I strongly believe in the healthy nature of shaking 
the community a little. It makes otherwise silent people speak up and 
it shows the real personal intentions.

> We need to address that before it escalates.

Dude, little earthquakes are natural as air. And healthy. Big 
earthquakes happen when the earth energy is dissipated all at once. 
When you have small continous earthquakes, the same energy is 
distributed over a longer period of time and it's much less disruptive.

yeah, you'll note that I'm more or less the origin of all the little 
community earthquakes.

the unintentionality of this is left to be determined by the reader ;-)

> Community dynamics is the most important part of an open source 
> project,

absolutely

> because
> with increased infighting and competition for attention there is a 
> directly
> proportional increase in the likelihood of forking and community split.

I disagree. see above for the reason.

> We want to avoid that at all costs.

Again. I disagree. I think that one of avalon problems is that people 
avoided the fight for a long time until the friction was too big. Big 
earthquake against small earthquakes.

> I would take the comments from myself, Leo(s), and Nicola on this 
> subject very seriously.  We have learned a few things about it.

>
> COMMUNITY IS PARAMOUNT
> ----------------------
>
> Community consensus for the core parts of what gives Cocoon its 
> identity is
> very important.  Not everyone comes from the same corner of the 
> world--which
> is a great strength and an achiles heel.  The key solution to this 
> challenge
> is to extend respect to others first, and assume the best.  If things 
> are
> worded in a caustic manner, or someone seems a little "dense", have 
> patience
> because they are probably working through communication issues.  Long 
> term
> patterns in behavior are more telling than short term mistakes.

absolutely.

>
> Identify your identity.  What makes Cocoon what it is?  Work toward 
> solidifying
> that and protecting that.  Just do it nicely.

good suggestions.

> TECHNOLOGY MUST EVOLVE
> ----------------------
>
> Most people site the "Rules for Revolutionaries" (no link for you, 
> sorry)

http://incubator.apache.org/rules-for-revolutionaries.html

>  as
> justification for declarying a "fork" or exploring wildly different 
> ways of
> achieving the same goal.  The problem is that forking and revolution 
> is only
> acceptable in very small quantities.  Too much revolution provides for 
> the
> high mutation rate that Stefano mentioned in his other thread.
>
> So how do we allow for new ideas without killing the community and 
> project
> at the same time?
>
> The solution I have found to work is to identify up to three 
> alternatives for
> the same problem.  Remember Leo's goal/position post?  You will find 
> that
> certain ideas will resonate immediately because they are not radically 
> different
> from anything most people have dealt with to date.  You will find that 
> other
> ideas will catch on after time.  Lastly, you will find that the 
> remainder of
> ideas will die on the vine.
>
> Why three alternatives and not more/less?  Typically because three 
> alternatives
> provide the following qualities:
>
> * There is a real need for a proper abstraction.  As the alternatives 
> evolve,
>   so will the abstraction.  That is a good thing until you release.
>
> * It provides enough variance while allowing for the community to 
> still remain
>   informed about the different ways of doing things.
>
> * It allows you to find what the real problem areas and strengths are 
> for the
>   implementation.  Some ideas are great on paper, but lose alot in the
>   translation.
>
> * When the time comes, the community can remain informed enough to 
> make the
>   decision for one implementation to be the "blessed" one, or to merge 
> the
>   different approaches into one.

This is a good suggestion, even if I'm not sure that a guideline is 
really what we need. More than anything, we need awareness of the 
problem that an implementation of a particular abstraction without the 
proper community diversity to back it up is potentially very dangerous.
>
> IDEAS MUST ABOUND
> -----------------
>
> As soon as ideas stop comming, the project dies.  If there is no where 
> to go
> with the technology then there is nothing to do, and interest leaves 
> along
> with the users and developers.
>
> Always consider alternative views even when you don't understand them.
> Different styles of programming allow for elegant solutions to 
> problems you
> may not of thought of.  For example, it was once thought that physical 
> disk
> location of files was good enough for mapping the URI space.  Life 
> proved that
> URIs last longer than information, and the URI contract is truly 
> important.
> As a result there were relocation protocols incorporated into HTTP 
> servers,
> and many servers provided ways of mapping the URI space to the actual 
> pages
> served.
>
> Different programming paradigms/patterns/languages allow for different 
> sets
> of solutions that were not practically possible otherwise.  For 
> example, the
> difference between procedural and object oriented programming allowed 
> for
> developers to look at the problem space from a different viewpoint.  
> The
> difference between declarative programming (rule-based programming) and
> functional programming (think procedural and OO) allows the developer 
> to
> attack a different set of problems more easily.
>
> Respect the idea, and the idea presenter.  You might learn something.  
> Even
> if you don't, you will learn about new ways that Cocoon may be used 
> that you
> haven't thought of before.  When you see the final product you might 
> finally
> "get it".  Continuations are something that unless you use are 
> difficult to
> grasp.  That is why it took a while to come to fruition.  Now that we 
> have
> it, many people can't imagine how they would live without it.  Other 
> ideas
> will be like that.

I totally agree.

Thanks for sharing your thoughts.

--
Stefano.