A nice feature I have implemented for Apache OpenOffice 3.4 released in May 2012, the new native SVG Import (see here), will make an appearance to the next LibreOffice version. It replaces the former SVG import greatly improving user experience and removing dependencies of six external libraries, also benefiting startup (a little bit). It has been integrated to the LibreOffice trunk for their 3.7 version recently (see here). This is also true for some more AOO features and bug fixes (e.g. the long missing LineCaps). These features are not yet promoted on the 3.7 feature page, but I hope it will be done as well and fancy as they usually do it for big features.

I am very happy about this, I write features at Apache for the 'public good', thus I intend them to be useful to as many users of the OpenOffice codebase as possible. It shows the flow of source between Apache OpenOffice and projects based on the general OpenOffice codebase thanks to the permissive Apache 2 License (ALv2). I added my stuff to Apache with the goal to get it into all OpenOffice derivatives, and that's exactly what ALv2 allows, as this example shows. That and 'having a choice' is what OpenSource is about from my point of view. This example demonstrates how code flows freely from AOO to LO, and why there is no need for misleading statements about where to place new code; real OpenSource gurus always knew this anyways. I can only encourage every OpenSource developer who wants to get his code in all OpenOffice derivatives to do it this way: Add it to Apache OpenOffice under ALv2 and you are done!

The other way is to distribute your code to all projects yourself which sadly requires more work (not only for you, but for everyone, BTW), but at least it is a fair thing to do.

It also shows that the main requested thing in every discussion on the net - to simply cooperate again - is already in place, seen from the Apache point of view. Hopefully the other way around will somehow be started too, in whatever way.

One caveat is that the fixes and enhancements I have already done (It's never perfect in the first shot :-)) for this feature in the trunk for AOO 4.0 will be missing eventually because it's not easy for a third person to identify all the relevant changes which are part of this. I did not check that, but I hope it was done in a careful and responsible way (what I assume, they are experienced and trusted OpenSource guys). In the current state it will need watching out for changes and some manual work all the time. I clearly wish this to happen for the users of my feature. Or the other way around - I do not want to be blamed for known and already fixed bugs ;-)

All this is much simpler for the normal case of using Apache software; it is intended to use source releases of any Apache projects and do whatever you want based on it (that's the Apache way). That way, you get the next bunch of enhancements and fixes automatically at the next release, no need to go through all fixes/commits and hand-pick the needed (where the hard part is to identify relevant parts when you've not done the changes yourself).

In this model it is also common to commit back to the Apache project - not only because OpenSource is about doing this, but for simple complexity reasons. Even big companies have nowadays learned the lesson (sometimes the hard way) that it is nearly impossible to keep an own branch of software synched to the goodies coming from the source (and it's a waste of resources anyways). Maybe there are better (and bidirectional :-)) ways of collaboration in the future; a move to less-restrictive licenses seems already to happen, hand in hand with rebasing on Apache OpenOffice code. I would not want to be the guy to e.g. integrate the next big changes I'm working on for Apache OpenOffice (see here, already more than 340.000 lines of diff).

For the advantage of all users, I encourage everyone interested in working on the OpenOffice codebase to draw his own conclusions. Mine are clear; help us at Apache or be so kind to release it on Apache, too. That's the way to reach the broadest possible user base for your feature. A lot of users (download numbers here) will thank you for it :-)