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 cutting knife.
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.
- 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 thinks Java's 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 involved in.
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 discouraging.
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.

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.

Stuff Michael Meeks is doing

2009-11-11: Wednesday.