Fri Jul 28 14:43:13 CEST 2006

NeoOffice vs. possible cooperation models? Is cooperation possible?

I thought a bit about possible methods or models of cooperation between (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 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 as well. As a consequence it is much easier for me to fix things in directly. Fixing it in both projects is inefficient.

And what about fixing issues in NeoOffice only without contributing back to the originating project, 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 at all. This is legitimate reason - 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 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 because of the boring process connected with re-diffing changes not yet integrated into mainstream, 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 - working for distributors' ooo-build and ooo-build working for

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 This is understandable - it is no easy job to follow all the changes happening in 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 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 project and NeoOffice project even better and to save the managerial burden connected with the different code we have - having the code in 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, 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 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 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 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 team is listening to its users on Mac OS X platform and they want 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 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'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 ( 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 ;-)

Posted by Pavel | Permanent link | File under:, Mac OS X