Apache OpenOffice.org

Rob Weir reports that there are 75 proposed committers signed up for
the Apache OpenOffice project.
http://wiki.apache.org/incubator/OpenOfficeProposal

I don't know what this will mean for us in the OOo and LibO docs
groups, but I am concerned about the potential for further
fragmentation of a small group of docs people into working on several
projects.

We really need to work on better ways to reuse material without time
consuming rebranding -- by automating everything we can and choosing
not to do some non-essential things that can't be automated. I have a
paper mostly written on this topic, which I'll make available when I
get home late next week.

Jean

The list of committers include: "It is perfectly all right to have your name on this list if you contribute in another way than to commit program code (please maintain alphabetical ordering)". So, the list includes non-dev people. There is no breakdown in committer categories as it is most likely to their advantage to not do so. It gives people the impression that all on the list will advance the code ... or in our case, for the documentation team, that they may have a large documentation contingent or for the marketing team ... etc.

It is reasonable to expect that whoever had not moved to the TDF/LibreOffice would be interested in joining the new OpenOffice project.

The fact remains that, LibreOffice has now transplanted itself as the new codebase of choice and that the "Legacy of OpenOffice.org" chart on the ASF page has been rewritten and LibreOffice is now the new base from which adaptations will now be made of.

I wouldn't worry too much about the 75 or more committers. We are definitely on the right path and I have to say that it is a pleasure to contribute to LibreOffice and that, this, by itself, is one of the greatest reason why people will continue to join the TDF/LibreOffice project. The cooperation across the different teams as well as the quality of work and friendly exchange of ideas are the attractive elements that keep people interested in LibreOffice.

A big thanks to all contributors and to your future contributions to LibreOffice.

Cheers

Marc

Hi :slight_smile:

I don't think we have to worry about it.

It's easier for whoever owns OpenOffice to copy the LibreOffice documentation
and then tweak it a bit than the other way around. So, LO will increasingly be
seen as 'upstream' and the best place to work on stuff. To modify it for
downstream just rename a chapter & delete sections on functionality they don't
have.

TDF are unlikely to chase people through legal action over a few screen-shots
or LO or TDF branding appearing in other people's documentation. In a way it
would be free advertising.

I guess that to help ODFauthors with future releases of LibreOffice
Documentation a lot of re-working sentences could be done to avoid words that
are specific to LO. It's an impossible task for this release though. There is
an opportunity for ODFauthors to promote themselves as a group worth paying (or
resourcing) to produce documentation for various projects such as KOffice,
AbiWord&Gnumeric as well as OpenOffice.

Regards from
Tom :slight_smile:

I don't know what this will mean for us in the OOo and LibO docs groups, but I am concerned about the potential for further fragmentation of a small group of docs people into working on several

projects.

If The Apache Software Foundation does what they normally do with
projects, there will not be a binary release of Apache OpenOffice.org.
There will only be a source code release.

The onus will be on third parties to deliver binaries.

Given the history of third party distribution of OOo binaries, I suspect
that tracking the third parties that deliver binaries that are either
based upon, or exclusively Apache OpenOffice.org code to non-trivial.

I don't see typical OOo end-users grabbing the Apache OpenOffice.org
source code, and compiling it for their system.

We really need to work on better ways to reuse material without time consuming rebranding

+1

OTOH, I'm not sure how much material will be reusable.
In updating _OOo in a Multi-Lingual Environment_, my original theory was
to include OOo4Kids, and OOoLight. Due to the differences between those
programs, and OOo, I had to either write: "This can not be done using
OOo4Kids" or else write a completely different set of instructions.
Instructions that, as often as not, did not work with either OOo, or LibO.

by automating everything we can and choosing not to do some

non-essential things that can't be automated.

The practical issue is:
* Which existing OOo derivatives/variants should the Documentation
Project track;
* What criteria should be used, to determine which new
derivatives/variants should be tracked;

Existing OOo derivatives/variants are:
# FLOSS:
* GO-Oo;
* BrOffice;
* LibreOffice;
* OOo4Kids;
* OOoLight;
* OpenOffice.org;
* OxygenOffice;

# Proprietary:
* 602Office;
* Co-Create Office;
* EuroOffice;
* KaiOffice;
* MagyarOffice;
* MyOffice 2007;
* NeoOffice;
* NextOffice;
* OfficeOne;
* OpenOffice Pro;
* OpenOffice UX PL;
* OpenOffice PL;
* RedOffice;
* StarOffice/Oracle OpenOffice;
* Symphony;
* ThizOffice;
* UPOffice;
* WPOffice;

I put that list together, based on various pages on the web. Not all of
those programs are still distributed.

jonathon
- --
If Bing copied Google, there wouldn't be anything new worth requesting.

If Bing did not copy Google, there wouldn't be anything relevant worth
requesting.

                              DaveJakeman 20110207 Groklaw.

Just thought I would add the two comments to the list. The comments are taken from their websites.

Cheers

Marc

Do we want to track KOffice and Calligra as well? They have some
interesting ideas that we should probably look at.

For docs or for devs?

Rogerio

I was thinking of following the projects, maybe even borrowing some good
ideas from each. I like some of the KWrite/Calligra page work layouts
but dislike how Kwrite works.