incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew C. Oliver" <>
Subject Issues with XMLBeans proposal
Date Thu, 03 Jul 2003 15:57:25 GMT
In summary the most serious issues to this proposal are:

1. diversity of committership.  I'd personally like to see >51% of the
ACTIVE committership from a different company.  So long as a decision in one
company can MAKE the vote, you don't have an Apache project, you have a
corporate subproject at Apache.

2. Pick your project.  I think it would have been a lot less confusing to
mail the proposal to Jakarta or XML.  Personally, if this is a Java only
project, I think it should go to Jakarta.  If it is a mult-platform C a/o
C++ and Java, then it make sense for it to be part of XML.  The proposers
and sponsors should just decide and go in a single direction rather than
kicking off a big debate.

3. Duplication of effort.  The project encompasses schema validation which
is done my XML parsers and it is Yet Another XML->Java binding API (there
are some here and several elsewhere).  From the standpoint of something I'd
commit code to, this bores the crap out of me.  From the standpoint of
acceptability, its totally irrelevant.  Choice is good, competition and
cooperation exist not only in opensource but often in the same area of given
projects.  Thus if it can become an Apache community, then its irrelevant.

4. Machiavelli - I originally posted this to a private list because I didnĀ¹t
think it was good to say publicly, but rounding things out here might be
good.  Thus anointing BEA into the real open source and Apache world is a
motivation.  I don't think this project should be accepted without meeting
the basic qualifications because of that, but maybe its a motivation to be a
little more helpful than usual ;-).  It might also round out the power
structure at Apache a little if BEA began participating.

Suggested courses of action:

1. Immediately begin recruiting other interested folks to round out the
committership.  This should not exit the incubator until >51% of regular
voting committers are not from the same company.  (meaning no "show
committers" who never vote ;-) but round out the percentage)

2. Pick a project (XML or Jakarta) and say "would you accept this given it
is acceptable out of the incubator"

3. Steven should begin suffering the incubator and moving the bureaucratic

4. set up the mail lists

5. Work on Gump integration and source structure to match other projects.

6. Project should be a subcontext of incubator for the moment.  There are
far more issues that must be worked out and confusion between a potential
Apache project and an Apache project should be avoided.

I still feel a little bit like this should start on sourceforge, round out
the community issues, then move to incubator....


Andrew C. Oliver
Custom enhancements and Commercial Implementation for Jakarta POI
For Java and Excel, Got POI?

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message