This is in a way related with the library project, and I'm asking you for
feedback. I'll not make a formal proposal until tomcat 3.3 is released, as
I don't want more distractions.
The problem:
In most projects, a lot of code (1/3...1/2 ? ) is "general" and not
specific to the main project goal. For example: logging, configuration,
i18n, string and file utils.
My itch:
Find a way to share the work of maintaining and developing this code among
projects ( which is very different from the library itch - which is
creating components that could be used by projects ).
In other words - my "driving" goal is not creating the components, but
finding ways for different projects to split the work ( and thus reducing
my work, and having more choices for the components I use).
The main benefit for jakarta will be that creating a common place where
projects can share will increase the exchanges between projects and
"mix" commiters - thus building a "jakarta-level" community.
My proposal:
Create a new CVS repository ( let's say "revolutionary" ), with a set of
rules tailored to solve the existing concerns. Tunning the rules and
creating a "special" place is (IMHO) the only way to get this colaboration
among projects.
Let's call this "agora" ( until we find a better name ).
1. All jakarta commiters will be commiters on this project.
Justification: I'm not proposing this for all projects - just for this
repository. I don't think it's right ( at this moment ) to extend this to
anything else, but it is essential for the success of the "agora" - we
want jakarta commiters to share work and use, everyone should know he is
part of this ( by default :-).
2. Any projects can create an "agora" component, by moving an existing
part and agreeing to those rules - no vote on agora is needed.
Justification: Agora is supposed to help projects share components ( both
work and use ). The decision to share should be taken by the source
project, and doesn't need to be "aproved" by any other entity.
3. By placing a component in the common repository, a project will get
more "eyeballs" and share the maintainance and development of the
component. In exchange, it will have to share decisions on the component
with other projects.
Justification: This is critical - this should reduce the concerns of
projects that want to reuse a component and are afraid the component will
change ( like it happened in the past so many times ). Since all projects
will share the control of the component - the evolution can happen ( if
all parties agree ) and incompatibities are minimized ( since all parties
have control ). Note that I'm talking only about the projects that are
actually using the component - and are affected by any change in the
component.
4. Duplication is good.
Justification: This will allow choice and reduce potential conflicts. If
development of a component becomes conflicting - spliting it will allow 2
more specialized components ( for different needs ) - which is good.
By having multiple solutions in the same place, the diferences will be
more visible and will allow better sharing of ideas and common interfaces.
That's it.
I think it's a win-win-win situation - the projects that decide to share
code will benefit by sharing work and getting more "eyes" for the
components, the projects that decide to use shared components will get
better code and choices, and the components themself will benefit because
more people will work on them and will be exposed to needs from other
projects.
In time, some components may mature and "graduate" into the library -
where the goal is to have "production-level" components. Agora should just
create a place for sharing - with focus on making the sharing work, while
the library can focus on components and code.
What do you think ?
Costin
