Re: Issues with XMLBeans proposal
On Thu, Jul 03, 2003 at 10:12:17PM -0400, Andrew C. Oliver wrote: On 7/3/03 7:24 PM, Greg Stein [EMAIL PROTECTED] wrote: 3. Jakarta - IMHO this the best place for it. The division of XML vs Jakarta predates me for certain, but I think the main issues surrounding that are rusty. The problem is Jakarta itself. Centering a PMC around a *language* rather than functionality is the inherent problem. These questions will continue to arise over and over. What's done is done. As a Jakarta committer I always feel like the guy wearing a I'm here I'm queer deal with it shirt at a Republican National Convention. Heh :-) Oh, what was done [Jakarta] was done *very well*. Don't get me wrong on that. I'm simply trying to point out that a language-oriented PMC is going to continue to cause decision-making problems like this. Am I suggesting unwinding Jakarta *because* it is language-oriented? Not at all. I *would* like to see more TLPs spin out of Jakarta, though. The Board doesn't have near enough insight into the major Jakarta projects: Tomcat, Struts, Turbine, Velocity, Gump, etc. When Grisha Trubetskoy wanted to contribute mod_python to the ASF, a good number of people called for creating a 'python' TLP. The Board decided to stop perpetrating the per-language concept. Instead, mod_python was added to the Apache HTTP Server Project (it *is* a module for Apache httpd, after all). mod_php, mod_perl, and mod_tcl fall under the same argument, of course, but they get a Grandfather Pass :-) I'm getting de ja vu... You don't like this community. I get it... I'll file this on the appropriate file system for such information. So Jakarta is the grandfather of them all... Etc etc Feh. I didn't say that, and you know it :-) The community is just fine and has done great stuff. I think the language focus of the Jakarta, Perl, PHP, and TCL TLPs is the wrong axis for slicing up where to put codebases. I also think Jakarta is too big and needs to spin out some TLPs. But don't like this community ?!?! Hah. ... I agree. The question for them: Are you a good witch or a bad witch? ;-) Euh... :-) Cheers, -g -- [EMAIL PROTECTED] ... ASF Chairman ... http://www.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache != HTTPD (was Issues with XMLBeans proposal)
On Tue, Jul 08, 2003 at 06:50:34PM +0200, Santiago Gala wrote: The reverse of this is that I don't often see Jakarta, Tomcat, Ant, Velocity, Xerces or Xalan referenced as Apache XXX. So, it looks like the people cannot stick two words together and still be a brand. Side Note: It reminds me of the GNU/Linux stuff (or even GNU Emacs). It simply doesn't stick. Much agreed, and ideally we could rebrand the HTTPD project as just that, 'HTTPD'. No Apache prefix, as you're right, none of the other projects use the Apache prefix (maybe because it's already taken by HTTPD?). I thought of proposing this rename to just HTTPD, but could see it getting even more backlash than the 'Apache' - 'Apache HTTPD' rename. If we went straight 'Apache' - 'HTTPD', then there'd be a hard conversion for, say, system admins scrolling through install screens (or the FreeBSD ports collection) looking for 'Apache 1.x/2.x' and not seeing anything. Think of all the confusion renaming something like 'apachectl' to 'httpdctl' or just 'httpd' would cause. In theory, I'm all for it, and the purist side of me really likes it, but I was trying to be a bit more pragmattic. With the 'Apache HTTPD' rename, I think it'd easier politically to get the change through in places like Redhat, FreeBSD ports collection, etc. I copy community (on political principles). If you want to raise awareness of such an Apache wide fact, don't do it in a java only place like Jakarta. Makes sense; I had forgotten this 'general' was at 'jakarta.apache.org' instead of just 'apache.org'. Actually, I think I'd like to get support for this before taking it to community. If people here at Jakarta don't want to go ahead with pursuing a rebranding effort, then I wouldn't bother raising it on community. Also, thinking about the strict 'Apache' - 'HTTPD' rename, just 'HTTPD' sounds rather clunky (to me, perhaps being naive). If the HTTPD community doesn't like being called just httpd, what if we did an even more drastic rename? A la the Mozilla Phoenix - Mozilla Firebird rename. It might actually work better, because if it's a bigger deal then just 'Apache' - 'Apache HTTPD', we could get lots of publicity on slashdot and other tech sites to inform end users of the change and hopefully avert some of the backlash on 'apache' no longer being in ports/installers/paths/etc. - Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache != HTTPD (was Issues with XMLBeans proposal)
Stephen Haberman wrote: Much agreed, and ideally we could rebrand the HTTPD project as just that, 'HTTPD'. No Apache prefix, as you're right, none of the other projects use the Apache prefix (maybe because it's already taken by HTTPD?). Wasn't that the name of the original NCSA web server? Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issues with XMLBeans proposal
Nicola Ken Barozzi wrote: Greg Stein wrote, On 04/07/2003 1.24: On Thu, Jul 03, 2003 at 04:22:10PM -0400, Andrew C. Oliver wrote: To that extent, I'd say it is an XML project. There is another more simple rule. Who has shown that they want the project most? Apache.XML. Then let them have it. However, I think it is mostly up to the XMLBeans community to ask for one or the other. If that PMC says okay, then everything is fine. (and no... PMCs are not allowed to meet at sundown to duel for an arriving project :-) No? ;-P If XML.Apache is willing, as it seems, to cater for this project, I'll wait for a vote from them, an ACK from the Bea guys, and start preparing the hatcher :-) I'm happy to invest some time in helping XMLBean get throught the incubator -- speaking with my XML PMC and ASF member hat on. Ted - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issues with XMLBeans proposal
On 4/07/2003 5:48 [EMAIL PROTECTED] wrote: Out of curiosity - does it have to be decided now? I guess not, if some actual people are willing to help XMLBeans out during incubation, setting up CVS, lists and all that, and monitor how they are doing - so that they can inform the eventually receiving PMC on the Apachiness of the incubating project. A clear sense direction might of course help, especially w.r.t. infrastructure - in a sense that CVS repos don't need to be moved, lists recreated and all that. Cfr. Lenya's incubation, which is still in progress, but already they have been made an integral part of the Cocoon project infrastructure. Less fuzz afterwards, and if incubation fails, deletion is still a no-brainer. If there is a general feeling from the two PMCs that they would be comfortable, then maybe we both sponsor into the incubator and give the committers time to migrate everything to Apache. Presumably in that time they are also getting used to Apache and can develop an understanding of where they feel their project fits best. Not jumping to any conclusion, I'm very happy to see a positive and constructive discussion happening. Thanks, all. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issues with XMLBeans proposal
Greg Stein wrote, On 04/07/2003 1.24: On Thu, Jul 03, 2003 at 04:22:10PM -0400, Andrew C. Oliver wrote: ... 1. Top level project - IMHO this isn't big enough and you don't have the open source experience or robust community to pull that off (not intended to be a criticism) There is no size minimum for a TLP, but I believe the Board would want to see the PMC has more direct experience at the ASF. So yes, I don't see that the Board would approve constructing a new PMC for this. As incubation goes, making a project a TLP right away is a *major* problem. If it isn't already a big and stable project with knowledge of Apache rules and a big sane OS community around it, I really prefer it to be under another PMC that can do the practical part of the incubation. 2. XML - I'm sure it would be fine. 3. Jakarta - IMHO this the best place for it. The division of XML vs Jakarta predates me for certain, but I think the main issues surrounding that are rusty. The problem is Jakarta itself. Centering a PMC around a *language* rather than functionality is the inherent problem. These questions will continue to arise over and over. At that time it made sense. Java is not only a language, and is so separated from other environments, that it was IMHO the only way of aggregating enough resources to launch something out of it. But things that go well one time (and Jakarta has been a major success), don't necessarily go well the second. When Grisha Trubetskoy wanted to contribute mod_python to the ASF, a good number of people called for creating a 'python' TLP. I'd do it when they'll donate Python itself ;-) Does wishful thinking work? ... To that extent, I'd say it is an XML project. There is another more simple rule. Who has shown that they want the project most? Apache.XML. Then let them have it. However, I think it is mostly up to the XMLBeans community to ask for one or the other. If that PMC says okay, then everything is fine. (and no... PMCs are not allowed to meet at sundown to duel for an arriving project :-) No? ;-P If XML.Apache is willing, as it seems, to cater for this project, I'll wait for a vote from them, an ACK from the Bea guys, and start preparing the hatcher :-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issues with XMLBeans proposal
Nicola Ken Barozzi escribió: Greg Stein wrote, On 04/07/2003 1.24: On Thu, Jul 03, 2003 at 04:22:10PM -0400, Andrew C. Oliver wrote: (...) The division of XML vs Jakarta predates me for certain, but I think the main issues surrounding that are rusty. The problem is Jakarta itself. Centering a PMC around a *language* rather than functionality is the inherent problem. These questions will continue to arise over and over. This can be paraphrased as Centering a PMC around *the new ASCII spec* rather than functionality is the inherent problem. In a lot of senses, XML has permeated the whole playing field. Pure XML projects will either be XML-functionality-toolkit projects or architectural slices of other projects. All classification attempts are doomed to failure ( http://www.crockford.com/wrrrld/wilkins.html ) unless we take them with a grain of salt. At that time it made sense. Java is not only a language, and is so separated from other environments, that it was IMHO the only way of aggregating enough resources to launch something out of it. But things that go well one time (and Jakarta has been a major success), don't necessarily go well the second. Things are not static. In the late 80's/early 90's I worked for a company where a Technology department for LA Networking existed. As LAN technology was more and more widespread and standard, the need for such a dept. disappeared. Today it would not make sense, but companies do have WiFi Technology Depts. which will vanish in a couple of years... When Grisha Trubetskoy wanted to contribute mod_python to the ASF, a good number of people called for creating a 'python' TLP. I'd do it when they'll donate Python itself ;-) Does wishful thinking work? ... To that extent, I'd say it is an XML project. There is another more simple rule. Who has shown that they want the project most? Apache.XML. Then let them have it. This is a good heuristic, I think. However, I think it is mostly up to the XMLBeans community to ask for one or the other. If that PMC says okay, then everything is fine. (and no... PMCs are not allowed to meet at sundown to duel for an arriving project :-) No? ;-P Don't forget that sundown occurs continuously in a slice of the world, and that the probability of an Apache committer seeing a sundown is high at any given moment ( http://cvs.apache.org/~sgala/nightmap.html ) Regards -- Santiago Gala High Sierra Technology, S.L. (http://hisitech.com) http://memojo.com?page=SantiagoGalaBlog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issues with XMLBeans proposal
On 7/4/03 7:26 PM, Santiago Gala [EMAIL PROTECTED] wrote: Don't forget that sundown occurs continuously in a slice of the world, and that the probability of an Apache committer seeing a sundown is high at any given moment ( http://cvs.apache.org/~sgala/nightmap.html ) Regards I think that is a conversation best held at [EMAIL PROTECTED] :-p ;-) -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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issues with XMLBeans proposal
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issues with XMLBeans proposal
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: [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]
Re: Issues with XMLBeans proposal
On 7/3/03 2:22 PM, Cliff Schmidt [EMAIL PROTECTED] wrote: As Santiago points out, the veto rule provides some protection over pure majority, but I don't think anyone here wants to rely on that. All I can tell you is that BEA is more concerned about establishing a long term relationship with Apache and other open source communities than controlling the future development of XMLBeans. From our perspective, we have much more to gain by proving ourselves as credible and positive contributors to open source, especially since we would like XMLBeans to be the first in a series of open source contributions. If the BEA committers attempt to make decisions against the wishes of the rest of the community and are viewed negatively for doing so, we have absolutely failed in what we set out to do. That is encouraging. That would be a nice development. Of course you understand that I don't want us to totally make an exception just because of this. At the moment, on the merits, the project has some difficulty. However using this motivation that you're expressing, I think this is a bridge that can be crossed. -andy See my response to Howard's questions for more on how the project differs technically from other open source projects. Cliff - 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]
Issues with XMLBeans proposal
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issues with XMLBeans proposal
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]
RE: Issues with XMLBeans proposal
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]
Re: Issues with XMLBeans proposal
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
RE: Issues with XMLBeans proposal
On Thursday, July 03, 2003 11:01 AM, Andrew C. Oliver wrote: 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. As Santiago points out, the veto rule provides some protection over pure majority, but I don't think anyone here wants to rely on that. All I can tell you is that BEA is more concerned about establishing a long term relationship with Apache and other open source communities than controlling the future development of XMLBeans. From our perspective, we have much more to gain by proving ourselves as credible and positive contributors to open source, especially since we would like XMLBeans to be the first in a series of open source contributions. If the BEA committers attempt to make decisions against the wishes of the rest of the community and are viewed negatively for doing so, we have absolutely failed in what we set out to do. See my response to Howard's questions for more on how the project differs technically from other open source projects. Cliff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issues with XMLBeans proposal
+1 On 7/3/03 2:26 PM, Neil Graham [EMAIL PROTECTED] wrote: Hi Cliff, I think the copy list of your note to Howard must have been a good bit narrower than the copy list of this response to Andy. :) Any chance you could enlighten those of us in this broader group who are interested as to the technical points on which XMLBeans differs from other technologies? Cheers! Neil Neil Graham XML Parser Development IBM Toronto Lab Phone: 905-413-3519, T/L 969-3519 E-mail: [EMAIL PROTECTED] |-+ | | Cliff Schmidt | | | [EMAIL PROTECTED] | | || | | 07/03/2003 02:22 | | | PM | | | Please respond to| | | general | | || |-+ - | | | | To: Jakarta General List [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] | | cc: | | Subject: RE: Issues with XMLBeans proposal | | | | | - | On Thursday, July 03, 2003 11:01 AM, Andrew C. Oliver wrote: 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. As Santiago points out, the veto rule provides some protection over pure majority, but I don't think anyone here wants to rely on that. All I can tell you is that BEA is more concerned about establishing a long term relationship with Apache and other open source communities than controlling the future development of XMLBeans. From our perspective, we have much more to gain by proving ourselves as credible and positive contributors to open source, especially since we would like XMLBeans to be the first in a series of open source contributions. If the BEA committers attempt to make decisions against the wishes of the rest of the community and are viewed negatively for doing so, we have absolutely failed in what we set out to do. See my response to Howard's questions for more on how the project differs technically from other open source projects. Cliff - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - In case of troubles, 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]
RE: Issues with XMLBeans proposal
Sorry about that -- looks like that mail didn't make it out of my outbox. I'll resend right now to all three lists. Cliff On Thursday, July 03, 2003 11:50 AM, Andrew C. Oliver wrote: +1 On 7/3/03 2:26 PM, Neil Graham [EMAIL PROTECTED] wrote: Hi Cliff, I think the copy list of your note to Howard must have been a good bit narrower than the copy list of this response to Andy. :) Any chance you could enlighten those of us in this broader group who are interested as to the technical points on which XMLBeans differs from other technologies? Cheers! Neil Neil Graham XML Parser Development IBM Toronto Lab Phone: 905-413-3519, T/L 969-3519 E-mail: [EMAIL PROTECTED] -+ | Cliff Schmidt | | [EMAIL PROTECTED] | || | 07/03/2003 02:22 | | PM | | Please respond to| | general | || -+ - | To: Jakarta General List [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] | cc: Subject: RE: Issues with XMLBeans proposal - | On Thursday, July 03, 2003 11:01 AM, Andrew C. Oliver wrote: 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. As Santiago points out, the veto rule provides some protection over pure majority, but I don't think anyone here wants to rely on that. All I can tell you is that BEA is more concerned about establishing a long term relationship with Apache and other open source communities than controlling the future development of XMLBeans. From our perspective, we have much more to gain by proving ourselves as credible and positive contributors to open source, especially since we would like XMLBeans to be the first in a series of open source contributions. If the BEA committers attempt to make decisions against the wishes of the rest of the community and are viewed negatively for doing so, we have absolutely failed in what we set out to do. See my response to Howard's questions for more on how the project differs technically from other open source projects. Cliff - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - In case of troubles, e-mail: [EMAIL PROTECTED] 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]
RE: Issues with XMLBeans proposal
Hi Cliff, I think the copy list of your note to Howard must have been a good bit narrower than the copy list of this response to Andy. :) Any chance you could enlighten those of us in this broader group who are interested as to the technical points on which XMLBeans differs from other technologies? Cheers! Neil Neil Graham XML Parser Development IBM Toronto Lab Phone: 905-413-3519, T/L 969-3519 E-mail: [EMAIL PROTECTED] |-+ | | Cliff Schmidt | | | [EMAIL PROTECTED] | | || | | 07/03/2003 02:22 | | | PM | | | Please respond to| | | general | | || |-+ -| | | | To: Jakarta General List [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] | | cc: | | Subject: RE: Issues with XMLBeans proposal | | | | | -| On Thursday, July 03, 2003 11:01 AM, Andrew C. Oliver wrote: 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. As Santiago points out, the veto rule provides some protection over pure majority, but I don't think anyone here wants to rely on that. All I can tell you is that BEA is more concerned about establishing a long term relationship with Apache and other open source communities than controlling the future development of XMLBeans. From our perspective, we have much more to gain by proving ourselves as credible and positive contributors to open source, especially since we would like XMLBeans to be the first in a series of open source contributions. If the BEA committers attempt to make decisions against the wishes of the rest of the community and are viewed negatively for doing so, we have absolutely failed in what we set out to do. See my response to Howard's questions for more on how the project differs technically from other open source projects. Cliff - In case of troubles, e-mail: [EMAIL PROTECTED] 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]
RE: Issues with XMLBeans proposal
Now to address, Andy's other issues (the first issue has spun off into a different thread)... On Thursday, July 03, 2003 8:57 AM, Andrew C. Oliver wrote: 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. This is definitely a Java-only project right now. If that is a clear line of separation, I will stop posting to the XML list. The reason I posted to both lists was partly due to the fact that XMLBeans is much more XML-centric than Java centric (in terms of data modeling and the full fidelity availability of the XML Infoset); I really feel like this is one of those projects that could go either way. The other reason for posting to both lists is that three different Apache people (two of them ASF members) advised me to do so. I'm definitely interested in feedback as to whether to just limit the discussion to Jakarta right now. 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. I've tried to address some of the differences with XMLBeans and why I think it adds a lot more than currently existing projects (see my response to Howard -- http://archives.apache.org/eyebrowse/ReadMsg? [EMAIL PROTECTED]msgNo=15061). However, this might be a good time for David Bau, the architect behind XMLBeans, to jump in with his views. 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. We would appreciate any help anyone has to offer, but I'm hoping we don't appear to need any special treatment. I've spent the last few months talking to everyone I can and reading everything I can about how to do this right. You and Howard have brought up some very reasonable points and I want to make sure I address them (either with further explanation or by making whatever changes to this proposal are necessary). Thanks, Cliff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issues with XMLBeans proposal
On 7/3/03 3:50 PM, Cliff Schmidt [EMAIL PROTECTED] wrote: On Thursday, July 03, 2003 8:57 AM, Andrew C. Oliver wrote: 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. This is definitely a Java-only project right now. If that is a clear line of separation, I will stop posting to the XML list. The reason I posted to both lists was partly due to the fact that XMLBeans is much more XML-centric than Java centric (in terms of data modeling and the full fidelity availability of the XML Infoset); I really feel like this is one of those projects that could go either way. The other reason for posting to both lists is that three different Apache people (two of them ASF members) advised me to do so. I'm definitely interested in feedback as to whether to just limit the discussion to Jakarta right now. options: 1. Top level project - IMHO this isn't big enough and you don't have the open source experience or robust community to pull that off (not intended to be a criticism) 2. XML - I'm sure it would be fine. 3. Jakarta - IMHO this the best place for it. The division of XML vs Jakarta predates me for certain, but I think the main issues surrounding that are rusty. I've tried to address some of the differences with XMLBeans and why I think it adds a lot more than currently existing projects (see my response to Howard -- http://archives.apache.org/eyebrowse/ReadMsg? [EMAIL PROTECTED]msgNo=15061). However, this might be a good time for David Bau, the architect behind XMLBeans, to jump in with his views. Okay. It sounds like there are some issues which warrant this over others. I could see this being useful in things like web services as well... Limit object creation/serialization and yada yada yada... Though from reading the 10k foot view you could support JAXB if you wanted to. Just an element of curio for me...Offtopic...nevermind ;-) We would appreciate any help anyone has to offer, but I'm hoping we don't appear to need any special treatment. I've spent the last few months talking to everyone I can and reading everything I can about how to do this right. You and Howard have brought up some very reasonable points and I want to make sure I address them (either with further explanation or by making whatever changes to this proposal are necessary). Well the homogony is a big issue. Apache isn't a panacea, you'll have to work at it but I think you're sincere and motivated. Steven can help you through the gauntlet^M^M^M^M^M^M^Mincubator process and provided the committership had rounded out, and you integrated with Gump I'd vote in favor of Jakarta acceptance. (BTW acceptance to Jakarta is a majority of the Jakarta PMC vote)... It would be nice if other Jakarta PMC members sounded off a little so the incubator can hear. -Andy Thanks, Cliff - 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]
Re: Issues with XMLBeans proposal
From: Andrew C. Oliver [EMAIL PROTECTED] On 7/3/03 7:24 PM, Greg Stein [EMAIL PROTECTED] wrote: ... okay, then everything is fine. (and no... PMCs are not allowed to meet at sundown to duel for an arriving project :-) Everyone always takes all the fun out of my life :. Out of curiosity - does it have to be decided now? If there is a general feeling from the two PMCs that they would be comfortable, then maybe we both sponsor into the incubator and give the committers time to migrate everything to Apache. Presumably in that time they are also getting used to Apache and can develop an understanding of where they feel their project fits best. Cheers, Berin This message was sent through MyMail http://www.mymail.com.au - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
