Stuff Michael Meeks is doing

This is of course my view, and I hope yours, but naturally it is worth presenting at least some rational and working for this conclusion. Unfortunately, there are so many reasons why TDF and LibreOffice are done right, that I can't list them all in linear time. However, I'll try to address some of the major ones recently raised by congenital worriers.

LibreOffice is vendor neutral

LibreOffice does not belong to any single vendor, neither is it a single vendor's product. To characterise it that way is just silly. We have full-time developers from Novell, RedHat, Canonical and Lanedo working currently, with many key volunteer contributors, and contributions from other companies and distributions eg. CodeThink's Unity integration work, or the many Google Summer of Code students we've enjoyed working with. No-one is excluded from our governance - oh, except over-dominant corporations, there are strict limits in our bylaws on the proportion of representation (one third) that any single company can have in any of our key institutions. Elections will be by a fair method (Single Transferable Vote), and be participated in by all significant contributors equally. The contrast with the mess of ridiculously gerrymandered governance, with layers of stacked privilege given to a single corporation in a previous project is quite stark.

SUSE is the largest corporate contributor to TDF, though we are small compared to our huge group of motivated volunteers. My aim is to ensure that no vendor dominates (including SUSE): and that there is room for all contributors. Looking at our structures: the Steering Committee, Membership Committee, and the Engineering Steering Committee, we seem to be doing well there.

Of course, having vendor neutrality around open standards is also good, but this is someone else's fight. I'm interested in the best result Free Software implementation possible, with a fun community to stand behind it, rather than the different good of enabling competition between implementations.

LibreOffice is robust to participants leaving

What if SUSE, RedHat and Canonical stopped contributing to Free Software Office suites tomorrow !? would LibreOffice and TDF survive ? This seems like an extremely outlandish eventuality, it is hard to imagine a successful Linux Desktop without LibreOffice, and there is no functional alternative. But lets address it - would we survive - the simple answer is - yes, but how ?

Well, the answer is simply diversity - we have lots of contributors from all around the world: all are welcome to contribute to LibreOffice. Many of them have contributed code, and own part of the LibreOffice franchise: it is their code. We are all (employed or not) trying to build personal loyalty to the project, in itself, rather than to a corporate sponsor. We have volunteers who manage tinderboxes, and can build for each platform we support, we have hardware to do that scattered around the world. We use infrastructure services donated by many friendly organisations - like freedesktop, with many kind mirror sites. Our infrastructure budget is small.

Furthermore, in order to make this unlikely eventuality even less potentially painful, we're rapidly working to remove one of our big bottlenecks: building on Windows. Currently to build on Windows, you have to buy expensive, proprietary Microsoft compilers - we are rapidly completing the gnu-make migration, as an initial step to much more reliable, and repeatable cross-compilation to Windows from Linux. When this is complete, almost anyone with a PC should be able to do releases. If you want to help out, here is a great task to get involved in.

How does this compare ? for OpenOffice.org almost all release builds came from a proprietary build environment inside Hamburg, run by a small team of build engineers. That single point of failure contrasts with a team volunteers and paid staff (we tend not to distinguish), with a shared responsibility and an open build process (modulo the hard-to-avoid windows compiler problems).

Linux distributions are safer with LibreOffice

As a Linux distro, clearly flocking with the other distros, and sharing your testing, bug-fixes, packaging problems, and integration code makes an incredible amount of sense. All known Linux distributions are currently doing this work in partnership with LibreOffice for their next releases. Doing anything else would be simply silly. Each major distro has great hackers working on the project, and with LibreOffice's time based release schedule, have assurance that it will be possible to get a known-good version, into their release in a predictable way. Of course, all of that is in contrast to the extra stability guarenteed by a diverse contributor base.

LibreOffice has a different, and better QA model

This process is still getting started, in large part due to the rush to get 3.3 out and stabilise that, early work on 3.4, in particular merging changes from Oracle took a hit. Similarly, building on windows is far less than ideal, both from a performance and reliability perspective. Having said that much progress is being made. I'll write up some more explanation of what a time-based release really means shortly, but suffice it to say that this avoids the multi-month release slips that we've seen in OpenOffice.org. It is also the same model that is used by both GNOME and KDE. This also gives more flexibility to the end-user, they can choose the required quality - either an older, more stable version say: 3.2.16, or a newer less stable one 3.3.3, or a very new one 3.4.0 with more problems. It is a matter of choosing your upgrade path carefully. That can make comparisons difficult - a release that has slipped by three months is somewhat less stable than a point-three release (for example).

Division is (sadly) sometimes necessary

Forming TDF caused a lot of heart-ache; in particular Oracle choosing not to join was extremely sad. Clearly, it takes two to go in different ways. Having said that, whenever I've written about it I've pointed out that Oracle were (and still are), encouraged to join in with The Document Foundation. Their influence, and contribution over many years would immediately give them a large say, and I'd love to work with their great engineers again. Though, of course, there is much public uncertainty around them dis-continuing commercial development.

In the light of that uncertainty, having a smooth, safe and predictable upgrade route, backed by commercial support for any users concerned about the future of OO.o is a good thing. There is also a welcoming new home for all who contribute, with good governance to match.

The Document Foundation champions ODF

I would have thought this was pretty clear; our announcement made clear that we are working with OASIS. We have a clear statement on OOXML. It reads like this:

The Document Foundation promotes and supports Open Standards. Among them OpenDocument Format (ODF), that offers many benefits to citizens, governments and businesses, and sets the documents and users free from proprietary lock-in.
The reason we enthusiastically promote ODF, is that we believe that no other standard provides the right level of vendor neutrality with widespread participation and implementation. We believe that ODF's absence of lock-in future proofs investment in both documents and software, to the great benefit of all citizens, governments and businesses. The Document Foundation does not promote nor support OOXML.

That aims to be clear; it seems so to me.

We are transparent about our contributors

We publish statistics on code contribution, to be sure these are not updated as often as they could be - but there are a number of things to be getting on with. Nevertheless, although all the contribution data, our code, and git repositories are public, and any half-way competent 'community exprt' type should trivially be able to analyse them themselves; we provide updates. The question of regularity of contribution was addressed recently by Cedric in How many frequent contributors to LibreOffice?. We publish more general stats to show trends: eg. Updated LibreOffice contribution stats. Unfortunately, judging the volume of contribution is excessively difficult - some simple changes can be automated and produce huge commits, while other key fixes can take longer and yield a single line. Measuring full-time-equivalents from commit lots is (as far as I know) an un-solved problem. Details as to contributors to translations are also available from each language's page in pootle.

Anyhow, what we have provides a high degree of transparency. Sun gathered, but did not publish their equivalent statistics. No good purpose is served by lying about our contributor base - clearly we need and want more developers, and there is a place for anyone that wants to actively contribute to be effective for software freedom. Furthermore, this contrasts with the inflated estimates of the past, supposedly OpenOffice had thousands of contributors in 2005, and Novell, RedHat and Intel's (much smaller) contribution then was called significant; yet we contribute many more full-time paid contributors these days.

In conclusion

While there is always scope for improvement, in my view TDF gets many things extremely right. We encourage contribution by vendor neutrality, and not putting barriers in people's way (such as ownership aggregation paperwork). We have a meritocratic, and yet fair membership and governance model. We have a competent and well advised steering committee.

Finally - we are executing, instead of sitting about talking, we are attracting contributors mentoring them, reviewing their code and including them into productive membership of the TDF family. Together, we are cleaning up the code-base, improving our build and release process, adding new features, undoing past mistakes, and providing an inspiring model for others to copy. Personally, I see it as a privilege to have been, and to be part of that story.