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: 2023: ( J F M A M J ), 2022: ( J F M A M J J A S O N D ), 2021, 2019, 2018, 2017, 2016, 2015, 2014, 2013, 2012, 2011, 2010, 2009, 2009, 2008, 2007, 2006, 2005, 2004, 2003, 2002, 2001, 2000, 1999, legacy html


2012-12-31: Monday.

2012-12-30: Sunday.

2012-12-29: Saturday.

2012-12-28: Friday.

2012-12-27: Thursday.

2012-12-26: Wednesday.

2012-12-25: Tuesday.

2012-12-24: Monday.

2012-12-23: Sunday.

2012-12-22: Saturday.

2012-12-21: Friday.

2012-12-20: Thursday.

2012-12-19: Wednesday.

2012-12-18: Tuesday.

2012-12-17: Monday.

2012-12-16: Sunday.

2012-12-15: Saturday.

2012-12-14: Friday.

2012-12-13: Thursday.

2012-12-12: Wednesday.

2012-12-11: Tuesday.

2012-12-10: Monday.

2012-12-09: Sunday.

2012-12-08: Saturday.

2012-12-07: Friday.

2012-12-06: Thursday.

2012-12-05: Wednesday.

2012-12-04: Tuesday.

2012-12-03: Monday.

2012-12-02: Sunday.

2012-12-01: Saturday.

2012-11-30: Friday.

2012-11-29: Thursday.

2012-11-28: Wednesday.

2012-11-27: Tuesday.

2012-11-26: Monday.

2012-11-25: Sunday.

2012-11-24: Saturday.

2012-11-23: Friday.

2012-11-22: Thursday.

2012-11-21: Wednesday.

2012-11-20: Tuesday.

2012-11-19: Monday.

2012-11-18: Sunday.

2012-11-17: Saturday.

2012-11-16: Friday.

2012-11-15: Thursday.

2012-11-14: Wednesday.

2012-11-13: Tuesday.

2012-11-12: Monday.

2012-11-11: Sunday.

2012-11-10: Saturday.

2012-11-09: Friday.

2012-11-08: Thursday.

2012-11-07: Wednesday.

2012-11-06: Tuesday.

2012-11-05: Monday.

2012-11-04: Sunday.

2012-11-03: Saturday.

2012-11-02: Friday.

2012-11-01: Thursday.

2012-10-31: Wednesday.

2012-10-30: Tuesday.

2012-10-29: Monday.

2012-10-28: Sunday.

2012-10-27: Saturday.

2012-10-26: Friday.

2012-10-25: Thursday.

2012-10-24: Wednesday.

2012-10-23: Tuesday.

2012-10-22: Monday.

2012-10-21: Sunday.

2012-10-20: Saturday.

2012-10-19: Friday.

2012-10-18: Thursday.

2012-10-17: Wednesday.

2012-10-16: Tuesday.

2012-10-15: Monday.

2012-10-14: Sunday.

2012-10-13: Saturday.

2012-10-12: Friday.

2012-10-11: Thursday.

2012-10-10: Wednesday.

2012-10-09: Tuesday.

2012-10-08: Monday.

2012-10-07: Sunday.

2012-10-06: Saturday.

2012-10-05: Friday.

2012-10-04: Thursday.

2012-10-03: Wednesday.

2012-10-02: Tuesday.

2012-10-01: Monday.

2012-09-30: Sunday.

2012-09-29: Saturday.

2012-09-28: Friday.

2012-09-27: Thursday.

2012-09-26: Wednesday.

2012-09-25: Tuesday.

2012-09-24: Monday.

2012-09-23: Sunday.

2012-09-22: Saturday.

2012-09-21: Friday.

2012-09-20: Thursday.

2012-09-19: Wednesday.

2012-09-18: Tuesday.

2012-09-17: Monday.

2012-09-16: Sunday.

2012-09-15: Saturday.

2012-09-14: Friday.

2012-09-13: Thursday.

2012-09-12: Wednesday.

2012-09-11: Tuesday.

2012-09-10: Monday.

Linux on the (consumer) Desktop

Overview

Arriving back from vacation, I read Miguel's thoughts on the state of the Linux Desktop in the race for the consumer market; I happen to mostly agree with his conclusion - that we're still facing a huge up-hill struggle there. While I have huge respect for his experience and insight, I think the causes are larger. My punch-line is that the Linux Desktop faces a huge and multi-factored ecosystem challenge, there is no single simple issue to fix. Over the last decade I've been peripherally involved in trying to tackle many of the problems in this area, here are some of my random thoughts and open questions on the topic, there are no radical new insights:

Our attractiveness to ISVs

Clearly this is a significant factor in our problem. No matter how bad and limited our APIs are, if there is market pressure to port software to the platform - it will come; hacks and all. Yes, the Linux Desktop is a horrifying thing to deal with from an ABI stability / interface perspective. Aside from the diversity of pointlessly different distribution packaging details, the Linux Desktop stack (with existing frozen / back-compatible API/ABIs) is not profoundly different from other operating systems - indeed, arguably it is better for ISVs since we have access to open the lid on the box and work with each other as some are finding out.

Other's attractiveness to ISVs

Often the disguised thought here is that the competition are simply wonderful at producing clean, crisp, working, tested, performant implementations of everything, for which there are no compatibility problems, and life is wonderful. People then often point at Windows XP - perhaps the best understood mature operating-system ever, with a decade of workaround development and integration testing.

How do Windows ISVs get such a great deal ? one thing they do is to distribute much more of the system in duplicate with each application. So for example each app ships it's own libc and gets to try to install it somewhere. This is something that we typically don't do on Linux, but it could be done: some form of application virtualisation would help. Conversely Windows ISVs suffer a lot of performance, scriptability, and repeatability problems that are just not there on Linux.

How about other new successful platforms like iOS / Android which are loaded with ISVs - do they have the world's most beautiful development environments ? given that Xamarin are selling sexy tools to improve the ISV environment there my suspicions is that not all is perfect. Enjoying native code development on these platforms is like enjoying extreme DIY dental surgery - the Linux Desktop is infinitely preferable as an ISV platform. Why do ISV's put up with it ? in my view, it is driven exclusively by the large addressable market. You don't need an MBA to see the trends and opportunity there.

Questions around a better ISV story

There is a lot more to say; but perhaps some of it belongs as questions. Let me frame them in this way; Question: is there something that we (as Free Software lovers) can do to make our ISV story sexy enough that it makes the Linux Desktop an attractive enough platform for developers that it overrides our lack of market share, and makes a Linux Desktop port of each piece of software automatic ? [ notice I'm abandoning the idea of a Free-Software killer-app that sticks to only our platform ahead of time, the market realities will bring it to Windows / Mac even against our will ].

What will attract ISVs to our platform ? what will make them feel at home, and productive producing software for the other major platforms ?

If we make it easy to purchase proprietary software, or to donate money to free software app developers and overcome our fragmentation to integrate this everywhere (a single 'App-Store'), will this bring us back to parity with other OS' or make us compellingly better ?

Attractiveness to (consumer) OEMs

It is often noticed that OEMs pay money to install Windows on their machines, and that the Linux Desktop is an apparently free alternative - so surely our zero cost should make us wildly successful right ? It seems to me there are a multitude of interesting problems here.

Zero is too inexpensive

One of the major business problems of hardware enablement is that it takes a constant investment of real cash to pay excellent engineers to make (brand new) hardware work reliably. Linux has more drivers working out of the box than any other OS - of course we rock; however - the Windows ecosystem distributes that cost among hardware vendors: who write their own drivers (subsidised by the hardware you buy), and the Mac ecosystem ships a very limited set of hardware. Unfortunately, the cost of the Linux Desktop to OEMs has been driven down to a marginal level by somewhat cut-throat competition. That makes enablement development hard to justify without enough volume. Substantially exacerbating this is the habit of consumer-grade hardware of constant switching of components. There is a silent, invisible, gigantic, cost-engineering war going on out there which squeezes cash out all along the chain. In the absence of good standard interfaces, this makes device support much harder for consumer hardware; a trivial but comic example is of custom tweaking batches of hardware to pre-define vflip states for built-in webcams, cf. the kernel.

Zero is not cheap enough

Unfortunately, even if hardware can be perfectly enabled, fully translated, with accurate manuals, support and update plans, integrated with OEM's imaging infrastructure etc. and at near-zero cost, this is still too expensive. Looking at other ecosystems there are substantial flows of cash to OEMs that are not obvious. There are a lot of these:

Channel issues

Even when the hardware is perfectly enabled, and there is an advertised Linux that works on this hardware - it is frequently extremely difficult to actually buy that model. Often these models are geographically limited, frequently the imaging process is done in the factory, and so the lower-volume Linux version you want is not in stock / is un-available on-line. Clearly by the time you head to an interactive shop display, the expensive (paid-for) display space is unlikely to be used for a little-known Linux variant of the hardware. So, all in all it's usually far easier to buy the device with Windows installed, and image it. Potentially there is a market for OS vendors to sell device-specific to-customer desktop O/S support but the transaction costs are likely to be high and the market small.

Zero can be much too expensive

The cost of supporting shipped hardware can be rather a large proportion of an OEM's expenses. That's particularly so if you image tens of thousands of machines with some crippling issue, or ship an update that breaks updating, or - any of the other software horrors you can imagine loaded on top of the inevitable hardware problems. I recall well being told by a nameless support technician to hold down 'QWER' while powering on a dead machine, not for some obscure BIOS feature - but to help re-seat the loose CPU immediately underneath the keyboard.

Perhaps here is somewhere we could excel - having ultra-robust, translated, cross-distro standardised recovery, re-imaging, disk repair, hardware diagnostics, incident reporting, built-in help-desk agents - which combined with relative virus-freeness could reduce consumer support costs. Re-installing windows is currently a routine lifestyle-choice for some people, nevertheless it is somehow a familiar and re-assuring experience - not something you send your netbook back for: just re-install. My hope is that the base-system consolidation around systemd might bring us some of this critical disaster recovery / re-imaging / rescue functionality in a standardized form.

Attractiveness to the Consumer

So perhaps the consumer is going to ride to the rescue, demand Free Software because it is better, and all will be well - the OEMs will respond to market pressure and produce what people want, and ISVs will respond to that.

If we build it, he will come

It is a nice dream. Clearly we want to make the best product possible for consumers. It is of course possible for an excellent product to spread virally by word of mouth, clever volunteer marketing, and more - but it is hard work. I often hear the idea that we just need to implement XYZ new feature, and people will flock to us. I'm always eager to see new features, but it seems to me that a feature-edge is rather a small part of the answer - we may well already be more secure, more manageable, more easy to upgrade, and lower cost: but unless consumers know about us - with the best will in the world, they can't choose us.

Making it easy to buy

Absent a near infinite supply of enthusiastic local hacker-types to install and maintain Free Software for everyone, your average consumer needs the ability to buy it. Unfortunately, the economics of encouraging high-street shops to position, and advertise it are punitive - a game for the very rich, and the results are not uniformly ideal - cf. Nokia's expensive Lumia displays in every mobile store window in the UK, and the resulting trivial market share. Potentially in an Amazon / web-purchasing world people can buy "one just like my mate has" without going into a shop, possibly media hype and brand loyalty can make people buy expensive new products on-line that they've never physically seen. On the other hand the experience of the rather cool Litl product - is not too encouraging.

Economies of scale in retail often lead to a few, large high-street vendors - whose appetite for across-the-board risk and experimentation with new software/hardware combinations is low.

Revolutionary technology improvement

There are two types of people: those who don't like to learn new things, and what was the other one ?. Persuading people to like change and new-ness is rather difficult - it seems to me, that the more humdrum and non-novel a product is, the more attractive 'new-ness' is as a marketing feature: "new ultra-squeeze toothpaste" turns out to be just the same old stuff in the same old kind of tube. Conversely - "new - radically different approach to keyboard key layout - up to 5x more productive" already doesn't sound like a winner. Apparently some new technologies are just so usable that people are willing to invest their spare time in learning them - perhaps that, or their brands, constructed by expensive marketing, are so powerful that people buy before they try, and feel they ought to catch up with their friends later.

Questions around Consumer demand generation

Can we create and retain a feature edge vs. other operating systems (who will relentlessly copy our killer ideas) for long enough, that we can create a marketing story that reaches enough consumers to build significant demand ?

Can we mobilise, motivate and inspire enough (tech literate) early adopters to evangelise, support and unambiguosly advocate the Linux Desktop ? Can we simultaneously please enough innovators such that they love using the platform to get their tasks done and let us capture a significant proportion of the leading edge of the adoption curve ?

Instead of targetting immediate ubiquity, could we find, and focus on a series of consumer niches which we can grow to become the de-facto solution, in turn growing a community of developers to sustain that niche ? Are there intrinsic strengths of the Linux Desktop that would stop any killer apps moving to other, existing platforms to avoid migration pain ?

Tentative Conclusions

While I've been hacking on and/or using the Linux Desktop it has improved in an simply incredible fashion. It is hopeful that on it's current trajectory it will continue to improve, assuming we can continue to (mostly) avoid the duplication, pointless re-writing, and un-necessary re-invention that plagues Free Software. However from a consumer adoption point I draw these hesitant conclusions:

Postscript - the Business user

So - perhaps focusing exclusively on the consumer desktop seems a bit depressing. It is interesting to consider instead the enterprise / business user. There are a number of factors here that make this a much more promising space, and one that I'd love to persuade more hackers to take seriously as they work. A note of self-interest, my employer SUSE happens to sell a fantastic Enterprise desktop SLED. A quick run-down of the salient differences are:

The net effect of the above is to make the economics far more favourable. Clearly there is still a co-marketing cliff of pain, the hardware manufacturers provide and debug windows drivers 'for free', etc. but the economics are much more tractable. So - what does a strategy for tackling business users look like ? What do business users care about that consumers tend to care less about ? I have a few thoughts, probably others have more:

In my view the most hopeful strategy for the Linux Desktop is to make it ideal for an enterprise, while not crippling it for consumers and very early adopters. It is perhaps not glorious - enterprises care little for the bling that doesn't have a direct, unarguable business benefit - and bling is fun to hack on; but surely creating real value, that allows people to work more efficiently, reliably, and speedily has to be a satisfying thing to do as well.

[ This is a live-ish post, that I'll try to update, correct, and cross-link better over time. ]

2012-09-09: Sunday.

2012-09-08: Saturday.

2012-09-07: Friday.

2012-09-06: Thursday.

2012-09-05: Wednesday.

2012-09-04: Tuesday.

2012-09-03: Monday.

2012-09-02: Sunday.

2012-09-01: Saturday.

2012-08-31: Friday.

2012-08-30: Thursday.

2012-08-29: Wednesday.

2012-08-28: Tuesday.

2012-08-27: Monday.

2012-08-26: Sunday.

2012-08-25: Saturday.

2012-08-24: Friday.

2012-08-23: Thursday.

2012-08-22: Wednesday.

2012-08-21: Tuesday.

2012-08-20: Monday.

2012-08-19: Sunday.

2012-08-18: Saturday.

2012-08-17: Friday.

2012-08-16: Thursday.

2012-08-15: Wednesday.

2012-08-14: Tuesday.

2012-08-13: Monday.

2012-08-12: Sunday.

2012-08-11: Saturday.

2012-08-10: Friday.

2012-08-09: Thursday.

2012-08-08: Wednesday.

LibreOffice progress to 3.6.0

a

Today we released 3.6.0, checkout the new feature summary and release notes. As always a lot more has happened under the hood than can easily be addressed in the features page; so here are some of the behind-the-scenes bits and some of the unsung heros doing the vital, but more hard-to-see work.

Improving extension registration

For this release we introduced new code to improve the way extensions (and built-in components) are registered and looked up. This dungs out a very old and unpleasant piece of the UNO core, replacing it with a rather simpler and cleaner version that performs better - casual callgrind profiling shows some nice wins here.

Unfortunately, for one reason and another, despite a delay for a fourth release candidate, there are still some circumstances where an upgrade will not re-register some built-in extensions, and silently exit on first launch (just re-run it). On the down-side that can affect spell-checking dictionaries, and (for some) on the up-side disables Auto-COrrection too. This is already fixed for 3.6.1, due in three weeks, and can easily be worked around by removing the extensions/ directory from your user-profile (which will then be re-generated). Better than that as this has been fixed Stephan Bergmann has further dunged out the registration / upgrade code to stop this recurring.

The ESC decided to sticking to our release discipline and cadence to underline the importance of early QA and bug fixing. I'd love to see more people running our daily dev-builds of master and reporting bugs much higher up the food chain, and building good relationships with the grateful developers who just created them. See here for a list of other annoying issues in 3.6.0.

Upgrading the code: dead code

In other areas we've made improvements that are hard to see; one of these is eliminating dead code; here's how we're doing at that: unused methods vs. time - lower is better.

As you can see the task is ~nearly done. The remaining bits are particularly hard and involve finally completing the re-write away from the legacy, non-standard macro-generated template-alikes, to use modern C++ STL templates, that are far more accessible. Many thanks in particular to Noel Grandin for his ongoing work there in this release, and Michael Stahl for reviewing lots of patches, and Caolan McNamara for building the dead-code detection infrastructure.

Upgrading the code: German comments

The ongoing charge to translate our remaining German comments continues to bear fruit. We're around 50% done here - down to around 25k lines (as detected by Miklos' nice bin/find-german-comments script).

With many thanks for this release to Luc Castermans, Philipp Riemer, Julien Nabet, Tomaž Vajngerl, Jesso Clarence – Murugan, Florian Reisinger, Sebastian Spaeth, Philipp Weissenbacher and several others. One of our (encouraging) problems is that comment translators tend to get hooked on code cleanup, and move off to do ever more substantial fixes elsewhere - so it's a great way to get involved in LibreOffice: not unlike the typing-in of BBC BASIC games that got me into code syntax; if you can understand German, you can help out here - but please don't send automated translations, we're eager to have the highest quality.

Upgrading the code: fixing the make system

One profound unpleasantness of the OO.o legacy was the custom version of the unusual 'dmake' required to reliably build the code. Some heroic hackers have been taking on the work Bjoern started at Oracle to convert to using GNU make instead. One benefit of this is exposing massive build parallelism - we now have a global view of dependencies for nearly all of our internal code in one GNU make process allowing an incredible degree of parallelism - thousands wide at times: so if you want to actively stress-test your 1024 CPU machine, we can help you.

Many thanks to David Tardon, Matúš Kukan, David Ostrovsky, Peter Foley, Pierre-Eric Pelloux-Prayer and more for working hard at this; and many others for detecting, filing and fixing any associated bugs. It is encouraging to see David's latest test branch to complete the UNO Runtime Environment migration, nailing the last set of problems before tackling the final chunk of 'external' modules - the around 80 bits of source we download, patch, build and distribute (mostly to enable Windows builds). Hopefully we'll be fully dmake-free in six months time.

Upgrading the code: unit tests

One of the most exciting things that has been ongoing in LibreOffice up to 3.6 is the growth in unit tests. In contrast to the various unreliable automated tests that were present before, these are run very regularly. Some we run on every module build (ie. just building calc), and yet more we run on straight-through builds. We aim to spend some small proportion of our compile-time say under 5% building and executing these as widely as possible:

Many thanks to Markus Mohrhard, Artur Dorda, Daniel Bankston, Kohei Yoshida, Miklos Vjana, Caolan McNamara, Michael Stahl, and many more - who got tired of endlessly re-fixing the same sorts of bug, and did something permanent about it by writing small, fast, reliable unit tests. This is a great job to get stuck into - we have code lying around that could be turned into nice unit tests, and it would be great to have more people involved in that work.

Faster, more readable code

Another thing that can't be seen are the very long overdue improvements in our basic String classes. Traditionally we've had four string classes where one would be best - heroically Caolan McNamara finally killed the ByteString class in 3.6, leaving only three. With perhaps a greater impact Lubos Lunak spearheaded a fantastic improvement in good-taste-based-coding with some tweaks to our OUString class, used almost everywhere. You can see the improvement in this pseudo diff based on real changes:

-    if ( aFlavor.MimeType.indexOf( ::rtl::OUString(RTL_CONSTASCII_USTRINGPARAM( ";Aspect=THUMBNAIL" )) ) != -1 )
-        xPropSet->setPropertyValue(::rtl::OUString(RTL_CONSTASCII_USTRINGPARAM("HelpText")), aAny);
+    if ( aFlavor.MimeType.indexOf( ";Aspect=THUMBNAIL" ) != -1 )
+        xPropSet->setPropertyValue("HelpText", aAny);
This sort of change is repeated many, many times. Interestingly in many cases these make the code not only far more readable, but also produce smaller, faster code by avoiding intermediate allocations of strings; a great improvement. Lubos also has some interesting clang plugin in progress to automatically generate this sort of semantic code upgrade. Using that is naturally blocked by completing the on-going re-basing on the Apache licensed version of LibreOffice.

Cross-compiling code

Other major improvements in 3.6 are the ability to do cross-compiles of LibreOffice - Tor Lillqvist did a lot of work here, initially focused on ensuring that the MingW cross-compile for Windows from Linux worked well. This can be run on very fast hardware as a tinderbox to ensure that master remains buildable always. That work has expanded into cross-compilation to Android and iOS both of which continue to develop and improve in master. At the same time Eilidh McAdam for Lanedo has done some great work at cross-compiling .msi files from Linux, re-using wine code - to improve that install flow and move us towards fully Free Software tooling.

Better builds out of the box

Another nice improvement is the growth of big-machine tinderboxes to ensure that we keep master in a buildable state on many platforms at all times. You can checkout the latest build status. With many thanks to Norbert Thiebaud for his time and CPU horsepower donations, and to ByteMark for their generous donation of a very substantial machine for native Win32 building that really helps.

Easier code contribution

Yet another ongoing initiative, is that of improving our code submission process - Bjoern Michaelsen, Norbert Thiebaud, Robert Einsle, David Ostrovsky and others have been working hard to get Gerrit (an automated code submission system) setup. This lets you convert your OpenId account to git push access to a review branch without any interactions, it also has a fine code review flow for submitted patches, and makes including cherry-picking patches, and providing feedback much easier. We plan to migrate our main repository to this shortly, leaving freedesktop as a read-only mirror.

Conclusions

Well, there is much more to say - so many people have done such a lot of work to make 3.6 better; the QA team has been doing a fantastic job triaging incoming bugs and raising their priority / flagging them as Most Annoying - we couldn't work effectively without you guys. The design team have done some really excellent work in 3.6 as well, overall it's an exciting time for LibreOffice. I hope I've given you a snapshot of some of the things you can't easily see in the 3.6 release - of course, there are also a ton of things you really can see that are visible on our 3.6 new features page - I commend that to you; thanks to Marc Paré for pulling that together.

If you want to get involved in LibreOffice, there has never been a better time, there are more people spun-up to help mentor, we continue to grow our developer base, and there are still plenty of easy hacks to ease you into the code - we'd love to hear from you.

2012-08-07: Tuesday.

2012-08-06: Monday.

2012-08-06: Sunday.

2012-08-04: Saturday.

2012-08-03: Friday.

2012-08-02: Thursday.

2012-08-01: Wednesday.

2012-07-31: Tuesday.

2012-07-30: Monday.

2012-07-29: Sunday.

2012-07-28: Saturday.

2012-07-27: Friday.

2012-07-26: Thursday.

2012-07-25: Wednesday.

2012-07-24: Tuesday.

2012-07-23: Monday.

2012-07-22: Sunday.

2012-07-21: Saturday.

2012-07-20: Friday.

2012-07-19: Thursday.

2012-07-18: Wednesday.

2012-07-17: Tuesday.

2012-07-16: Monday.

2012-07-15: Sunday.

2012-07-14: Saturday.

2012-07-13: Friday.

2012-07-12: Thursday

2012-07-11: Wednesday

2012-07-10: Tuesday

2012-07-09: Monday

2012-07-08: Sunday

2012-07-07: Saturday

2012-07-06: Friday

2012-07-05: Thursday

2012-07-04: Tuesday

2012-07-03: Tuesday

LibreOffice / Android update

This last week, Tor Lillqvist handed me the task of mentoring Iain Billet for his Google Summer of Code project. He is working hard to make a nice viewer out of LibreOffice for Android. Rafael Dominguez's new templates dialog blog post provoked / inspired me to give a quick status update on where we're at. To re-emphasise, the bulk of this is Tor's work, with viewer bits by Iain; I just took some screenshots.

What is done already ?

For those unlucky enough not to have been at FOSDEM / LinuxTag to catch the latest status, and see the live demo fun - here is a quick snapshot of the current state of affairs:

What does that look like - well, that gives a fairly horrific, bolts and all, barely usable (even with keyboard and mouse) office suite on your tablet; here is a picture of it under the emulator:

Horrible hack of a lame Android UI - proof of concept
As you can see the rendering is reasonable, albeit with the odd silly re-draw artifact but the user interface is otherwise utterly horrible for a tablet device.

Current state

As part of the Google Summer of Code, Iain Billet is working hard at building a Java viewer UI for LibreOffice, that will integrate nicely into the platform, and provide fast pan / zoom / page-flip browsing, and all that good stuff you expect. Tor meanwhile (modulo having just left for vacation), is working on tiled page rendering to textures. That will allow us to quickly render portions of document content at any scale, asynchronously in a background thread, to suit the viewer. This is going reasonably well.

We have a viewer / file-manager shell to allow managing and selecting your documents on the sdcard. Hopefully this is iterating slowly towards the beautiful design from the design team:

Android Viewer UI shell

And the initial viewer UI with page selector is coming along nicely too, again targetting the design:

Android Viewer UI - showing rendered writer document

The code for the viewer is in the git / master branch in the android/experimental/LibreOffice4Android directory. It should build out of the box with a make clean all install run, of course after you have followed the compilation instructions and Android how-to. Help much appreciated improving and extending this to other components: calc, impress etc. The test-files above are (for interest) 1, 2.

Ongoing viewer work

As you can see, lots of the heavy lifting is already completed, and the stage of fertile hacking is arriving, with smaller incremental forays from something working, to something better. There are still a largeish number of things that need doing / cleaning up though, some of these will help other platforms & products too:

Help much appreciated with any of that, please do mail the developers list if you want to get stuck in somewhere there.

Future editor work

Of course, a viewer, even one that handles the full breadth of formats that LibreOffice can handle, is not enough. The plan in the deeper future is to add editing functionality. That brings plenty of challenges, particularly around re-using existing code and widgets in a tasteful way.

One thing that really needs working on is a liblibreoffice.so model. That would allow developers to link a single shared library and do a small amount of platform/toolkit integration work to re-use the LibreOffice core and renderer. That is something that is reasonably do-able today in fact, indeed - it would be rather excellent to fully split the rendering core from the presentation / scrolling etc. internally. That would also allow a new, native linux, viewer client, which in turn would accelerate prototyping of what is needed for mobile. Currently a slow build, re-package, install, run appears to be required for native Android development.

Finally if you want to hear, and see more, and get involved with what we're up to, a great way to do that is by coming to:

LibreOffice conference - Berlin 17th-19th October

2012-07-02: Monday

2012-07-01: Sunday

2012-06-30: Saturday

2012-06-29: Friday

2012-06-28: Thursday

2012-06-27: Wednesday

2012-06-26: Tuesday

2012-06-25: Monday

2012-06-24: Sunday

2012-06-23: Saturday

2012-06-22: Friday

2012-06-21: Thursday

2012-06-20: Wednesday

2012-06-19: Tuesday

2012-06-18: Monday

2012-06-17: Sunday

2012-06-16: Saturday

2012-06-15: Friday

2012-06-14: Thursday

2012-06-13: Wednesday

2012-06-12: Tuesday

2012-06-11: Monday

2012-06-10: Sunday

2012-06-09: Saturday

2012-06-08: Friday

2012-06-07: Thursday

2012-06-06: Wednesday

2012-06-05: Tuesday

2012-06-04: Monday

2012-06-03: Sunday

2012-06-02: Saturday

2012-06-01: Friday

2012-05-31: Thursday

2012-05-30: Wednesday

2012-05-29: Tuesday

2012-05-28: Monday

2012-05-27: Sunday

2012-05-26: Saturday

2012-05-25: Friday

2012-05-24: Thursday

2012-05-23: Wednesday

2012-05-22: Tuesday

2012-05-21: Monday

2012-05-20: Sunday

2012-05-19: Saturday

2012-05-18: Friday

2012-05-17: Thursday

IBM's Symphony code contribution

Today IBM seems about to deliver on their promise of opening up the Symphony codebase. That is a good thing. It represents an important way-point, in the middle of a long process.

A long journey

I recall well meeting Don Harbison at the OpenOffice conference in Koper in 2005, and a memorable party during which I no doubt bored him to death by re-iterating the importance of working with the community, in the open and contributing your code. Then around April 2006, IBM Workplace 2.6 arrived: a proprietary product based on a version of the OpenOffice.org 1.x code-base. That was enabled by the non-copy-left SISSL license variant the code was under at the time. Fast fowarding to September 2007, Lotus Symphony appeared in beta, complete with an interview "IBM joins OpenOffice to widen it's reach" with Doug Heintzman, promising:

"IBM will dedicate a core team of 35 programmers in China to the OpenOffice project, but more people will be added as needed around the world, he said."

Around this time, we got some contributions of parts of the Symphony feature-set thrown-over-the wall. Sadly these were mostly vs. an obsolete code base, and were mostly not maintained or forward ported (though LibreOffice's current Lotus Word Pro filter was rescued from that dump). At the time I confess I was eager for IBM not to contribute anything towards propping up the fundamentally unjustly managed and structured OpenOffice.org project, with which I'd become utterly disillusioned.

As time passed, the waiting and suspense continued to build, in November 2008 at OOoCon Beijing I had the pleasure of meeting Michael Karasick, whose (keynote) gave an apologetic score-card for this contribution, and promised "we will be contributing". More time passed. By July 2011, the donation of the code was announced in a press release "IBM Donates Lotus Symphony Source Code to the Apache OpenOffice Project", and still no code.

Then, this week Don Harbison announced that IBM have signed a software grant agreement to the Apache project for the code, which is planned to appear in svn as a single, flat, code dump. At last ! the code will be read and the valuations independently assessed. I have fond memories of working together with Doug, Michael & Don, and I'm certain their commitments were sincerely given and meant on each occasion. I suspect the primary cause of the delay is degrees of embarrassing frustration inflicted by part of a corporate machine fearful of, and unused to the transition costs of open, community based development.

Every day, open and engaged ...

Of course, it is great when code that has been proprietary and closed is finally opened, and licensed in a way that LibreOffice can include it. While there is some sad level of duplication vs. work done in LibreOffice, there are also some nice sounding features that should be useable for our next release as/when we have re-licensed.

On the other hand, one of the real pleasures of working in LibreOffice is the collegial, interaction and co-operation with my much-appreciated colleages from Red Hat, SUSE, Canonical, Lanedo, Google and the hundreds of developers and other supporters that have contributed to the project since we started ~eighteen months ago. The credit these guys deserve, for their outstanding effort defies praise. In my book what looks like the boring, every-day, long-haul work of open interaction to achieve shared goals is worth immeasurably more. It may take time to hammer out results that I don't always agree with, but it is good.

Playing well with the community seems to me to mean a lot more than a one-off code-dump. It also means being willing to compromise and work constructively with others of differing ideological viewpoints, encouraging and motivating people to work together.

It means that companies should not horde their changes, to try to be first to the market. There should be direct contribution of the totality of bug fixes and improvements, as they are made, to an appropriate branch. Unfortunately, licensing is a factor here too. The Apache license, by providing you with the choice of when to release your code: "now ? later ? never ?" creates an economic incentive to horde and create a saleable, proprietary feature-edge. That in turn creates a disincentive for others to share. In contrast, a weak copy-left license pushes people inevitably towards sharing, working together, and a service & support based business model.

Hoping for good corporate citizens

So, what does this mean, if anything ? if this move signals a genuine change of heart, towards working collaboratively with the developer community in a sustained and non-proprietary fashion - releasing code changes as they are made and working fully in the open, that is good news. Of course, the most convincing way to make such a commitment to work well as peers with the community, is to join with the existing majority of the developers around the code-base, who are eager to work with IBM as part of LibreOffice. Indeed, more than that - I (and I suspect others) are anxious to make room for our friends from IBM: Peace, Love, LibreOffice ! However, that will inevitably mean making a few real compromises, working in community always requires that. One would be formalizing that intention to contribute well in the most convincing way: using the form of a source-code-license like the MPLv2 or LGPLv3+ which codify such good behaviour. That helps to ensure timely, collaborative code contribution from all players, protecting everyone independent of scale. Is it hard to make such a binding commitment ?

Failing that the option of competing with that community, while trying to build a track record from scratch as an enthusiastic believer in open development, collaboration, compromise, working as an equal, etc. may prove problematic. One canary here may be how this substantial code dump is treated. Will it be split up into individual, digestible features & commits, which can be merged individually into the existing Apache OpenOffice codebase. Or will a single, big, un-documented code commit be attempted ?

A conclusion or two

It looks like IBM will release six+ years of work by their development team; that is a good thing, it will be interesting to see what their sharp team has been up to over that time. Opening previously proprietary software is almost always a good thing, and it may provide our users with some improvements in due course.

In this historical context actions speak much louder than words, but are much harder to extrapolate into the future. Will we see a positive, constructive engagement moving forwards ? the best sign of that would be positive interaction with, compromise and re-unification with the vast majority of developers. An ongoing sadness for me is the lack of even contemplation of that.

Still, in the meantime the LibreOffice community is having fun preparing for it's 3.6 freeze with steady hacking progress; a prototype new feature page is in the process of getting built, though I suspect completing that will need to wait for some last minute features to get pushed. It's a great place to have fun, make a difference and get involved with Free Software, why not try an Easy Hack today ? every little helps.

2012-05-16: Wednesday

2012-05-15: Tuesday

2012-05-14: Monday

2012-05-13: Sunday

2012-05-12: Saturday

2012-05-11: Friday

2012-05-10: Thursday

2012-05-09: Wednesday

2012-05-08: Tuesday

2012-05-07: Monday

2012-05-06: Sunday

2012-05-05: Saturday

2012-05-04: Friday

2012-05-03: Thursday

2012-05-02: Wednesday

2012-05-01: Tuesday

2012-04-30: Monday

2012-04-29: Sunday

2012-04-28: Saturday

2012-04-27: Friday

2012-04-26: Thursday

A LibreOffice/Apache OpenOffice Comparison

Update 2015-06-05: this is now deeply obsolete; checkout the updated sixty page version instead.

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.

A (very) potted history

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.

A side-by side comparison

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):

Some thoughts

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.

2012-04-25: Wednesday

2012-04-24: Tuesday

2012-04-23: Monday

2012-04-22: Sunday

2012-04-21: Saturday

2012-04-20: Friday

2012-04-19: Thursday

2012-04-18: Wednesday

2012-04-17: Tuesday

2012-04-16: Monday

2012-04-15: Sunday

2012-04-14: Saturday

2012-04-13: Friday

2012-04-12: Thursday

2012-04-11: Wednesday

2012-04-10: Tuesday

2012-04-09: Monday

2012-04-08: Sunday

2012-04-07: Saturday

2012-04-06: Friday

2012-04-05: Thursday

2012-04-04: Wednesday

2012-04-03: Tuesday

2012-04-02: Monday

2012-04-01: Sunday

2012-03-31: Saturday

2012-03-30: Friday

2012-03-29: Thursday

2012-03-28: Wednesday

2012-03-27: Tuesday

2012-03-26: Monday

LibreOffice Collaborative Editing Prototype

One of the last, big missing features in LibreOffice is collaborative editing, to fill this hole Eike Rathke (of RedHat) has been working for some weeks getting Telepathy code hooked into the LibreOffice core. This was chosen to allow us to setup a channel for multi-way communication over existing Instant Messaging (IM) protocols, without requiring any form of server.

A mini hack-fest

With the lovely Google Summer of Code coming up and this Collaborative Editing task on the menu, we thought that it would be good to break the back of the problem, so we had a basic design agreed, some of the heavy-lifting done, and an awareness of the problem areas, so that we'd be good mentors for that task (though please apply for other tasks too, since we suspect this will be rather a popular one, there are a load of other great things to get stuck into in the project list).

Using some quick funding from The Document Foundation, it was possible to get Eike to Cambridge, with Collabora sponsoring us providing office space and Will; getting all the brain-power we needed into one place: Will, Eike, Myself & Rob.


Outline / progress

The kernel of the collaborative approach chosen here is to realise that, as long as every user of the suite applies every change in exactly the same order, it doesn't much matter what the result is; users will get used to resolving occasional conflicts, as long as they can deterministically see the results, and know that this is what everyone sees. Naturally, more complicated designs are possible, but this at least provides a simple, initial approach while we tease the code apart to extract real controller objects.

Telepathy provides a powerful instant-messaging framework that allows the creation of abstract 'tubes' that tunnel invisibly over the IM protocol - allowing arbitrary new protocols to piggyback on your existing IM chat. Perhaps, even better than that, the Jabber protocol provides multi-user chat-rooms, where the order of messages is defined and consistent - meeting our collaboration requirement. Extending that to one-to-one connections we can select a master to ensure ordering, and for local LAN / auto-discovery we have low enough latency that we can do likewise.

So after some initial design overview from Will, we hacked away happily - I spent much of my time re-immersing myself in the calc core code. It is easy to forget how heroic the hackers that work on the top of LibreOffice are - after all, the lower layers of the system are shared, and have more use and polish. I dug at the view code, and ensuring that the ScDocFunc object, was used - splitting large operations (such as cell entry) into a series of smaller, simpler operations in an undo transaction on the model.

Eike meanwhile worked to get our unit tests working with various main-loop integration horrors under control, and the basic communication channels created and sending messages from A to B. Then he connected that to my lame demonstration protocol work to get messages and co-editing flowing.

Will - providing invaluable design input, hacking help, debugging assistence, API work, an 'Approver' to handle incoming connection requests from mission control, chased down obscure g_signal and C++ exception mis-interactions, provided non-stop enthusiasm, and was an exemplary host.

We spent much of the week, Monday to Friday, from early until late at night closeted in a remarkably pleasant sunlight room hacking away, heads down - with occasional frustrated noises, shaking of the head at code in dire need of discipline and so on.

What does it look like


(awful image hack linked to movie above to avoid iframe/planet troubles). For those who dislike screencasts, a more shaky, real-camera and two side-by-side laptops version, where you can see rather less you can go here, failing that perhaps you'd like a much higher resolution, non-dubbed webm of the above.

Thanks

To Collabora (where dreams solidify into reality) for hosting us, and providing the invaluable advice, support and enthusiasm of Will Thompson - thank you: Rob McQueen, Philippe Kalaf, Guy Lunardi, Neil McGovern & team. To RedHat for Eike's time & of course to SUSE who pays your humble scribe.

Also to all those who supported LibreOffice financially, your generosity makes this sort of strategic travel possible, thank you.

What's next

This is really just a prototype, there is a lot of work to turn this into a product, ie. you will not be seeing this anytime soon outside of some Experimental feature in any shipping LibreOffice - so unless you actively want to help hack on it - please don't bother the developers with questions.

Next, is the Google Summer of Code, there are a lot of rough edges here for this demo, the instant-messaging contacts list needs finishing, connection setup and negotiation needs re-factoring and pushing down into the framework. Then of course, big chunks of re-work to slowly tease out a controller concept from the code, and ensure that it is interposed correctly between the Model and View / Scripting.


Another area that will need more work, is encouraging the Empathy client onto windows, and providing the telepathy framework in an easy-to-consume form there.

Of course, if you want to play with this, and/or see what new exciting things will come out of the next LibreOffice Hackfest, it would be fantastic to see you at:


For some good German beer, sausages, excellent company, and some intense co-editing of the code.

Get involved

Are you a developer ? do you want to get involved with LibreOffice ? Now is a better time to start than later. It's a good idea to get a generic build first, and do an Easy Hack to get confident that we welcome code contributions, and love to have new people involved.

Then if you want to hack on the telepathy integration - assuming that it has not been merged to master by now (if so the branch will be gone) you want to checkout the feature/tubes2 branch, build it and ask on the developer list which bit you could best work on.

2012-03-25: Sunday

2012-03-24: Saturday

2012-03-23: Friday

2012-03-22: Thursday

2012-03-21: Wednesday

2012-03-20: Tuesday

2012-03-19: Monday

2012-03-18: Sunday

2012-03-17: Saturday

2012-03-16: Friday

2012-03-15: Thursday

2012-03-14: Wednesday

2012-03-13: Tuesday

2012-03-12: Monday

2012-03-11: Sunday

2012-03-10: Saturday

2012-03-09: Friday

2012-03-08: Thursday

2012-03-07: Wednesday

2012-03-06: Tuesday

2012-03-05: Monday

2012-03-04: Sunday

2012-03-03: Saturday

2012-03-02: Friday

2012-03-01: Thursday

2012-02-29: Wednesday

2012-02-28: Tuesday

2012-02-27: Monday

2012-02-26: Sunday

2012-02-25: Saturday

2012-02-24: Friday

2012-02-23: Thursday

2012-02-22: Wednesday

2012-02-21: Tuesday

2012-02-20: Monday

2012-02-19: Sunday

2012-02-18: Saturday

2012-02-17: Friday

2012-02-16: Thursday

2012-02-15: Wednesday

2012-02-14: Tuesday

2012-02-13: Monday

2012-02-12: Sunday

2012-02-11: Saturday

2012-02-10: Friday

2012-02-09: Thursday

2012-02-08: Wednesday

2012-02-07: Tuesday

2012-02-06: Monday

2012-02-05: Sunday

2012-02-04: Saturday

2012-02-03: Friday

2012-02-02: Thursday

2012-02-01: Wednesday

2012-01-31: Tuesday

2012-01-30: Monday

2012-01-29: Sunday

2012-01-28: Saturday

2012-01-27: Friday

2012-01-26: Thursday

2012-01-25: Wednesday

2012-01-24: Tuesday

2012-01-23: Monday

2012-01-22: Sunday

2012-01-21: Saturday

2012-01-20: Friday

2012-01-19: Thursday

2012-01-18: Wednesday

2012-01-17: Tuesday

2012-01-16: Monday

2012-01-15: Sunday

2012-01-14: Saturday

2012-01-13: Friday

2012-01-12: Thursday

2012-01-11: Wednesday

2012-01-10: Tuesday

2012-01-09: Monday

Removing unused code in LibreOffice

One of the unfortunate things that LibreOffice inherited, as part of the several decades worth of unpaid technical debt, is unused code that has been left lying around indefinitely. This was particularly unhelpful when mingled with the weight and depth of the useful code we have around the place. Caolan McNamara of RedHat wrote a beautiful tool callcatcher that identified these unused methods, and in recent times in LibreOffice we've had an unusedcode.easy file in our toplevel with a list of methods that should be removed. It's pretty easy to find and expunge a method or two, with a quick git grep, and dropping a patch to the developers mailing list. To escape from a pile of administration recently, I knocked up a pretty nasty perl script to parse the git numstat output, to see how we're doing. That produces a fun graph:


It seems that over half of our unused code has now bitten the dust. Uunfortunately as we remove more, more wasteage tends to be revealed, which explains some of the upward jumps in the graph, nevertheless the trend is clearly down. One of the side benefits of the unsung heros working at the conversion of our old-style macro driven generics to modern STL is that this looses us several unused methods per class converted.

If you want to get involved with LibreOffice development, it doesn't get much easier than this - please do check out the code and have a go. For the more adventurous finding an unused destructor, without a matching unused constructor is proof of a leak that needs chasing, of which there are a handful.

Failing that, why not run Caolan's callcatcher over your project to see which nooks and crannies are surplus to requirements.

2012-01-08: Sunday

2012-01-07: Saturday

2012-01-06: Friday

2012-01-05: Thursday

2012-01-04: Wednesday

2012-01-03: Tuesday

2012-01-02: Monday

2012-01-01: Sunday


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)

Made with Pyblosxom