Some of you know I was closely involved in the original open-sourcing of StarDivision code as OpenOffice.org. I'm also an Apache Member. Thought some of the current discussions could benefit from a tiny bit of (no axe to grind) history.
This information is offered in the spirit of trying to get it "right" as we go forward. I've offered to mentor the podling (should it be accepted, which I think is likely) because I'd really like to see the best outcome to a tough situation here. PLEASE only actual questions relating to the content of this message in this thread. 1) Why the .org? Well...the original owner of the code, Marco Boerries, was really fond of the name OpenOffice. No other name would do. However, Sun's lawyers were not willing to endorse a name that they couldn't secure worldwide trademarks on. There was an existing proprietary software package sold in the South Korean market that was using the name OpenOffice. Although the software in question was *not* a productivity package, it was felt by Sun Legal that field of use was too close and so they advised we add something to make the trademark more unique. Since Sun was trying to transmit the meme that the new project was going to really be open source, they decided (for better or worse) to register OpenOffice.org (which was also the project URL). I'd imagine that the trademark grant Oracle has transferred to us should read "OpenOffice.org" and not "OpenOffice". We should seek to clarify in any documents where this is ambiguous. Apache should use OOo rather than OO wherever possible. 2) Why the LGPL? The original intention was to attract the cooperation of the then-burgeoning Desktop Linux community. OpenOffice.org was announced at the same time (literally at the same press conference) as the formation of GNOME.org (with Miguel de Icaza and Nat Friedman supporting both announcements). GNOME.org was adamantly GPL and thus OOo was offered under a compatible license. I and others spent many man-hours explaining this to Sun execs and lawyers to clear the way for LGPL licensing (which BSD-inspired Sun had previously said they would "never" employ). Honestly it wasn't an ideological choice on Sun's part, it was expedient. They were looking to make best (disruptive) use of a sunk-cost asset. That said, folks like Michael Meeks were absolutely the target audience. Coincidentally, I ran into Nat and Miguel at a party last night and they both said they thought ALv2 licensing and an Apache home for OOo is a good idea now... 3) LOTS of people download OOo Like maybe 10% of the human population of the planet. And its a big file. Initially we engaged Akamai, but it quickly became too expensive. Serving up downloads of OOo was pretty intense. I know Apache has all that web server download traffic and all...but I'm telling you Sun.com quailed at the throughput, and we shouldn't assume our mileage will vary. There will be extraordinary infrastructure costs, because it is end-user software (and there are a LOT of users worldwide). Sun mitigated this problem with mirrors, but of course that screwed download stats. It's a lot of code as well. When we launched it took a day (as in 24 hours) to build. I'd imagine that situation will have improved somewhat, but rolling a public release of end-user code is a much different prospect to releasing another version of the web server. 4) most customers use OOo on Windows Last time I checked, the percentage of Windows users was still in the high 90s percentile. But it builds on the various Linux distros, as well as MacOSX and a bunch of other platforms, each with their own lovely and unique quirks. This complexity is one of the reasons it might be a good idea to behave like kernel.org and let OOo "distros" handle end-user packaging and distribution. Another reason would be that consumers are relatively unsophisticated and ask a lot of silly questions... There are more things to know, but that's a start. Danese --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
