RE: Vote for XMLBeans proposal
Thanks to all of you for the many offers to help us get things started with XMLBeans. It sounds like it might be easier for everyone if we now pick one project that we believe would be the best fit for XMLBeans. From talking with a few committers, I think we are leaning towards the XML project, but I would like verify that with each of the others. I should be able to confirm this preference in the next 12-16 hours. Thanks again to everyone for being so willing to help make this work. BTW, I'll be at OSCON all week, if anyone would like to discuss any issues further. Cliff On Sunday, July 06, 2003 7:57 AM, Aleksander Slominski wrote: Subject: Re: Vote for XMLBeans proposal Berin Lautenbach wrote: Ted Leung wrote: Nicola Ken Barozzi wrote: 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. The idea of moving XMLBeans to incubation under the XML project and with the assistance of Ted gets a +1 from me with some caveats : 1. Current XMLBeans committers need to be comfortable with this resting with the XML project in the first instance. Note that I would hope that the umbrella project could be changed prior to exit from incubation if the feeling from the committers was that it should be. If the initial preference is Jakarta then please indicate! I'm definitely not trying to push a line here, and it's easy to switch the vote over to the Jakarta PMC :. 2. Committer issues that have previously been discussed will need to be worked through during incubation (although that's really what incubation is about :). +/- from other XML PMC members welcome. Further discussion also welcome! hi, based on what I have seen when looking on XMLBeans source code and (limited) design documentation I beleive that this project is very interesting and useful for Web Services so I have CCed [EMAIL PROTECTED] mailing list too. It seems that BEA folks are willing to solve all remaining problems and I think that it would be good if this project quickly gained more mementum and I am willing to help with it (even though I am not Apache XML commiter) thanks, alek - 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
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
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: Proposal: XMLBeans
(copying the other lists, by request) Thanks for all the good questions and advice, Howard. Please let me know if the following leaves you with other questions or concerns. On Wednesday, July 02, 2003 7:26 PM, Howard M. Lewis Ship wrote: See [http://workshop.bea.com/xmlbeans/quickStart.jsp BEA's quick start page] for more information. There's a commons module, Betwixt, that very much overlaps what you describe here. The main difference is the XML Schema support. However, there are areas of XMLBeans that overlap with other projects (especially commons modules like Betwixt). This is one of the reasons we are interested in Apache -- we would like to integrate/reuse as much as possible of other projects, especially if it makes the final product better. We also believe that the other projects could benefit from pieces of XMLBeans. What's compelling about XMLBeans compared to some of the other front runners, such as JDOM and XOM, Castor and JAXB? The main difference between XMLBeans and JDOM or XOM is that XMLBeans does not create objects for each XML information item. Instead, it provides cursor-based access to each item in the XML Infoset. It has an architecture where, if an actual object is needed for a node, it can be created on-demand. We found this provided great performance benefit. The biggest differences between XMLBeans and Castor or JAXB are: 1) the goal of 100% Schema support (currently supports everything in Schema other than redefine and substitution groups, and those features are nearly ready), and 2) the integrated and synchronized access of the underlying XML content with strongly typed Java classes. ''Meritocracy: '' We would very much like to see XMLBeans evolve under the meritocracy model that is used within Apache. The advice I got is still good ... get your meritocracy working RIGHT NOW. I personally found big benefits to reoganizing along these lines; it would have been worth the effort even if Tapestry hadn't made it all the way in. The meritocracy really works to get people motivated and contributing. I agree. We spent a lot of time thinking about the best community structure for XMLBeans and decided that the meritocracy by Apache was the model that we wanted to follow. We've made the first steps in this direction, but we are now trying to go all the way with it. Whether Apache is the right place for XMLBeans or not, we will be following the meritocracy model. In fact, we are looking at starting open source projects around several other technologies we've recently developed, and even though many of these won't be appropriate for Apache, we will still will be following a meritocracy model since we are also convinced that it really does work. ''Core Developers:'' In addition to key members of the XMLBeans development team, the initial committers include developers from outside BEA who have spent several months using XMLBeans to solve their particular development needs. Be prepared to document a bit more about outside developers' contributions. To be clear, the outside developers have only recently had the opportunity to submit patches, but they have been working closely with the BEA development team for six months by submitting bugs and feature requests based on the problems that they would run into while developing against XMLBeans within each of their applications. I've learned the hard way to get rid of all [L]GPL dependencies before you attempt to move to Jakarta. It's not even a question for us. We are in the process of dealing with this now. I just wanted to let you all know that we were handling it. Do you have a roadmap of where you would like this project to be in 6 months? A year? Two years? Yes - and I will post it shortly on the Wiki site. What licensing to you currently use? LGPL is a problem, BSD or ASL is the way to go. (Pardon me if this is on the pages you've linked to ... I haven't clicked through yet). We currently use an Apache-style license. See http://workshop.bea.com/xmlbeans/XsdUpload.jsp. '''(5) identify apache sponsoring individual ''' * Steven Noels ([EMAIL PROTECTED]) That's a good step! Yes - Steven has been incredibly helpful by allowing me to bounce ideas off him about how BEA can get involved with the open source community, and specifically if and how XMLBeans would be complement Apache. I'd be interested to know why you feel the project will benefit from hosting at Jakarta? My personal experience with Tapestry is that the move to Jakarta was good for exposure ... but Tapestry, regretably, did not have a major player (such as BEA) backing it. Eclipse, for example, self-hosts, yet is taken very seriously as an open source project. We are looking at open sourcing other BEA technologies, some of which would probably make the most sense in a self-hosted community, especially ones that we don't think Apache would be interested in. One reason we are
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: Proposal: XMLBeans
On Thursday, July 03, 2003 12:02 PM, Cliff Schmidt wrote: On Wednesday, July 02, 2003 7:26 PM, Howard M. Lewis Ship wrote: Do you have a roadmap of where you would like this project to be in 6 months? A year? Two years? Yes - and I will post it shortly on the Wiki site. I've just posted a description of what we have in mind at: http://nagoya.apache.org/wiki/apachewiki.cgi?XmlBeansRoadMap Cliff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
