Niclas:
I have read this email several times. It's heavy, purposeful, direct and in my opinion a very good post. If I look for actionable semantics I can establish the following:
1. put in place a charter (refer Unifying Vision) 2. focus on single Avalon product 3. Transfer ECM to Cocoon 4. Deprecate Fortress 5. Evolve Merlin to support these new solid contracts 6. Bring MerlinDeveloper to market 7. component publishing infrastructure product
With respect to the first point (1). The Avalon charter is as defined by the Board under the motion taken to establish the PMC. This provisional charter establishes a scope of "component and service management". I think the conclusions within the Unifying Vision post provide a good framework/starting-point for a concrete charter.
The second point (2) is in my opinion *very* important to the subject of sustainable quality. Since the dawn time other initiative have chosen to compare themselves with Avalon and to asset Avalon compatibility. Looking ahead - a single Avalon product, defining the best, delivering concrete contracts, setting the standard for IoC. This is Avalon. This is why I joined. This is why I'll stay.
Item three (3) is an option that the Avalon project should present to the Cocoon project. ECM is after all already deprecated and no longer part of the Avalon landscape. If Cocoon accepts ECM - case closed. Otherwise its simply a case of zip it up and place it in the archives.
Item (4) concerns the deprecation of Fortress. I agree. However I think we should deal with this carefully and in consideration for existing users. The code base should be moved out of Avalon core CVS and into a deprecated group. If there is a requirement for ongoing maintenance we should enable that (or facilitate the migration of Fortress code out of Avalon as required).
Item (5) means solid focused work on - its non-trivial but we have a solid foundation to work on and the people to archive it.
Item (6) concerns bring MerlinDeveloper to market and here what is missing immediately is a work plan the synchronizes the current MerlinDeveloper platform with the Merlin 3.3. I.e. we need to synchronize the release of Merlin Developer and 3.3. development ASAP.
Item (7) is not familiar territory for Avalon but it's something close to my heart. This will change the landscape and Avalon will never look back. I think we should make sure that the Directory Project are in on the loop with respect to this subject.
Stephen.
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
--
|------------------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org/merlin | | http://dpml.net/merlin/distributions/latest | |------------------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
