Issues with XMLBeans proposal

["Andrew C. Oliver" <ac...@apache.org>]

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
wheels.

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....

Thoughts?

-Andy
-- 
Andrew C. Oliver
http://www.superlinksoftware.com/poi.jsp
Custom enhancements and Commercial Implementation for Jakarta POI

http://jakarta.apache.org/poi
For Java and Excel, Got POI?


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Issues with XMLBeans proposal

[Santiago Gala <sg...@hisitech.com>]

Craig R. McClanahan escribió:
> Snipping to an issue I have with one particular comment.

I snip the whole thing, just to add. Read Craig's mail if you haven't :-)

The Apache voting rules, where one -1 vetoes (and at the same time it is 
required to give substantial arguments about the veto) is, I think, 
precisely designed to enhance dialog and consensus over pure majority.

I think this fact does a lot towards avoiding this kind of control traps 
and hidden agendas. This and the public discussions on the rationale of 
decisions.

Regards
-- 
Santiago Gala
High Sierra Technology, S.L. (http://hisitech.com)
http://memojo.com?page=SantiagoGalaBlog



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org

Re: Issues with XMLBeans proposal

["Andrew C. Oliver" <ac...@apache.org>]

> Simplistic standards like "> 51% of the ACTIVE committership from a
> different company" might work for making simplistic decisions.  They are
> not appropriate for a decision to accept a new project into Apache, which
> should be based on the quality of the proposed code and the proposed
> initial committers, not on the email addresses of the proposed initial
> committers.
>

Maybe that¹s not a candidate for policy however it is required for MY vote.
If your boss came and said "Craig, if you don't vote X then you're fired"
and said this to a number of committers...  While some might quit or
whatever, I suspect the vote would be decided supposing they dominate the
project.

Furthermore, the interests of a set of employees of a company using a
project for a particular purpose will tend to have homogenous interests.
Thus will *tend* to vote similarly (if not the same way).  It is my
experience that developers who counter their employers interest do not stay
employed for long. 

Lastly, developers who work together at work tend to communicate directly
versus on community resources more frequently.

In a NEW project it is my opinion that diversity should be settled up front
so that no one company controls any new project.  This is MY criteria for
certain and required for my vote -- perhaps its not yours.

-Andy
 
> Craig McClanahan
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
> 

-- 
Andrew C. Oliver
http://www.superlinksoftware.com/poi.jsp
Custom enhancements and Commercial Implementation for Jakarta POI

http://jakarta.apache.org/poi
For Java and Excel, Got POI?


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org

Re: Issues with XMLBeans proposal

["Craig R. McClanahan" <cr...@apache.org>]

Snipping to an issue I have with one particular comment.

On Thu, 3 Jul 2003, Andrew C. Oliver wrote:

>
> 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.
>

Andy, I agree with you that diversity is important, but your proposed
standard (more than half the committers from "elsewhere") has some
distrubing implications that are worth exploring.

* There is an implied assumption that the proposed committers
  will behave the way that their employer wants, not the way
  that they want.  Although it is too simplistic to say that
  this never happens (our individual actions are public record,
  so of course you take into consideration what your employer
  might think), developers that are solely "corporate mouthpiece"
  players should never have been elected as committers
  in the first place.

* There is an implied assumption that all the committers from
  the same company will vote the same way.  I can tell you from
  lots of experience over the last few years (some of it pretty
  painful and personal) that this is not likely to be a problem.
  If it is, then we screwed up on accepting the original committers
  in the first place.

* There is an implied assumption that a person's employer (and therefore
  their corporate email address) should have anything to do with
  whether or not that person is individually a good choice for being
  an Apache committer.  THAT should be the overriding concern -- after
  all, they will be able to stay a committer even if they move to a
  different job (within the same company or elsewhere).

* What happens to your "diversity" statistics if a committer that was
  originally outside the originating company is then hired by that
  company to continue working on the project?  One of the company's
  goals might well be to support open source by allowing that person
  to work on the project on company time; yet your proposed standard
  would view the change of employment as a negative and not a positive.

Apache is about individuals, not about companies.  Apache is about
attracting high quality software projects, not about conspiracy theories
(go back in the archives a couple years before you joined, and you'll see
LOTS of discussion along these lines :-).

Diversity is important -- a proposal that ONLY has committers from one
company needs to be analyzied.  But a proposal that includes a software
contribution from a company, but WITHOUT any committers from that company
willing to continue working on the software (the "throw it over the wall"
scenario) would also be problematic.

Simplistic standards like "> 51% of the ACTIVE committership from a
different company" might work for making simplistic decisions.  They are
not appropriate for a decision to accept a new project into Apache, which
should be based on the quality of the proposed code and the proposed
initial committers, not on the email addresses of the proposed initial
committers.

Craig McClanahan

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org