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
-
Mail chew, poked at slides, stats, financials.
-
Curious to see another extremely lengthy
set of thoughts on LibreOffice, let me answer some questions and inject
some facts as I see them:
- "Can you update the toolchains and APIs that LibreOffice
uses ?": yes, let's take the recent Skia
update - which has some numbers: seven person months of an expert
engineer; also - so far, not used on Mac and not default on Linux - so
we still have some benefits of consolidating on a new standard to win.
Anything is possible - but that's a lot of money Eur 100k as a lower bound;
and we continue to fix bugs.
- "Why don't we re-write everything from scratch ?":
in Rust (or whatever). This is of course possible in theory; it has even
been tried: watch Igor
Zaika's nice presentation, and his 'Pyramid' comments. Even with vast
sums of money and experienced engineers behind them they failed.
- "With what money ? with the donation money we have in the
bank ... I want to know why we do not have as many full-time, high-quality
coders as our money in the bank allows working on the code ?" - while it
is true that TDF has a problematic amount of donation money in the bank at
around Eur 1.2m, the excess we have each year over our staff and fixed
costs is very much smaller under Eur ~200k per annum. We are tendering tasks
in line with our mission at TDF to spend this. The process for proposing
things to spend it on is an open one, but is often, lamentably rushed due
to disorganization. Want something else done - get involved.
-
"Why don't we spend a lot of those donations on focused hackfests,
all year round, and pay the volunteers in beer and pizza to fix
the bleeping 10-years-old, and older, bugs?" - I'm not certain
that volunteers have all-year-round spare-time, and are long-term
motivated by beer and pizza (if we were allowed to buy that for them).
So - let's assume volunteer fatigue after the first month. We have around
sixteen thousand issues of various kinds in bugzilla. Let's say ten thousand
are old and need fixing. Each takes around a person-week to fix - that gives
a nice round two hundred person years (best case: assuming we create no new
regressions when fixing tough issues, no QA cost etc.). The average staff cost
at TDF is around
Eur 50k pa - plus management, overheads etc. So that's
around Eur 10m minimum we would need. To burst hire, train, manage, motivate
and review the results of 200 new engineers to tackle these quickly would take
an order of magnitude more funds. At the end we'd have a great product, with
more features, amazing interop, and so on - but it is also possible
that we would then find more problems. Finding the odd Eur 100m behind the
sofa is something of a problem, and spending also an issue.
-
Ultimately though this is the right question: how can we
build the economic environment right to attract this level of investment
to perfect LibreOffice? how do we project manage, schedule, and plan that?
how do we make the best engineering/business decisions? My strategy is
perhaps obvious: do what the paying customers want - and get more of
them, build a strong brand with that and use it in marketing to attract
more customers. Use that brand to differentiate yourself from the many
who just take the code, and contribute nothing back.
-
On the joys of go-oo
I agree it was fun; there was a community of
peer / developers, who were good to each other, and a clear shared problem.
Meritocracy was present there, in a way it is not at TDF, on that I agree.
However - go-oo was an alliance of packagers, with a few developers that
provided some polish and minor features around the incredible work that
Sun/StarDivision was investing in around OpenOffice.org. It was rather
easy to look good filling in the gaps they left. The code is still
there.
- "Tell me the answer for that and write it in a TDF's blog post.
I don't want to read through a thousand lines of mailing lists to fish
the answer, if there is any." - here to help of course, but too much
asking of questions that are easily answered by reading existing presentation
material could get annoying.
- Of course, everything seems easy to do when you don't have to
do it yourself. Vehemence is often inversely correlated with influence. I
was amused recently to hear Cannon J.John
note the great pity it is: that all those who really know how run the country
with incisive solutions for the world's problems are too busy driving taxis
and cutting hair.
-
My friend David amused us at the weekend with:
"What do we want ?" ... "Delayed Gratification!" .. "When do we want it ?" ...
-
Monthly mgmt call.
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)
