This is my (in)activity log. You might like to visit
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
Stuff Michael Meeks is doing
Up early, tech. planning call. 1:1 with Eloy, partner call.
Spent too long reading a very dense and rambling chunk of
on the apparent evils of Design by Committee.
A quick excerpt is:
"The main issues that we are facing today are mostly the
result of the managerial style of TDF in general.
Designed by committee:"
As should be obvious to anyone, the solution to committees
- is more committees. Apparently this new one would set a technical
direction that made more sense.
"If I were on the Board as a dictator ... immediate freeze
on all new feature requests and implementations. Then I would
have put a committee together ..."
It is interesting the credence he gives to a top programmer at Intel
with "years of coding experience" whom he has apparently
mis-informed. Lest we forget, Intel processors are written in TCL
which is a linguistic abomination, and apparently there are some
problems there too.
He writes: "Most probably, your beloved LO project does
not have any good coder." - I'm willing to admit I'm probably a
terrible coder: with only three decades of experience, but I've
programmed alongside many of our industry's outstanding programmer /
leaders and (in my view) the ability to handle complexity, which is
needed to effectively contribute to LibreOffice, ensures that
anyone with significant code included is an outstanding developer
who would be welcome on any sort of project; I salute them.
When it comes down to who contributes how
much of what - there are lots of different factors, but it doesn't
surprise me to see a long tail, even a Price's law
or Pareto principle
type behavior at work.
For more accurate numbers on the ecosystem checkout Vendor
My thesis is that LibreOffice's problems are
fundamentally economic. Eric seems to agree - his perscription
seems to be enabling widespread creation and sale of
proprietary plugins, templates and so on to fund TDF's new
committees. My last attempt was to build marketing incentives
for a diverse ecosystem and rewarding real contribution back
to the code.
Eric speaks of forking; but without any clear motivation for
it: is it to fix the code ? How can that code fixing be done
without finding, and hiring these amazing, (expensive) missing
developers he seeks ? and how can that be done without getting
the economics right ? - curious. As with any large block of
under-informed prose my problem is sorting the truth from the
Ultimately - I fear this whole article is a great exemplar of a
very typical approach here: loading yet more blame and criticism
on those who are trying to solve the problems in the code and
the project. We're all rather familiar with users blaming
developers for not doing more, perhaps it is our fault for caring.
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
Michael Meeks (email@example.com)