Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


On Sun, Jun 5, 2011 at 1:48 PM, Sam Ruby <rubys@apache.org> wrote:
...
I will be totally transparent as to what my preference however is.  It
is my fond hope that all of the participants will identify subsections
of the code that they are willing to share the burden of maintenance
with the larger community.  Direct participation in the development of
that pool ensures that you can harvest that code back quickly and
easily as there is no need to merge it with other changes that you
held back.  Furthermore the extension points you need for your value
add will be in the base.

Part of this vision is also that participants don't block one another.
 If IBM, for example, has a proprietary value add they should not be
able to block somebody else from contributing substantially similar
functionality to the ASF under a more liberal license.  Similarly, if
LO has some CopyLeft value add, they should not be able to block
others from contributing substantially similar functionality to the
ASF under a more liberal license.

Again, fully symmetrical.


What can the Apache Foundation provide to OpenOffice?
1. You start with zero community and you alienate the LibreOffice community.
2. You will start building a community at some point in the future in
some unknown way.
3. You are developers and can currently only deal with developer needs.
4. Your infrastructure is based on Subversion (SVN) which will make it
difficult
for other to share code. Git is not even in the immediate plans.
5. You are happy to get going with 20-30 core developers.
6. The Apache Foundation hosts over 150 projects and I fail to see
any important user-centric software like OpenOffice.

The essential need for the Apache Foundation involvement in this appears to be
so that IBM can continue to offer a proprietary product, IBM Lotus Symphony,
License Agreement at http://pastebin.com/uqbUTRg5

Is IBM is trying to replicate what Sun/Oracle had with StarOffice,
putting just enough resources
for their own needs in order to ship their product?

The Linux kernel is an amazing piece of software that it used in 92%
of Top500 supercomputers,
all sort of servers, mobile phones, most TVs and routers.
And still, there is a single Linux kernel project thanks to the
copyleft license.
Everyone works on Linux because they cannot keep away their own contributions;
they have to share them with the community.
Even the ARM architecture, where each ARM licensee went their own way,
is going to get its cleanup.
Because the code for all of them is already in the Linux kernel repository.

IBM makes money out of Linux by providing services. And IBM is even a
top contributor to the Linux kernel.
Would IBM hypothetically prefer to have the Linux kernel developed
under the Apache Foundation?

OO/LO are in this critical point where they can repeat the Linux
copyleft success story
and help ODF dominate the document formats.

OO/LO is a complicated piece of code and will probably require big
architectural changes.
Having an Apache OpenOffice and a LibreOffice will slow down progress
in major changes.

Simos

-- 
Unsubscribe instructions: E-mail to discuss+help@documentfoundation.org
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.documentfoundation.org/www/discuss/
All messages sent to this list will be publicly archived and cannot be deleted

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.