avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen McConnell" <mcconn...@apache.org>
Subject RE: [VOTE] Stephen McConnell as a committer
Date Wed, 29 Sep 2004 10:47:50 GMT

Hi Stefano:

It's a really interesting read.

See notes in line.

> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> 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
> positive energy into a community instead of burning it down in flames
> 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
> 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
> 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.  


To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message