NeoOffice vs. OpenOffice.org: possible cooperation models? Is cooperation possible?
I thought a bit about possible methods or models of cooperation between
OpenOffice.org (GNU LGPL licensed software) and its fork
NeoOffice (GNU GPL licensed; because of its focus, it is
available only on the proprietary operating system, Mac OS X). In the past, there were some issues
between both projects that I still do not understand completely; maybe because I didn't care about
Mac OS X port until recently and I was not involved in these issues (I concentrate mainly on
technical issues that I think both projects benefit from!).
I'm working on the OpenOffice.org project, thus please read everything here with that in
mind. I never even thought about working on NeoOffice because its code is forked and there still is
no upstreaming process implemented in their development. (Compare with
ooo-build - a "friendly fork". At the beginning I was very anti-
ooo-build oriented because of the very slow upstreaming process there but we communicated fixes very
well and the cooperation with distributors' oriented ooo-build is now almost perfect and both sides
clearly benefit from it). But with NeoOffice, the situation is different. If I want to fix
something in NeoOffice, it also has to be fixed also in OpenOffice.org as well. As a consequence it
is much easier for me to fix things in OpenOffice.org directly. Fixing it in both projects is
inefficient.
And what about fixing issues in NeoOffice only without contributing back to the originating project,
OpenOffice.org? I have to say that I haven't even thought about it. But people doing so probably
have their motives. But as I said above, I only care about technical issues, so I can think of
following reasons to do so:
- the code is NeoOffice only, it does not affect or it does not exist in OpenOffice.org at
all. This is legitimate reason - OpenOffice.org for Mac OS X is not yet as advanced as on other
platforms and it is not possible to integrate all the functionality NeoOffice contains
- the quality of the code is not up to the quality of OpenOffice.org standards
- the architecture of the code doesn't follow the architecture of the rest of the code
But there probably are also other reasons (I'd be glad to hear them from you so I can see the whole
picture from both sides). I'm mainly interested in the motivation to not share the generic patches
that affect both projects. Have a look at ooo-build: at the beginning, the project was several
development milestones behind the mainstream OpenOffice.org because of the boring process connected
with re-diffing changes not yet integrated into mainstream OpenOffice.org, checking the build, and
then again concentrating on their own changes.
After several (I can imagine how Michael Meeks hated me ;-) rounds of discussions and bringing
existing problems to the discussion table, we realized that there are almost no problems and both
parties can benefit from working together closely - OpenOffice.org working for distributors'
ooo-build and ooo-build working for OpenOffice.org.
I see the same problem on NeoOffice side. I understand that developers probably concentrate more on
the user friendliness side of the product and thus they are a bit behind OpenOffice.org. This is
understandable - it is no easy job to follow all the changes happening in OpenOffice.org CVS tree if
you have to implement your changes in many source files of the project and even add your new
code. I see the same problem when working on aquavc01 child workspace. Because of the fact it is
a development cws, there is no schedule for its integration, so we have to resync it very often to
bring latest changes in OpenOffice.org milestones, and it is time consuming work. And boring work to
say the truth. But we have to do so, because we are not that fast with development to integrate it
yet. This clearly is a point where we can cooperate to make both OpenOffice.org project and
NeoOffice project even better and to save the managerial burden connected with the different code we
have - having the code in OpenOffice.org means it also gets tested also on other platforms thus it
gets tested by more people.
So the above is a clear (at least from my technical point of view) win for both sides! Where else
could we cooperate? I again have to look at ooo-build. There is close cooperation - we share our
Wiki (provided by OpenOffice.org),
Bonsai,
LXR and
tinderbox (provided
by ooo-build) and other infrastructure as well. It helps both projects - shared administration,
shared costs. I think infrastructure is a place where both OpenOffice.org and NeoOffice can
cooperate too. Ah, I almost forgot about
OOoPlanet - also run
by ooo-build project!
Before I even started to think about this issue, I thought if both sides would like to cooperate at
all. Of course I do not know about NeoOffice (as I do not follow it), but for OpenOffice.org it
clearly would be interesting to integrate applicable fixes and thus make it even better. Do you
know? From what I read on Neo forums, the attitude to OpenOffice.org project and developers is not
very good - e.g. after Eric's
presentation at
OOoCon 2005 at Koper, Neo people's financial income from donations was lower than they have expected
and they feel it was a dirty trick to them. But even if it looks so, it was not meant to be.
The OpenOffice.org team is listening to its users on Mac OS X platform and they
want
OpenOffice.org without the X11 subsystem - so working on native port is a logical step forward for
us! NeoOffice already is running without X11, but some people still prefer running OpenOffice.org
instead. We want to make their experience smoother, and without X11. The port is not progressing as
fast as Eric expected - mainly because of lack of knowledge and experiences with Mac OS X on the
OpenOffice.org's developers side, but we are getting there, but slowly. Unfortunately we can't use
the work done on NeoOffice's side. Not only because it is GNU GPL licensed (OpenOffice.org is GNU
LGPL licensed) but also because of technical reasons (UI of NeoOffice is implemented using Java
instead of C or C++, thus potentially slower than the native code). But this is no reason for not
sharing the common code as pointed above.
I'm still mixed. I'm probably missing some (either technical or political) reason not to share the
code or I simply haven't yet read some clear statement from NeoOffice developers with their
reasoning to not share the code. So if you know where to read it, please point me to it. Thank you.
Now back to real work ;-)