enough with all those [RT]s for a bit! Here's something concrete. Replies to the avalon development list only please.
Summary
-------
It has been said dozens of times now: we *badly* need a common repository for Avalon components. The thought that immediately follows: this repository should be part of Avalon. I strongly agree with the first statement; I strongly disagree with the second.
In this email, I explain why, then I resurrect the best alternative: *Avalonia*.
Explanation
-----------
The rationale behind a common component repository is obvious: there are lots of (open source) avalon(-compatible) components out there, and a single place for hosting/finding all of those means less infrastructure overhead, less googling, in other words, we get all the benefits of one-stop-shopping. It also means that a single community can be built around multiple components (much like jakarta commons) that would otherwise likely be single-man projects.
The rationale behind hosting such a repository here at Avalon is also obvious: there's already a community here, there's already some infrastructure here, and some components, and avalon is all about component-oriented programming. Hosting components here will also likely increase their visibility.
So why *should there not be an avalon-hosted component repository*?
1) Oversight. The Avalon PMC needs to be able to maintain (legal) oversight of the community and of our entire codebase. The bigger the codebase (especially: the bigger the number of small effectively-one-or-two-man codebases most of the PMC is not very familiar with), the more difficult this job is.
2) Brand dellution. Call everything "Avalon" and no-one will know what it means. We've already seen this happen so often! "What is Avalon, exactly? It seems to include <snip/>...BUT...<snip/>".
3) KISS. Do one thing, and do it well. Avalon is about a software framework. Not about everything that could possibly be built using that framework (avalon being a generic framework, you could implement half of the java class libraries using it). As an analogy, your Do-It-Yourself kit doesn't come with a house included, now does it?
4) Size. Already, since avalon is about lots of things, there are loads and loads of messages on avalon-dev; our website is huge, and roughly a third of all the binaries available on your average ASF mirror is produced by Avalon. The sheer energy required to keep up is huge; this is a big barrier to entry. The logical step in order to cope is to split up mailing lists, partition cvs priviledges, etc; this is disastrous to the community for various reasons (again, a lesson from experience), so its not an option.
5) Barrier to entry. There is a substantial barrier to obtaining access to an apache cvs, for various reasons (basically, its always a side effect of being a committer on a project, which includes several responsibilities and priviledges). We do not really need nor want such a barrier for a component repository.
6) Scope. Apache has a few component repositories already: jakarta-commons, apache-commons, xml-commons, ... It does not need another, especially not one that is a subproject of a project that previously had problems partially due to exceeding its original scope by far. A component repository does not fit our intended project scope.
The Obvious Alternative
-----------------------
There should be a *seperate project* for hosting avalon components. This removes objections 1-4. To remove objections 5 and 6, this project should not be an ASF-hosted project.
Concrete -------- So, what form would such an alternative take? Here's some basic ideas:
1) We create a sourceforge project 2) We name it:
Avalonia
--------
The one-stop shop for your Avalon component needs3) All avalon committers, contributors and interested third parties can get cvs access, without most of the barrier to entry that are intrinsic to the ASF.
4) Avalonia is run loosely ASF-style (consensus, +1/-1/0 voting, ASL license).
5) The Avalon PMC grants avalonia permission to use a slogan like the one above.
6) Avalonia gets a link from the front page of the avalon website.
7) Discussion of the project is, at first, on the avalon mailing lists (subjects prefixed with '[avalonia]'). When traffic ramps up, we create seperate lists on sourceforge.
8) existing external avalon-related projects like jadetower, keel, webtop, james, cocoon are all invited to participate (with an equal voice).
9) Avalonia forks avalon-components or gets a license grant; avalon-components is discontinued.
10) Avalonia not only hosts components, it will also host a component database linking to external components.
Proposal -------- The proposal is as follows: we create Avalonia.
(We don't need to agree on all those bullet points above immediately, but on the general idea.)
I'm willing to invest significant time, energy and computing resources to get this thing underway, but only if there's broad support and other people (both in the current avalon committer base and outside) who will commit to doing the same.
Now is the time to volunteer!
cheers,
- Leo
PS: for those that are wondering...yes, I did start writing this e-mail a month or two ago :D
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
