This is my (in)activity log. You might like to visit my employer
Novell which is an amazing company, and also
Dell who in days of yore provided me with a
free laptop for Gnome development / conferences.
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.
Stuff Michael Meeks is doing
Up early, dropped Srini at the coach stop, back to
breakfast with the family & Robert, on to mail, admin,
planning; and kiwi patch back-porting.
Google appear to have lost the plot, with yet-another
language, at least it seems
fairly simple - rock on 'gob'
or was it Vala ? or Eiffel, or ... < insert vast list of
obscure languages > ... The quest for balance - of
incremental value vs. relevance goes on.
Pete arrived, to fit a patch to our old carpet - looks
lovely, some cunning glueing thing, and a lovely hooked carpet
Perhaps one of the most totemic talks of OOoCon was the discussion
on: "a possible future architecture for openoffice.org" - also captured on video roll, and
just to irritate myself, I couldn't resist watching it
and had a few thoughts.
In summary - it would have been entirely preferable to have some
speakers with authority, programming experience and first-hand
understanding of the issues to present some competing visions in such
a session. It is also galling not to hear about the real structural
challenges to getting developer interest and investment that the
ownership and governance structure create. Finally, the hype around
UNO as part of the solution, when it is a key part of the problem is
Since - of course, this is OpenOffice.org - neither of
the two people giving the talk have ever contributed real code, or
apparently intend to, which neatly avoids having a visceral understanding
of the issues programmers face, or the existing overall architecture,
nevermind a future architecture.
Everything is necessarily re-fried second, or third hand guesswork
- this is fairly usual in OO.o 'community' circles - though, at
most normal conferences you tend to get laughed off the stage for
this sort of thing. Some good first questions when dealing with
apparently clueful OO.o-stable advocates are: "is there any code
yet?" and then "Did you write any of it ?". Sometimes we
have whole talks by non-coders about non-existent code. Yet, perhaps
Chinese whispers, when filtered through a strategic community genius,
can be woven into a fantastically compelling story - lets see.
Indeed - for a heady mix of truism, and balderdash, it's
hard to beat:
Luis: "To load writer you
have to load 85% of the code-base ... if you have a modularised
version, I imagine you can just open up the UNO code, which
is a core part that things are plugged into ... and then the specific
module you want - load time would be much faster, it would be much
lighter ... "
The realities of creative imagination aside, it seems to
me that the cult of UNO is itself, a large part of the problem,
stultifying re-factoring, reducing performance, confusing concerns:
such as code re-use, highly granular concurrency, and scripting bindings,
and forcing an all-or-nothing nightmare on everyone. Without it,
we might have more of a chance. The same kind of individual that
synchronised keyword is the last word in
concurrency just loves the UNO-for-everything attitude.
With regard to performance, it is amusing - often a
given UNO interface is sufficiently unusable that it is necessary
to create a C++ helper library to be able to use it in a lean
and effective way; this unfortunately tends, either to double the
library count (thus reducing performance), or mean you need to link
to the implementation itself anyway, reducing 'plug-ability'.
"... this [modularisation] results in a sustainable
community ... what I am interested in is making it so that ...
[ many ] people are able to develop OO.o as they want ...
Of course, creating a sustainable developer community is a great
goal - and one I applaud. It is (in general) perhaps a shame that
the clear advice of the existing external developers was not
highlighted. Indeed, this very talk crowding out some
thoughtful developer analysis, with marketing, could be seen
as a powerful signpost to the emasculation, oppression and
exclusion of the hacker class. Reducing the pundit
count is perhaps a pre-requisite for recruiting developers, who
don't easily tolerate this sort of thing. It is good to have an
expert view, based seemingly on no experience, that the developer
process is not bureaucratic - no doubt a great comfort in
the struggle to get code included.
The presentation of the OO.o code base as vast, and
impossible to hack on is strange. To me, some of the most
ghastly pieces to work with are the heavily 'UNO'ised 'designed'
pieces: configmgr, toolkit, and framework code leap immediately
to mind. Indeed - the simplest pieces I've worked with - eg. the
calc core, or VCL happen to be the 'legacy, non-UNO-ised' bits -
can that really be a co-incidence ?
The goal of " ... make it sustainable so people can
make a business out of it ... is a really nice idea, but the
primary problem in this area is, surely, Sun's ownership demands
which strangle corporate (and I imagine Government) investment at
birth - sign here to donate to Sun Microsystems.
A great truism: "... speculation gets us no-where
without actual bucks" - though arguably, you shouldn't have
to pay people to work on OO.o. If the project is structured
right - making it fair, and less of a pain to interact with - then
developers will slowly trickle in, feel valued, have fun, get
things done, and enjoy creating great software together for the
common good. At least, that is the OO.o community I want to be
Finally my kiwi image build finished, and I tested Marcus' nice
fix, which works well for me.
Saddened to see the EU's apparent lack
of understanding of the database world, in their complaints,
and the recent Sun layoffs. Simply because two things are called by
the same name - 'a database' - does not mean they necessarily compete:
is SQLite a meaningful competitor to MySQL ? - would anyone want it
if it was ? and Oracle already seem to build the preferred InnoDB
storage core for MySQL. Either way,
if I ever had to create a database, I would build on one using a more
open model, eg. you can't 'buy' SQLite,
or Postgres and thus
avoid this sort of problem.
In case it's not painfully obvious: the reflections reflected here are my
own; mine, all mine ! and don't reflect the views of Novell, The
Lithuanian Gov't or Arnold Schwarzenegger. 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 (firstname.lastname@example.org)