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.
