avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject [RT] Purpose of Avalon
Date Wed, 10 Mar 2004 00:36:04 GMT

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 

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.


|   http://www.bali.ac         |
|  http://niclas.hedhman.org   |

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

View raw message