So what in this ensures this will be a community-developed project and not just an Apache branded extension of BEA? I really would like to see you guys involved in Apache, but not in a way the compromises Apache. There is a challenge that limits the excitement of others in that there are so many other similar projects that do exactly the same thing. Perhaps it would benefit the effort if you explained why we needed another one. That has no bearing on its suitability but it might make people more interested who wouldn't be otherwise.
Note that I didn't come up with the "shouldn't be all from the same company" requirement...that was noted long before my time.. -Andy On 7/3/03 1:27 PM, "Cliff Schmidt" <[EMAIL PROTECTED]> wrote: > I understand Andy's concern here, but I think Craig does a good job > of pointing out the consequences of less participation by the core > developers of a project, and the possibly invalid assumptions > around that. > > As any of the committers can tell you, I wrestled with the list and > really tried to limit the BEA involvement to a functional minimum. > There are a few reasons why I ended up with 6 out of 9 being BEA > folks: > > 1) I'm really hoping that other members of the Apache community will > find this project interesting enough that we will end up with a > couple experienced Apache people on our committer list, thereby > reducing the BEA percentage. > > 2) The core XMLBeans developers (all BEA employees) are really > excited about this stuff and want to do what ever they can to keep > improving it. They are open to all kind of possibilities for > refactoring, integration with other projects, and especially working > with others on it...but they really all wanted to stay involved. It > would probably be more efficient for BEA to have only a couple > developers on the project, but the individuals wanted to be as > involved as possible. > > 3) In the end, I had to go with the people I thought would have the > most knowledge and experience with the code to lead by example. I > am hoping that an active committer list will inspire community > participation. I found three non-BEA people who I know will fill > this role, plus the six BEA people. > > (I'll be responding to Andy's other points and Howard's email > shortly.) > > Cliff > > > On Thursday, July 03, 2003 10:01 AM, Craig R. McClanahan wrote: > >> 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: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
