You really have some good points I totally agree with, especially the fact, that Cocoon, Turbine and James are not Avalon's only users and that they are not more important than any other users. Absolutely right.
As I stated, it's up to you guys to define the future of Avalon. Just one question out of personal curiosity: You speak about transfering ECM to Cocoon and dropping Fortress. *If* (just hypothetical) we at Cocoon would decide to continue with Fortress instead of ECM would you consider (also) transfering Fortress to Cocoon? Carsten Niclas Hedhman wrote: > > This Random Thought is trying to touch on the Purpose of > Avalon, as I believe that there is a large chasm regarding > this subject, and that the view of active developers may not > be the view of our users, current and future. > > ***** Avalon - The Apache Server Framework ***** > > Bold statement indeed, but apparently not bold enough, as > Avalon has outgrown this statement, and some say it should > now fit inside anything from an credit card to an airline > booking system (exaggeration intended) and preferably without > any differentiation of codebase. It should be tweakable to > fit inside any other technology out there, without any > demands placed on that technology, and ohh..., throw in some > GUI applications as well. > > This has gone completely out of proportions. Face it, what is > the bottom line purpose of Avalon or ANY other OSS project; > > ***** To serve our users ***** > > and not to serve our egos, or the academic research paper on > ultimate scalability that will earn my doctor's degree. > > - o - o - So what are our Users' needs?? - o - o - > > Well, to answer that question, we need to look at WHO is our users? > > Traditionally, we have always turned to Cocoon, Turbine and > James, but are they truly the real users, and are they really > the main beneficiary of Avalon. > > If the answer to this is YES, then the future direction of > Avalon is very simple, shut down Merlin and Fortress, and > continue to evolve ECM and Phoenix. As Mr Sutic explains > "migrating to Merlin would not translate into a single $ for > me" and conclude that migrating away from ECM for Cocoon > doesn't solve anything per se, only a hope that the next > container will come up with something better for them in the long run. > > - o - o - Are our users Cocoon, Turbine and James??? - o - o - > > I think NO, they are part of our user base, but they are not > even the main beneficiary of Avalon technology. > > - o - o - How can that be? - o - o - > > Projects like these three are large, independent and > basically don't have any commercial constraints. There is > very little **re-use** involved !! > > Face it! The real beneficiaries are all those developers out > there, who crank out 2-5 applications a year, often within > the same problem domain, for different customers. All are > slightly different, but the bulk is **re-use**. > The developers who currently use copy-paste to move from > project to project, are the ones who can really get a > performance boost out of COP, NOT the large monolithic > product developers. > > > Stephen mentioned to me something in the region of a 1000 > downloads of Merlin a day. If that is true, it is a shame we > don't manage to attract many of them to stay on (which can be > seen on user@ if anyone reads it). I think the reasons are; > > 1. "Which container?" > 2. Too few components. > 3. No documentation of the components that do exist. > 4. It is unclear what the benefits for the corporate > developer are, when hitting the official website. > 5. We are not "political correct". > > > - o - o - The Way Forward - o - o - > > Avalon and its community have a lot of choice, and need to > make decisive > action, or it will become a dead project and laughing stock > of the ASF. > > * Absorb a Unifying Vision (see separate post later). > > * Drop the concentration on container toolkit, support of IoC > types, and > similar academic issues. Those interested in these exercises > can and already > do this outside this community, which is fine, but let's not > get divided over > things that doesn't matter to our emerging users. > > * Declare Merlin * The Apache Server Framework *, and create > easy access to > the 2-4 common usecases that really exists, not constructed > ones to prove > versatility for the academic sake. Transfer ECM to Cocoon. Deprecate > Fortress, or those who are interested bring it elsewhere. > > * Focus on component contracts and patterns, which will help > the corporate > developer and reusability at large. Flexibility is not > performance improving, > and please search the Cocoon mail archive for the word "Flexibility > Syndrome". I want to solve real problems for real people ! > > * Evolve Merlin to support these new solid contracts. > > * Bring MerlinDeveloper to market for rapid prototyping solutions. > > * Bring a component publishing infrastructure product into > existence, to > simplify the component publishing for non-ASF committers. > > > - o - o - Conclusion - o - o - > > Avalon needs to get a momentum forward, and I will produce > the Unifying Vision > in a separate post. Stalemate and in-fighting brings us nowhere. > Avalon has, like Cortez, sailed a long way and there is a > jungle of obstacles > in front. Burn the ships!!! Move forward, there is no going > back. Those who > want to peddle around with petty things, stay on the beach > and pamper ECM, > Phoenix and Fortress. The rest of us, who want to conquer new > land, will > forge ahead for fame and fortune (God, King and Country if > you prefer :o) ). > > Staying on the beach will lead to death in obscurity, without > anyone caring > about it. > > > Niclas > > -- > +---------//-------------------+ > | http://www.bali.ac | > | http://niclas.hedhman.org | > +------//----------------------+ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
