I have been lucky enough to be invited into the Avalon committer community on a similar timescale to yourself. Since arriving I have been honored to work amongst the excellent minds here. As I see it the community focuses on the brilliance of Avalon-Framework and its patterns. With that focus we are united. It is the goal that draws us all together. Where the community has differing interests is that we are maintaining multiple containers. Some like Phoenix & ECM have been in development for multiple years and have been used in anger over a similar timescale. Some like EOB are young and yet to be used by a single organisation anywhere near a live situation!! All our containers are different in goal, niche configuration and implementation. That is fine by me. I focus on the A-F commonality and am not upset that my Avalon buddies show little interest in EOB :-) I am unlikely to make any money from EOB as I've targeted the magic price point of zero, but then that characterises all of our containers (not withstanding the ultra-secret efforts of the lurkers to this list).
Anyway, I am happy with this community. I am happy that we all have good things to say about all of the containers even the one that we do not work on. I am happy that we hold all Avaloners in high esteem, all containers as worthy efforts. I'm happy that we agree that A-F is Jakarta's most important project (though we know that non-Avaloners take some convincing).
Where we differ dude, is on the assertion that the community needs to evolve. I believe it essentially does not. We also differ on sub projects <not> working together. I think there is plenty of synergy. There are tens of excalibur libraries used by other excalibur projects and avalon based containers.
I'd like to state a new problem we may well disagree on. I am deliberately brief here:
The more dissent we repeatedly post here, the more community mind share
we lose (regular developers & committers). I'd really prefer more high-esteem,
and less 'playground' comments.
Regards,
- Paul
PS - I'd also like to see more xdocs work, but as is typical with my experience with xdocs, developers cannot be convinced to work on them unless they are tied to their computers and make to listen to Janice Joplin for 72 hours continuously.
Hi Leo:
I read through your email and to be frank, I felt somewhat angry and sad all at the same time. I felt sad because what your wrote about is the "playground syndrome" that is so prevalent in Avalon. What I felt angry about is that it's not a passive syndrome, its an active syndrome.
I got involved in Avalon about two years ago. After figuring out all of the Avalon stuff I got to point where the "Avalon Concept" was having a real impact on my own development and the development of the people I was working with. During that first year my primary contribution to the Avalon Community was helping other people understand Avalon and Phoenix. One year later was voted in as a committer, armed and ready to contribute to the Avalon project with some important components.
What happened was that I was that I was assigned my own playground - avalon-apps/enterprise - lots of freedom to do what I wanted and no constraints. But what I wanted was to get involved in a real process about delivering real components that would deliver real value to Avalon "the Community". That never happened. When I joined up as a committer the last thing I wanted was to be shuffled of to a playground. What I wanted was the opportunity to leverage a bunch of people I really respected. I wanted to leverage ideas, beliefs, opinions - and through this process, enhance and improve not only the content that I committed, but also I to pay-back the confidence that the Avalon project had placed in me when they voting me into this community.
It's two years later and what is the impact outside of my delegated playground ... I've managed to push though the deprecation of the Component interface through the work on the service package (not a lot of code but a lot of effort to handle the volume of email at the time). It's something I really believe will enhance Avalon buy simply eliminating the Avalon lock-in (giving people more choice and more liberty gets more people engaged). I think this was an important contribution to the framework and a contribution reached through a solid engagement and participation of the community. I've also contributed to Avalon the Merlin story - something positioned somewhere between ECM and Phoenix. I look at this work as achieving two objectives - an expression of interest from myself in where I would like to see Avalon going in the future, and secondly, and concrete attempt to resolve the technical/community divide in Avalon that is reflected by the ECM/Phoenix split. Two cultures - two communities, that only serve to weaken the real potential of Avalon as the complete component solution.
Even today, with an order of magnitude increase in the market recognition of the value of component oriented programming, the hot press coming out of Avalon is the release of incompatible and divergent containers (Phoenix and Fortress). And yet, both address different concerns and could really incorporated in a single comprehensive solution. Why do these two different solutions exist? Why is it that they have not merged already? Why was Merlin even necessary? They exist because somewhere in the history of Avalon there was a fundamental split - Phoenix went down the direction of static component management, ECM went in the direction to dynamic component management - playground policies got their first foot in the door. And years later, their differences remain unresolved - and yet with only a few months work, Merlin 2 manages to bridge both abstractions. What's wrong with this story? The problem is the continuation, no! escalation of "playground principals" - principals that fly in the face of the needs and interests of our end-user.
Take Cocoon as an example - Cocoon is on the brink of engaging in a process of block based development and moving towards this from an ECM legacy position. Where is the "Avalon Project" solution.... block no longer exist in Phoenix - Fortress has no notion of blocks or anything close to block assembly. Is there something we need to be addressing relative to our end user priorities? Why aren't sub/sub projects working together - because territories have been marked out - unspoken rules that imply territorial restrictions.
Avalon is in my opinion the most important project in Apache. But I believe that Avalon is only as strong as its community. For the community to work together it must abandon playground policies and really engage in addressing the difficult issue of bringing all of this work together. If the Avalon community cannot do this the Avalon the Community has nothing to offer. If the Community has nothing to offer that Avalon has nothing to offer its users.
This community *must* be totally committed to its core and its own integrity. Any suggestion of the departmentalizing/separation of voting and commit privileges is simply reinforcing a cancer that will only lead to further fragmentation of interests. Avalon will only evolve if its community evolves. That means that every single member of this community must be given the real and tangible potential to contribute his or her best in every aspect of Avalon's evolution.
From this perspective I'm very strongly in support of Avalon "the community" taking up the challenge and leveraging the opportunities for real evolution offered by escalation to a top-level project.
Cheers, Steve.
Leo Simons wrote:
All,
following an interesting conversation between PD & Nicola on
general@commons (somewhere in messages 100-200) and also other threads
regarding voting on that list, I figured it might be a good idea to say
some things right here about the moral separation of voting and commit
priviledges @ avalon.
Avalon is a big project where not everyone knows all of the codebase or
works on it (sure as hell I don't know all of it :). Yet every avalon
committer has full access to all the cvs modules. This has many
advantages, like allowing everyone to do useful stuff like applying
patches, fixing language or adding docs.
However, informally, it is considered ill-practice here (I'd assume by
everone...) to participate in voting (other than lazy approval and/or
non-binding :) on pieces of code for which you are not a 'significant'
contributor/maintainer and for pieces of code for which you do not have
sufficient knowledge to make an informed decision.
Of course, 'significant' is something not so easily defined or perhaps
agreed upon when you have as informal a setup as we do (which might be
part of the problem behind our recent flamefests and yet one more reason
to eliminate scope creep and/or setup our own PMC - to be able to make
some things like this more formal); the 'informal' part also makes our
community work less transparantly (well, especially that this moral
guideline is also undocumented ;).
This is not to discourage anyone from participating in discussions where
they don't immediately see all sides of the story immediately or haven't
been involved with a piece of code before......on the contrary! That'd
be a disaster. I'm just voicing some more thoughts on voting behaviour
before heading to bed......if it all sounds silly just ignore me :)
weltrusten (g'night),
- Leo
--
To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@;jakarta.apache.org>
-- To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@;jakarta.apache.org>
