Hi Stefano: It's a really interesting read.
See notes in line. > -----Original Message----- > From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] > What you have been told is that the ASF board has lost trust in Mr. > Stephen McConnell's ability to handle disagreement in a way that brings > positive energy into a community instead of burning it down in flames of > friction. >From where you are coming from, one of the initiators of the original framework project, a strong proponent of Avalon, and ultimately a user of the results - I can completely justify the conclusions you have. Clearly, in your understanding, I have taken down a community that was here, cut away different products, rebuilt the development and user communities, and established something tangibly different. > This type of biased inferencing shows you precisely what I'm talking > about. > > The ASF cares about long-term stability of a project a lot more than > about short-term acquiring of newbies. Why? because once you depend on a > project, it's hard to go back, especially invasive frameworks like > Avalon's. When I look out across the Apache landscape there are many projects, each with their own personalities. What has struck me as significant is the dynamics of a one product community versus a community sustaining multiple competing products. If we look into the rule base on which the majority of Apache projects operate we find a structure which balances a focused community priority with evolution through consensus. Take for example the rules-for-revolutionaries - an example of the balance of product stability against the opposing interests of competitive and /or disruptive evolution - tempered by a community focused a single convergence point - the product. In my opinion it is this social contract that is the foundation for a properly functioning project. Cast you mind back a couple of years ... we have ECM (a product driven largely by Cocoon requirements), Fortress in the pipeline, Phoenix (nearing release), Merlin (in alpha), and containerkit in early development. We had identified the absence of common context keys as a framework issue but no agreement on a common solution due to inter-product conflicts, and collaboration on Merlin/Phoenix interoperability had halted due to similar reasons. End-user participation was minimal and the development community largely fragmented. Avalon was not a single community - it was simply a set of micro-communities sharing the same name. The absence of a single community results in a lower level of trust across the group for successful consensus based development - but a sufficient level of trust within micro-communities to enable a somewhat protective form product development. If we take another snapshot of the Avalon landscape a year later (one year ago) - things are steaming along by comparison. The fork of Phoenix outside of the ASF shifted attention here in Avalon towards the Merlin development effort. The development team was growing and community centers of interest moved from the fragmentation of the year before towards a new model of community polarization with the Merlin team on one end (working hard on products, pumping our releases, etc.) and the Excalibur/Fortress/ECM team on the other (working away with Cocoon on a new migration strategy). Looking again at the trust within the community what we seem to have is strong micro-communities brought about by reduced competition, leading to greater polarization and observable characterization as we see the emergence of group identities. > Ask around: there are several examples of these users that got "sucked > in" by the great PR skills In November last year Cocoon's migration plan stalled as a result of insufficient resources, trigging a role-back of development effort and a general rethink within the Cocoon community of its roadmap and community relations. On one hand ECM was deprecated, Fortress was not panning out as a viable strategy, triggering a rash of internal and external actions. Who got "sucked-in"? Well - it does not really matter if your sucking or blowing - the important point is that lack of community strong enough to step up and make the Cocoon scenario a success had a direct impact on the intercommunity trust model (which is another subject altogether). However, something good came of this - a decision by the Avalon community to consolidate on a single platform and a single community. Like most changes in life, that process was not without resistance. Following the community decision to consolidate and prior to the launching of Excalibur - the Avalon PMC was lighting up like a Christmas tree. However - as things turned out - that action ultimately led to the spinning off of the Excalibur project - and for the first time in the history of Avalon a single product community scenario was at hand. One could argue that the ducks were lining up nicely. > and were later damaged by their inability to prevent some others > to do incompatible changes without a constructive consensus-driven > approach. The true story is that it was basically the release of framework 4.2 which involved no actual signature or implementation modifications - but instead tied in with the introduction of constructor injection of lifecycle artifacts as part of the standard Avalon component model. But this triggered claims by members of the Excalibur project that the Avalon project was not managing its assets responsibly. Ok - so we didn't get the separation of assets right the first time round. What is more interesting was the style of reaction. The Excalibur team reacted much more aggressively and robustly than in the past. Could it be that a healthy community is simply greater than the sum of its parts? > The last example of this (and what started the last of the flame fests) > was Stephen's attempt to repaint Avalon with merlin colors and remove > the framework (its code and documentation) from a visible position. But what's one flame fest without a sequel? And just like most sequels - the story-line wasn't as good. BTW the only thing that changed was the documentation in a process involving lots of people here. Clearly the community issue was not solved - and the ultimate consequence of the re-run was the preparation of a proposal for a separate and independent project. Relative to the 'trust' model we actually have some interesting event and reactions. First of all we have LSD issuing a veto. But from the perspective of a community trust equation there were contradictions - LSD is part of Avalon but he's not part of the 'Avalon' team. Equally - your own attack carried with it a sense of your ownership and protection of the framework asset - but you're a not a part of the team unit. In effect the 'Avalon' community barriers were being breached. > Ask yourself: if the HTTPD 2.0 project wiped out the documentation of > the 1.3 branch because "considered obsolete" what kind of image would > that have given the foundation? it doesn't matter that 2.0 is soooooo > much cooler than 1.3 and the documentation is way better and more > professional. It does not matter for those who depened on 1.3 and have > no reason to upgrade (or such an upgrade is too expensive for them to > balance the banefits of 2.0) > > This is called "respect for your peers once they disagree on what you > say and they get hurt by your decisions". And this is a very weak argument! Moving on ... > Stephen has *repeatedly* shown how he favors friction-driven > escalation-type resolution-making processes rather than friendly, > respect and consensus-driven ones. May I suggest that your own more personal association with the framework combined with the recent less than successful migration experience may have left a bitter taste? Maybe you and I should co-author a book - "101 mistakes in open source"? Anyway - one thing is certain - when I look back over the last couple of years, I think I've learn a lot about the ways that communities react, community values, and the relationships between individuals and community. I've described a bunch of stuff related to trust in the test above and hinted at things that can weaken, damage, and even render a community non-functional. In conclusion - where is the Avalon team today in this trust model? Clearly a team needs to feel in control and masters of their own assets. I think this could have happened if the same approach were applied to the developers here as was applied to the Excalibur team. The remaining question is one of identity. Should the team start with a new identity around which it creates its own community as it sees fit - or should the team rebuild the Avalon identity? I think a new identity is in the best interests of everyone. Stephen. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
