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