On Mon, Jun 6, 2011 at 3:52 PM, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
> To the extent that OOo presents the incubator with something the ASF has > not faced, you are correct... these things we have no standards yet to > measure whether a podling should be accepted. To the extent that it is > the same, or similar, as many other incubator podlings, it should be > allowed to proceed without changing those standards. The question is, > in which ways is OOo unique to the ASF? We've had some good discussions > here on these points. Let me summarize what I do see as unique points: - Code duplication: We frequently had projects that duplicated another projects scope, or whatever you name it. But we never before had a case, where there is an existing open source project with almost identical source code. - Community overlap: Most likely as a consequence of the previous point, we never before had a case, where there is an external, and, to the best of my knowledge, working community that is so interested in the proposed project while at the same time wishing not to join. That in common with the code duplication means that all we can really do better is the choice of license. That may be sufficient for most, but not all of us. - Audience: Apache audience has traditionally been system admins, developers, and so on. As a consequence, Apache projects are typically having a community of some hundred or thousand users. Those hundreds or thousands are typically aware of what Apache can and cannot do. This project aims to be used by millions. We must realistically expect that a lot of additions and modifications must be made for this project in terms of infrastructure, policies, and structures. Users will be more helpless and unaware as they usually are. What worked for all and every existing Apache project will most likely not work for this one. - Concentration on binaries: Apache projects are usually all about source code. For example, Apache httpd is still distributing binaries for Windows and Netware (!) only. For this project, a release will possibly consist of a single tar ball plus several hundred or even thousand binaries: A myriad of localized variants, several platforms (at least Windows 32/64, Mac) are already for sure, but it is easy to imagine additional variants. Such releases can no longer be controlled in the traditional way. Which PMC member would really bother to inspect some hundred files when asked for a positive vote? - Efforts overlap: Again, as a consequence of the points, we never before had a case, where there is an external organization that will basically do just the same stuff: Build scripts for binaries, running a build infrastructure, reapply our patches, and so on. That means a real lot of duplicated efforts with no additional value. Jochen -- Capitalism is the astounding belief that the most wickedest of men will do the most wickedest of things for the greatest good of everyone. John Maynard Keynes (http://en.wikiquote.org/wiki/Keynes) --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
