Stuff Michael Meeks is doing

This is my (in)activity log. You might like to visit Collabora Productivity a subsidiary of Collabora focusing on LibreOffice support and services for whom I work. Also if you have the time to read this sort of stuff you could enlighten yourself by going to Unraveling Wittgenstein's net or if you are feeling objectionable perhaps here. Failing that, there are all manner of interesting things to read on the LibreOffice Planet news feed.

Older items: 2021: ( J F M A M J J A S O N D ), 2019, 2019, 2018, 2017, 2016, 2015, 2014, 2013, 2012, 2011, 2010, 2009, 2009, 2008, 2007, 2006, 2005, 2004, 2003, 2002, 2001, 2000, 1999, legacy html


2011-12-31: Saturday

2011-12-30: Friday

2011-12-29: Thursday

2011-12-28: Wednesday

2011-12-27: Tuesday

2011-12-26: Monday

2011-12-25: Sunday

2011-12-24: Saturday

2011-12-23: Friday

2011-12-22: Thursday

2011-12-21: Wednesday

2011-12-20: Tuesday

2011-12-19: Monday

2011-12-18: Sunday

2011-12-17: Saturday

2011-12-16: Friday

2011-12-15: Thursday

2011-12-14: Wednesday

2011-12-13: Tuesday

2011-12-12: Monday

2011-12-11: Sunday

2011-12-10: Saturday

2011-12-09: Friday

2011-12-08: Thursday

2011-12-06: Wednesday

2011-12-06: Tuesday

2011-12-05: Monday

2011-12-04: Sunday

2011-12-03: Saturday

2011-12-02: Friday

2011-12-01: Thursday

2011-11-30: Wednesday

2011-11-29: Tuesday

2011-11-28: Monday

2011-11-27: Sunday

2011-11-26: Saturday

2011-11-25: Friday

2011-11-24: Thursday

2011-11-23: Wednesday

2011-11-22: Tuesday

2011-11-21: Monday

2011-11-20: Sunday

2011-11-19: Saturday

2011-11-18: Friday

Trying to visualise Open Source OpenOffice.org derivatives

Caveats

The caveats. As to my motivation (please remember to play the man not the ball): I do not intend to make anyone afraid, uncertain or doubtful. If graphs scare you - please look away at this point. These graphs are built from estimates, hopefully they are fairly un-controversial ones, I detail them at the bottom. This is probably misleading in all sorts ways I didn't discover yet. My hope is that it provides a more helpful picture of the world today than this history graph that gets a frequent airing. By rendering only the last two years, we de-clutter lots of lapsed projects, and by not rendering version numbers we can use perceptual area for showing something more useful: an estimate of user-base. As/when I discover major bugs I'll update this, it is a work in progress:

A user-base & release picture

Notes:

This is clearly where it gets hairy. I've tried not to offend people, though I've tried to round against my obvious bias. Also, drawing very thin boxes in draw gives some rounding imprecision.

Everything is meaningless

Of course user-base is a poor heuristic for future relevance. That would be driven by features and marketing, as provided by developers and contributors. Potentially graphing contributors in a similar way would be possible, but that was harder to acquire in half an hour. It would be ideal to render more than a rectangle - showing the evolution of the user-base over time, but I don't have that either, and there is some considerable estimation here. Finally, this doesn't include AOOI, which has yet to release a product, it'll be interesting to see how things change when they do.

2011-11-17: Thursday

2011-11-16: Wednesday

2011-11-15: Tuesday

2011-11-14: Monday

2011-11-13: Sunday

2011-11-12: Saturday

2011-11-11: Friday

2011-11-10: Thursday

2011-11-09: Wednesday

2011-11-08: Tuesday

2011-11-07: Monday

2011-11-06: Sunday

2011-11-05: Saturday

2011-11-04: Friday

2011-11-03: Thursday

2011-11-02: Wednesday

2011-11-01: Tuesday

2011-10-31: Monday

2011-10-30: Sunday

2011-10-29: Saturday

2011-10-28: Friday

2011-10-27: Thursday

2011-10-26: Wednesday

2011-10-25: Tuesday

2011-10-24: Monday

2011-10-23: Sunday

2011-10-22: Saturday

2011-10-21: Friday

2011-10-20: Thursday

2011-10-19: Wednesday

2011-10-18: Tuesday

2011-10-17: Monday

2011-10-16: Sunday

2011-10-15: Saturday

2011-10-14: Friday

2011-10-13: Thursday

2011-10-12: Wednesday

2011-10-11: Tuesday

2011-10-10: Monday

2011-10-09: Sunday

2011-10-08: Saturday

2011-10-07: Friday

2011-10-06: Thursday

2011-10-05: Wednesday

2011-10-04: Tuesday

2011-10-03: Monday

2011-10-02: Sunday

2011-10-01: Saturday

2011-09-30: Friday

2011-09-29: Thursday

2011-09-28: Wednesday

2011-09-27: Tuesday

2011-09-26: Monday

2011-09-25: Sunday

2011-09-24: Saturday

2011-09-23: Friday

2011-09-22: Thursday

2011-09-21: Wednesday

2011-09-20: Tuesday

2011-09-19: Monday

2011-09-18: Sunday

2011-09-17: Saturday

2011-09-16: Friday

2011-09-15: Thursday

2011-09-14: Wednesday

2011-09-13: Tuesday

2011-09-12: Monday

2011-09-11: Sunday.

2011-09-10: Saturday.

2011-09-09: Friday.

2011-09-08: Thursday.

2011-09-07: Wednesday.

2011-09-06: Tuesday.

2011-09-05: Monday.

2011-09-04: Sunday.

2011-09-03: Saturday.

2011-09-02: Friday.

2011-09-01: Thursday.

2011-08-31: Wednesday.

2011-08-30: Tuesday.

2011-08-29: Monday.

2011-08-28: Sunday.

2011-08-27: Saturday.

2011-08-26: Friday.

2011-08-25: Thursday.

2011-08-24: Wednesday.

2011-08-23: Tuesday.

2011-08-22: Monday.

2011-08-21: Sunday.

2011-08-20: Saturday.

2011-08-19: Friday.

2011-08-18: Thursday.

2011-08-17: Wednesday.

2011-08-16: Tuesday.

2011-08-15: Monday.

2011-08-14: Sunday.

2011-08-13: Saturday.

2011-08-12: Friday.

2011-08-11: Thursday.

2011-08-10: Wednesday.

2011-08-09: Tuesday.

2011-08-08: Monday.

2011-08-07: Sunday.

2011-08-06: Saturday.

2011-08-05: Friday.

2011-08-04: Thursday.

2011-08-03: Wednesday.

2011-08-02: Tuesday.

2011-08-01: Monday.

2011-07-31: Sunday.

2011-07-30: Saturday.

2011-07-29: Friday.

2011-07-28: Thursday.

2011-07-27: Wednesday.

2011-07-26: Tuesday.

Some brief thoughts on Project Harmony

Seeing Mark's blog over the weekend promoting corporate ownership aggregation reminded me of an overdue response to Project Harmony. Mark writes compellingly, as normal, I'm just not so convinced about the moral excellence of generosity, without sensible safeguards, towards profit chasing corporations. But anyhow, Project Harmony:

Having initially been involved with the project, I'm rather disappointed by its output. There are many applications of Harmony that are problematic legally, pragmatically, ethically and from a software freedom perspective. I've written about the practise of to-corporate Copyright Assignment though that title would better be expanded to certain licenses, such as Harmony's, which are tantamount to (C) assignment enabling an unhelpful corporate ownership aggregation. Others writing in detail on this are Bradley Kuhn, Richard Fontana, Dave Neary and Simon Phipps.

My two cents is that, best practise is the Free Software norm, where the inbound contributor agreement (CA) is identical to the outbound license. There is some extent to which Harmony does improve things - it is rather like a hypothetical ISO standard for weapons sales. Such a standard, with clear escrow provisions perhaps, might help accelerate arms sales, making them cheaper, and perhaps may have a legitimate use: helping some defend themselves and others under threat. The only slight down-side being the scope for littering the world with yet more unwanted land-mines. In the same way I fear that Harmony has the potential to make acceptable the corporate control Free Software projects, bringing many complications. There are many rather good reasons not to sign a CLA, often focued on the horrible imbalance of power that they create. Here is one such specimen reason focused on the corporate sphere:

Why Harmony's CLA can be dangerous

Broken options - the one way street

Consider a BSD licensed Harmony option. The BSD license gives no out-bound patent rights to the software, so it is easy to end up with code that requires a separate patent license to effectively use it. Now - consider that you have assigned your patent rights under a Harmony CLA to FooCorp, you assign:

"For patent claims ... which You own, control or have the right to grant, now or in the future, You grant to Us [FooCorp] a perpetual, worldwide, non-exclusive, transferable, royalty-free, irrevocable patent license with the right to sublicense these rights to ..."

By signing this - you have comprehensively given away your patent rights, to the code you contributed to FooCorp, but interestingly, you get no license granted back, either by the outbound BSD license or by the Harmony agreement. That is deeply generous but highly broken. It is thus easy to create a situation, where only FooCorp, and its for-fee licensees can use the project's code.

No self defence provisions

Another problematic down-side follows from this. If there is any ethical justification for acquiring patents it is self defence (from the madness of the real world). More sane non-copy-left outbound licenses have reciprocity clauses to enable self defense against patent aggression. Lets look at Apache's:

3. ... each Contributor hereby grants to You a perpetual, worldwide ... irrevocable (except as stated in this section) patent license ... If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) ... then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.

Which means - if MegaCorp sues me for patent infringement, while they are using my own patented code: I get to use that patent to defend myself. So how does that jive with the Harmony CLA ? Sadly, none of that nice termination logic is there - you just gave away your current and future patent rights completely. Pathologically in the previous (BSD outbound) case; quite feasibly FooCorp can immediately threaten you for patent infringement on their work. Add some simple corporate mechanics such as making FooCorp a shell company, even with an Apache licensed project FooCorp's parent can sue you for using their code.

Third parties get to tread on you

That situation can be seen in a different way. Say you are defending yourselves in some patent war cf. the mobile space. Perhaps your major defensive tool is a patent covered by code you've included into FooCorp's product. Unfortunately, whatever the outbound license used (perhaps it has a sensible termination provision) the patent license comes, not from you, but from FooCorp. Of course perhaps you only discover when it comes to defending yourself that FooCorp already sold your code + patent rights to MegaCorp under a confidential proprietary license some years back; better hope you keep them sweet by not competing with them.

A FUD factory - who knows what you're missing ?

Thus FooCorp is sitting pretty, on its pile of aggregated patent and copy rights, and has a great marketing tool to sell their proprietary licenses to other companies: "better safe than sorry" - "who knows what key rights you might be missing; we don't ?" - "sign here for safety". Similarly other (big) companies are incentivised to only appear to work inside the community, limiting their exposure by taking bespoke, non-reciprocal, proprietary licenses. That can make project contributors feel safe - "MegaCorp is distributing OpenBaa under the LGPL too right ?" when in fact they have a neat way of avoiding giving you key rights, via paying FooCorp.

I initially tried to encourage the Harmony project to address this sort of issue, but without success.

The net effect - more complexity on top of the license

One of the aims of Project Harmony is to make review easier for lawyers, yet it conceals this non-reciprocal loose your job minefield. By parameterising 'license', and including the scope for future license change it provides a very clear definition of the rights you surrender now and in the future, and a very vague aspiration to the rights you get back. Thus, you cannot read the Harmony CLA without also paying very careful attention to its interaction with the selected outbound license as well. So - I am fairly convinced that large companies will not be signing such an 'Entity agreement'. If they need to contribute there are plenty of ways to look like they are doing that, eg. via a shell entity, or by letting employees contribute as individuals.

Where is a CLA useful ?

Some projects are not blessed with a copy-left license. That means that every time they see a patch floating across their mailing list, the ownership of it can be less than clear; after all, it is fine to claim that your changes to a non-copy-left code-base are proprietary, even after you happened to publish them. Some explicit statement can help in this case to clarify that you are indeed contributing this code in good faith - paperwork can do that. Also many non-copy-left licenses have no "or later version" upgradeability in them via a license steward (the FSF provides that for the GPL). An example of that is the Apache license. In that context some CLAs make some sense.

Of course, it probably makes more sense, to have a copy-left license, with a clear license steward. That makes it clear that distributed changes are licensed under the project license, and can be easily merged as/when they are published. This is the beautiful inbound equals outbound symmetry that underpins most Free Software projects.

A quick reflection on the barrier to entry to non-copy-left projects with sign-and-fax-in assignment/license documents makes you wonder how they have survived. Perhaps the un-written social contract around respecting a project's license and not soft forking it without good reason has protected them thus far from being hollowed out by more fun, free-wheeling, copy-left variants. It seems that that unwritten contract is under quite some strain these days; who knows what the future holds there.

Conclusion

I hope that examining just one weakness in some detail highlights that, while Harmony may have some uses, in general a much better approach is to use a uniform copy-left license that gives the same rights and protections to all. That also reduces the scope for corporate malfeasance that will ultimately betray your generosity.

2011-07-25: Monday.

2011-07-24: Sunday.

2011-07-23: Saturday.

2011-07-22: Friday.

2011-07-21: Thursday.

2011-07-20: Wednesday.

2011-07-19: Tuesday.

2011-07-18: Monday.

2011-07-17: Sunday.

2011-07-16: Saturday.

2011-07-15: Friday.

2011-07-14: Thursday.

2011-07-13: Wednesday.

2011-07-12: Tuesday.

2011-07-11: Monday.

2011-07-10: Sunday.

2011-07-09: Saturday.

2011-07-08: Friday.

2011-07-07: Thursday.

2011-07-06: Wednesday.

2011-07-05: Tuesday.

2011-07-04: Monday.

2011-07-03: Sunday.

2011-07-02: Saturday.

2011-07-01: Friday.

2011-06-30: Thursday.

2011-06-29: Wednesday.

2011-06-28: Tuesday.

2011-06-27: Monday.

2011-06-26: Sunday.

2011-06-25: Saturday.

2011-06-24: Friday.

2011-06-23: Thursday.

2011-06-22: Wednesday.

2011-06-21: Tuesday.

2011-06-20: Monday.

2011-06-19: Sunday.

2011-06-18: Saturday.

2011-06-17: Friday.

2011-06-16: Thursday.

2011-06-15: Wednesday.

2011-06-14: Tuesday.

2011-06-13: Monday.

2011-06-12: Sunday.

2011-06-11: Saturday.

2011-06-10: Friday.

2011-06-09: Thursday.

2011-06-08: Wednesday.

2011-06-07: Tuesday.

2011-06-06: Monday.

2011-06-05: Sunday.

2011-06-04: Saturday.

2011-06-03: Friday.

LibreOffice progress to 3.4.0

Today we released 3.4.0, there is a great list of new features, specific to LibreOffice available (expertly assembled by Marc Pare and others). Each should also be credited so some of the depth of the (code) developer community is apparent, this is of course in addition to our extensive credits page (kept up to date by a volunteer of course). This is the first major release containing code from many of our new volunteers which is exciting. Of course, there are some great improvements there, I like the named range / data-pilot work that makes it easy to extend the data range you're working on without manually editing perhaps ten data-pilots depending on it but there are a load more. Some of the changes are invisible, and/or behind the scenes - so I thought I'd expand on them here.

The incredible shrinking codebase

First - ridding ourself of sillies - there is lots of good work in this area, eg. big cleanups of dead, and unreachable code, dropping export support from our (deprecated for a decade) binary filters and more. I'd like to highlight one invisible area: icons. Lots of volunteers worked on this, at least: Joseph Powers, Ace Dent, Joachim Tremouroux and Matus Kukan. The problem is that previously OO.o had simply tons of duplication, of icons everywhere: it had around one hundred and fifty (duplicate) 'missing icon' icons as an example. It also duplicated each icon for a 'high contrast' version in each theme (in place of a simple, separate high contrast icon theme), and it also propagated this effective bool highcontrast all across the code bloating things. All of that nonsense is now gone, and we have a great framework for handling eg. low-contrast disabilities consistently. This also reduces run-time memory consumption (we have to cache the .zip theme's directory), and of course binary installation and download size shrinks (we ship several themes to taste) - here is a pretty picture:


The incredible shrinking footprint on Windows

When we first released LibreOffice, in place of the individual install set per language - duplicating the code, artwork, templates, etc. many tens of times on each server we switched to bundling lots of languages (and also the run-time adapted BrOffice branding) into a single package. That shrunk our mirror load from 76Gb down to 11Gb for 3.3, which is now for 3.4 down to 7.6Gb a handy win (of ~70Gb) for mirror admins, making us more agile, and appreciated by our fantastic mirror network I hope. To achieve this, in consultation with the l10n team, Kendy worked hard to split out our help to the wiki - so you can browse it on-line at http://help.libreoffice.org. That of course helps Linux users' space-constrained live-CDs more useful too.

With that work in-place, we managed to cram the top fifty languages into only 225Mb on release, which (sadly) left the remaining languages in a rather larger 265Mb download. In 3.4.0 down to improvements such as the them work above, sharing templates, dropping the BrOffice brand (at the Brazilians request) and more importantly Kami's gret msi packing improvements we've managed to pack all our languages, and many more dictionaries, and more functionality into a single download at 197Mb. That is clearly still too big, but smaller than a MS Office service pack. We are still some 40Mb larger than the original single-lang packaging (which it is our goal to match), but there is plenty more room for improvement (eg. gutting the megabytes of pointless ICU code we ship), and we'd love more help, (cf. scale offset of 150Mb):


Better translation infrastructure

I'm not an expert here, but our fantastic l10n team, swelled to 200 contributors is doing some great work on getting the latest translations into the product. They're using pootle for that, but better (thanks to Andras) we've switched from storing our translations in SDF format, instead using native gettext .po files compiled to various odd other formats during the build. Bjoern has a prototype patch coming to allow run-time .po file translation, to allow post-ship translation and better integration with Launchpad.

Heroic merging

One of the huge, invisible tasks for 3.4.0 was the merging of Oracle's code changes. Luckily, of course we use git - and several split repositories, such that merging should be easy. Then again, we have done lots of widespread changes, many hundreds of thousands, if not millions of lines of diff, stripping dead code, translating thousands of comments, touching every single file, as well as more substantial API and code changes.

One of the things that made the merge more tricky, was that (after decades of inactivity), some Oracle developers decided now (post fork) would be a great time to do some long overdue large-scale code cleanups. One of those was replacing every instance of TRUE with sal_True, same for FALSE, all instances of legacy types like BOOL to sal_Bool, for each of UINT16, ULONG, LONG etc. etc. Unfortunately, not an easy 'sed' either, as witness to some of the bogus "sal_True" type strings that popped out of the works. While a valuable, and much needed cleanup, this results in the kind of multi-million-line patch (touching all the dead code too) that has the effect of obfuscating their other valuable changes, and takes a certain determination to merge and reconcile.

The effort, spearheaded by Norbert with many straight days of mindless grunt work from myself, and able assistance from Thorsten, Kendy, Kohei, Noel and others - hopefully highlights a triumph of determination and survival against the odds, the tedium and some RSI. Unfortunately, due to some comic, transient technical hitches (that resulted in having to do much of the work twice) this merge rather delayed the code freeze and our first betas for 3.4.

Tinderboxes / rapid building & QA

With the rush to get 3.3 out, and the stabilisation releases after it, as well as the one-shot fun of migrating many Linux distributions over to use LibreOffice there was not enough spare bandwidth to get many tinderboxes or build-bots building. Unfortunately, this had quite an impact on the QA teams particularly after the merge completed, which was sad. The good news is, that we have mostly fixed this now, and have much more recent (the aim is daily) install-sets for most platforms available for testing - a great way to get involved is to help with re-testing old bugs against the latest stable releases.

A chunk of this is down to better tooling and scripts to drive tinderboxes, though we still struggle with unreliable Windows builds, cygwin's sh.exe, or perl.exe or dmake like to wedge intermittently some hours into the build. On the Mac front, Norbert had a breakthrough to shrink the build time. An all-lang Mac build used to take 15 hours (13 inside helpcontent2) - he managed to get this down to under 30 minutes using a ramdisk - substantially improving our agility and ability to turn around builds quickly: getting the latest code to QA fast. One of many great build performance improvements - with other much appreciated packaging acceleration wins in the tangle of badly written perl by guys like Jan Darmochwal, Julien Nabet and Steve Butler.

Then of course some QA stars like Rainer, Alex, Cor, Andre and many others have been working hard at finding, cleanly filing, triaging, prioritising and marking bugs, critical work.

Time based releases

One of the key features of LibreOffice, from my perspective, is its time based release process. Italo has done a great write-up with several nice pictures of this, one of these is this:


To me - having a predictable, and time-based release is such a key concept, that shipping 3.4.0 as a carefully labeled, point-zero release on time is more important than shipping an incredibly bug-free product, at a future, undefined point. This avoids a deeply political process of deciding when and if to release, and whose pet bug is worth waiting for and why, and why is his worse than mine, and oh ! I just found another one, lets delay another week. The alternatives to a time based release seem to have lead only to long (multi-month) slips.

Clearly, we have learned a lot this cycle, and improved our processes to make future releases even better. Obviously our succession of point releases: 3.4.1, 3.4.2 etc, will incrementally improve quality: indeed we are confident of that, since we already have a lot of fixes in-place for 3.4.1, however the fact remains that 3.4.0 is buggy (in fact all software is, but it is more so than usual, and we found a lot of bugs rather late). The bright side, is that our future point-zero releases, build on our improved infrastructure will be better in future. This is why we are continuing to advertise 3.3.2 (and the soon to be available 3.3.3) as the primary download build for now (thanks Christian for all your hard Javascripty work to make that fly). Please do - check-out 3.4.0 and get stuck into helping us make the Free Software Office world even more fun, fast-moving, and exciting. A great way to start as a developer is to get stuck into an Easy Hack.

Contributors

Of course, lots of people got stuck in already, and continue to do so. We like to graph statistics of commits by affiliation - charting how many people of what affiliation commit at least one patch per month, that gives us a pretty graph like this:


Which (I hope) shows the strength and diversity of the contribitor base, as well as its extraordinary growth since we launched. Sadly, some like to denigrate and despise contributors that only come up with small changes, personally I started off in Free Software as a contributor like that - and we love to help encourage, and mentor contributors from small things - to greater ones.

Other highlights

Well, of course so many others have been involved in making LibreOffice the success it is today, tirelesss work by many Steering Committee members, like Italo and Florian writing and co-ordinating multiple press briefings concurrently, and many helping translate and promote the software. The design team, being patient as we get the basics right before getting too stuck into fixing the UI (while producing some beautiful, much improved artwork), and no-doubt many others I forgot. And please take note - this is just some of the features you can't see, there are plenty that you can"

2011-06-02: Thursday.

2011-06-01: Wednesday.

2011-05-31: Tuesday.

2011-05-30: Monday.

2011-05-29: Sunday.

2011-05-28: Saturday.

2011-05-27: Friday.

2011-05-26: Thursday.

2011-05-25: Wednesday.

2011-05-24: Tuesday.

2011-05-23: Monday.

2011-05-22: Sunday.

2011-05-21: Saturday.

2011-05-20: Friday.

2011-05-19: Thursday.

2011-05-18: Wednesday.

2011-05-17: Tuesday.

2011-05-16: Monday.

2011-05-15: Sunday.

2011-05-14: Saturday.

2011-05-13: Friday.

2011-05-12: Thursday.

2011-05-11: Wednesday.

2011-05-10: Tuesday.

2011-05-09: Monday.

LibreOffice is the future of Free Software Office suites

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.

2011-05-08: Sunday.

2011-05-07: Saturday.

2011-05-06: Friday.

2011-05-05: Thursday.

2011-05-04: Wednesday.

2011-05-03: Tuesday.

2011-05-02: Monday.

2011-05-01: Sunday.

2011-04-30: Saturday.

2011-04-29: Friday.

2011-04-28: Thursday.

2011-04-27: Wednesday.

2011-04-26: Tuesday.

2011-04-25: Monday.

2011-04-24: Sunday.

2011-04-23: Saturday.

2011-04-22: Friday.

2011-04-21: Thursday.

2011-04-20: Wednesday.

2011-04-19: Tuesday.

2011-04-18: Monday.

2011-04-17: Sunday.

2011-04-16: Saturday.

2011-04-15: Friday.

2011-04-14: Thursday.

2011-04-13: Wednesday.

2011-04-12: Tuesday.

2011-04-11: Monday.

2011-04-10: Sunday.

2011-04-09: Saturday.

2011-04-08: Friday.

2011-04-07: Thursday.

2011-04-06: Wednesday.

2011-04-05: Tuesday.

2011-04-04: Monday.

2011-04-03: Sunday.

2011-04-02: Saturday.

2011-04-01: Friday.

2011-03-31: Thursday.

2011-03-30: Wednesday.

2011-03-29: Tuesday.

2011-03-28: Monday.

2011-03-27: Sunday.

2011-03-26: Saturday.

2011-03-25: Friday.

2011-03-24: Thursday.

2011-03-23: Wednesday.

2011-03-22: Tuesday.

2011-03-21: Monday.

2011-03-20: Sunday.

2011-03-19: Saturday.

2011-03-18: Friday.

2011-03-17: Thursday.

2011-03-16: Wednesday.

2011-03-15: Tuesday.

2011-03-14: Monday.

2011-03-13: Sunday.

2011-03-12: Saturday.

2011-03-11: Friday.

2011-03-10: Thursday.

2011-03-09: Wednesday.

2011-03-08: Tuesday.

2011-03-07: Monday.

2011-03-06: Sunday.

2011-03-05: Saturday.

2011-03-04: Friday.

2011-03-03: Thursday.

2011-03-02: Wednesday.

2011-03-01: Tuesday.

2011-02-28: Monday.

2011-02-27: Sunday.

2011-02-26: Saturday.

2011-02-25: Friday.

2011-02-24: Thursday.

2011-02-23: Wednesday.

2011-02-22: Tuesday.

2011-02-21: Monday.

2011-02-20: Sunday.

2011-02-19: Saturday.

2011-02-18: Friday.

2011-02-17: Thursday.

2011-02-16: Wednesday.

2011-02-15: Tuesday.

2011-02-14: Monday.

2011-02-13: Sunday.

2011-02-12: Saturday.

2011-02-11: Friday.

2011-02-10: Thursday.

2011-02-09: Wednesday.

2011-02-08: Tuesday.

2011-02-07: Monday.

2011-02-06: Sunday.

2011-02-05: Saturday.

2011-02-04: Friday.

2011-02-03: Thursday.

2011-02-02: Wednesday.

2011-02-01: Tuesday.

2011-01-31: Monday.

2011-01-30: Sunday.

2011-01-29: Saturday.

2011-01-28: Friday.

2011-01-27: Thursday.

2011-01-26: Wednesday.

LibreOffice - our first release

Today we released our first stable release of LibreOffice. That is really rather exciting ! and a major milestone. Of course, if you have a GNU/Linux or Unix distribution, most likely your packagers already knew our release timetable, and have distribution packages ready for you to use. If you can use those, do - they are likely to be better integrated with the system, and somewhat faster.

If you are a Windows or Mac user though, it is a great time to try out LibreOffice, directly from our download site.

Why LibreOffice ?

Apart from all the obvious reasons - of loving Freedom, Free Software, and fun, open, community development. LibreOffice is just better, much better, check out our (still expanding) New Features page - showing off what people can expect to enjoy in LibreOffice. As I get time, I'll add some highlights of my own appended here.

What next ?

As we work in a much more conventional Free Software project mold, we are releasing a point-zero release. This will not be perfect, but is any software ? what we will be doing is rapidly iterating it, via many minor point releases, towards perfection. We've published our timeline for that. Something you don't like ? some hideous translation or crasher bug ? we can include that fix soon, so do get stuck in and help out.

Perhaps the more interesting piece is the commitment to move to a six month release cycle, that is well aligned with existing Free Software community and distribution release cycles. We hope this will help get the latest, and best LibreOffice into users' hands as quickly as possible.

How do I get involved ?

LibreOffice is a project, almost uniquely suited to scaling to hundreds of people working on it - there are problems, missing features and bugs everywhere. There are millions of malnourished lines-of-code, awaiting your loving ownership, and remedial care - can you help them ? If so, please head to our developer instructions grab the code from freedesktop's git repository, and get stuck in, we'd love to work with you. We have many Easy Hacks designed for beginners to get involved - ranging from zero programming skill required, to some heavier lifting for the elite. As you do that, please do say hello on IRC: #libreoffice on irc.freenode.net, where much of the team hangs out.

Of course, if you want to mirror our binaries - and we are only 11Gb small (compared to 70Gb+ for OO.o), then drop a mail to mirrors@documentfoundation.org, we use Peter's excellent mirrorbrain - we have good coverage, but it can always improve. If you just like web banners that point to us there is just such a image.

Who did this thing ?

Well, in fact many people, far more than I can write down in one place - there are extensive credits here for all of the many individuals that have struck their blow for freedom with us; I am incredibly grateful for their support and friendship.

However, of course, some people have put more than the usual effort into this release - and here is where I forget people and offend at least someone. For various reasons: new packaging, and split help - the Windows build sucked a lot of mental energy this cycle, with Fridrich and Tor bearing the brunt of the pain. Similarly, Kendy battled the split help indomitably at great length, while managing the Novell team too. Then of course, the Steering Committee have put in lots of time with my personal favorite of Italo - creating and massaging press text and briefing many. The poor translation team, worked incredibly well under very tight deadline pressure to make up for the late strings that routinely needed shoving in, with Andras doing fantastic work getting their changes merged. Then finally, the website, its infrastructure, mirroring, scripting, design, artwork, and volume of text, polish, translation and beauty, as always - done on the very cusp of release swallowed much sweat and tears particularly from David, Christian, Florian, Thorsten and Sophie. My profound thanks to all of these, and more who worked so hard to get the release out - oh, and especially to the many un-sung hackers who got really stuck into triple reviewing, and fixing nasty blocker bugs before final code freeze.

2011-01-25: Tueday.

2011-01-24: Monday.

2011-01-23: Sunday.

2011-01-22: Saturday.

2011-01-21: Friday.

2011-01-20: Thursday.

2011-01-19: Wednesday.

2011-01-18: Tuesday.

2011-01-17: Monday.

2011-01-16: Sunday.

2011-01-15: Saturday.

2011-01-14: Friday.

2011-01-13: Thursday.

2011-01-12: Wednesday.

2011-01-11: Tuesday.

2011-01-10: Monday.

2011-01-09: Sunday.

2011-01-08: Saturday.

2011-01-07: Friday.

2011-01-06: Thursday.

2011-01-05: Wednesday.

2011-01-04: Tuesday.

2011-01-03: Monday.

2011-01-02: Sunday.

2011-01-01: Saturday.


My content in this blog and associated images / data under images/ and data/ directories are (usually) created by me and (unless obviously labelled otherwise) are licensed under the public domain, and/or if that doesn't float your boat a CC0 license. I encourage linking back (of course) to help people decide for themselves, in context, in the battle for ideas, and I love fixes / improvements / corrections by private mail.

In case it's not painfully obvious: the reflections reflected here are my own; mine, all mine ! and don't reflect the views of Collabora, SUSE, Novell, The Document Foundation, Spaghetti Hurlers (International), or anyone else. It's also important to realise that I'm not in on the Swedish Conspiracy. Occasionally people ask for formal photos for conferences or fun.

Michael Meeks (michael.meeks@collabora.com)

pyblosxom