Stuff Michael Meeks is doing
Older items: 2015: ( J F M ), 2014: ( J F M A M J J A S O N D ), 2013, 2012, 2011, 2010, 2009, 2009, 2008, 2007, 2006, 2005, 2004, 2003, 2002, 2001, 2000, 1999, legacy html
/usr, and yast2 to show debugging info than to fix the issue.
As the date of the Apache OpenOffice release approaches, and the final release candidate wends its way through a couple of rounds of approval / voting, I thought it might help clarify the current situation to have a side-by-side summary of what is in each suite. I'll update this entry in response to feedback, please do mail me with corrections if I've got things wrong.
Let me say, straight off, that I think the 'removal of copy-left' code (or at least its replacement) has been done reasonably well. Potentially rather a confusing description though: there are still great big gobs of copy-left code as hard requirements for a useful Apache OpenOffice but these are category b copy-left, instead of the category x licenses: (including the LGPL) that Apache excludes. The functionality loss from this removal is modest, as new versions of dependencies have been selected or system dependencies added, with even some rule-bending around shipping GPL dictionaries.
On the other hand, thus far, there are rather few really new features in the release that did not come from Oracle's existing work; that is outside of some pleasant drawing improvements, which we hope to merge into LibreOffice for our next major release.
So - what has been going on in these projects:
Of course, that misses a huge amount of detail out, a huge team of developers, translators, QA guys, infrastructure / sysadmin, conference and hack-fest work that people have done on the LibreOffice side: a simply staggering job, building a near-complete infrastructure and community that relentlessly execute against our time-based release plan. I can't begin to itemize or call out everything that has been achieved by so many.
On the other side work eventually started at Apache OpenOffice Incubating. Here - there were a few star developers from the Oracle Office BU that, despite having just been fired, continued to help Apache fix up what was left post Beta-1 by that hasty exit. They did so, not because they were required by their employer, but because they felt bound by duty to the project and the codebase. Prominent among them were Mathias Bauer, Eike Rathke and Michael Stahl, the last two of whom we enjoy the company of as active LibreOffice contributors today.
Rob Weir of the Apache project also produced an infographic on the project's progress which is worth checking out.
I spent a little while building a side-by-side comparison matrix to make it reasonably easy to see what is going on and what is in each of the three versions involved. I collected my data from the Apache OpenOffice 3.4 new features page which is helpfully split into those from the beta, and the new ones. I merged some subset of the distinctive main features from LibreOffice: 3.3, 3.4, 3.5 until I gave up.
Perhaps the biggest single chunk of the work we've done is hidden behind just a couple of bullet-points: MS Office 2007+ import / export. While all right-thinking people demand ODF, there is a sad reality of people using Microsoft's formats that Free Software users need to interoperate with. Having said that, the LibreOffice team has done some amazing work building other file filters to migrate legacy formats into the ODF future. Other features mentioned are a bit passé, SVG import has been shipping to GNU/Linux users, and many others since around 2008. Anyhow - here it is (also as an odg):
One of the most curious things about the OpenOffice.org brand, is the loyalty that users have to it, despite the 3.3 feature freeze being twenty-two months ago, having lost much of its development community, and having had no new release since January 2011 - users are still downloading this increasingly old and creaky release at top speed. Getting the LibreOffice message out: about the new, exciting, much more featureful, and fun suite is important - and much appreciated. Existing profoundly clueful GNU/Linux communities already know about the best free office suite ever others don't yet.
So - re-merging the projects; what is the sticking point ? In large part this comes down to licensing; do you believe that large companies will contribute their changes in a timely and constructive fashion without the encouragement of the license requiring that ? do contributors 'just want to see their code used' ?, or do they really 'just want to work together with others towards a common goal' ? who can say; only time will tell. Interestingly, there is perhaps a middle ground in the category b license. This type of copy-left license can allow binaries to be distributed under eg. an Apache license - but only after all of the source code is contributed back.
Interestingly, Apache OpenOffice Incubating already has a heavy dependence on code under this license; LibreOffice plans to move wholesale to the category-b Mozilla Public License (MPLv2). For me, going further to the Apache license would break faith with that significant proportion of our large developer community who see enabling non-contribution of core fixes and improvements as anathema, encouraging proprietary software creation. LibreOffice's weak-copy-left licensing is a compromise, enabling all sorts of awful proprietary things to be created and sold alongside, and embedded into LibreOffice, yet it requires contribution to humanity of changes to its core. That is good for interoperability, and community dynamics. Sadly, most end-users care remarkably little about licenses - clicking through them without even reading; that is something we should try to fix.
Another possible development, is the ongoing hope that IBM's commitment (of nine months ago) to donate whatever improvements Lotus Symphony has made to the code-base will finally materialize; which may help to close the growing feature gap to LibreOffice somewhat in places.
Ultimately, I would strongly prefer to have all of us working happily together in a community chosen by the active developers, and governed by a license that defines and regulates our co-operation. I'd like to think we have a good and growing track-record of being a flourishing, dynamic and stable foundation in The Document Foundation today. Certainly, we can't compete for length of track-record with the Apache pedigree, but in terms of attracting and inspiring developers to have fun together and produce a predictably great product I think we're excelling.
The Document Foundation is a diverse meritocracy, open to all contributors with plenty of room for new parties. We will share the same category-b licensing style that Mozilla and Eclipse have. There is no reason for more companies not to get involved. I'm happy with where LibreOffice is, but we can always be better - why not get involved today and become a key part of the future.
tools/tablepseudo-template in favour of STL; nice.
much more readable and comprehensible.- rtl::OUString foo(RTL_CONSTASCII_USTRINGPARAM("foo")); + rtl::OUString foo("foo"); - if (foo.equals(rtl::OUString(RTL_CONSTASCII_USTRINGPARAM("baa")))) + if (foo == "ABCD")
My content in this blog and associated images / data under
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 (email@example.com)