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


2010-12-31: Friday.

2010-12-30: Thursday.

2010-12-29: Wednesday.

2010-12-28: Tuesday.

2010-12-27: Monday.

2010-12-26: Sunday.

2010-12-25: Saturday.

2010-12-24: Friday.

2010-12-23: Thursday.

2010-12-22: Wednesday.

2010-12-21: Tuesday.

2010-12-20: Monday.

2010-12-19: Sunday.

2010-12-18: Saturday.

2010-12-17: Friday.

2010-12-16: Thursday.

2010-12-15: Wednesday.

2010-12-14: Tuesday.

2010-12-13: Monday.

2010-12-12: Sunday.

2010-12-11: Saturday.

2010-12-10: Friday.

2010-12-09: Thursday.

2010-12-08: Wednesday.

2010-12-07: Tuesday.

2010-12-06: Monday.

2010-12-05: Sunday.

2010-12-04: Saturday.

2010-12-03: Friday.

2010-12-02: Thursday.

2010-12-01: Wednesday.

2010-11-30: Tuesday.

2010-11-29: Monday.

2010-11-28: Sunday.

2010-11-27: Saturday.

2010-11-26: Friday.

2010-11-25: Thursday.

2010-11-24: Wednesday.

2010-11-23: Tuesday.

2010-11-22: Monday.

2010-11-21: Sunday.

2010-11-20: Saturday.

2010-11-19: Friday.

2010-11-18: Thursday.

2010-11-17: Wednesday.

2010-11-16: Tuesday.

2010-11-15: Monday.

2010-11-14: Sunday.

2010-11-13: Saturday.

2010-11-12: Friday.

2010-11-11: Thursday.

2010-11-10: Wednesday.

2010-11-09: Tuesday.

2010-11-08: Monday.

2010-11-07: Sunday.

2010-11-06: Saturday.

2010-11-05: Friday.

2010-11-04: Thursday.

2010-11-03: Wednesday.

2010-11-02: Tuesday.

2010-11-01: Monday.

2010-10-31: Sunday.

2010-10-30: Saturday.

2010-10-29: Friday.

More API copyright nonsense

2010-10-28: Thursday.

2010-10-27: Wednesday.

2010-10-26: Tuesday.

2010-10-25: Monday.

2010-10-24: Sunday.

Repstrap gear construction

Reprap ?

The reprap project provides the designs and drawings necessary to make a self replicating, plastic extrusion 3D printer. There is only one hitch: self replication; you need a plastic printer in order to make one. Failing that you need to bootstrap your printing world by building a 'repstrap' - something that can (just about) print the pieces.

An ad-hoc repstrap

I have knocked together such a thing from spare bits of floating timber (mostly MDF and ply-wood), which has some unpleasant calibration problems: related to thermal issues, and a lack of an adjustable, (or even better heated) bed. Nevertheless it can be persuaded to print useful things. Indeed - arguably it is easier to cut a nice, rigid sheet of MDF, than to create isometric triangles made of studding with complicated plastic verticees. Anyhow - the beastie re-uses almost all the parts: steppers, controllers, belts etc. from an existing reprap - so you can re-use them in the final product (in theory). It also requires only simple hand-tools (except for the extrusion nozzle, and knurled driver which is a pain generally). It looks a little bit like this:

my repstrap

Notice the horrific warping problems that come from poor print head - bed spacing calibration, and the lack of a heated bed. Still, this is one of the largest, and most problematic prints necessary to bootstrap. I have the vague intention to create useful drawings, and instructions to replicate/iterate it for others with low-precision tooling - but the joys of LibreOffice are ship-wrecking this aspiration currently. Please also note that the all-important safety goggles are just out of frame somewhere.

Making large z axis gears

One of the most fun problems of repstrap construction are the gears. After several attempts - to whittle gears from acrylic rod, to make them from MDF, and so on I hit on a near perfect solution, reproduced here for your gear-constructing pleasure.

It turns out that simple 30mm panel-pins fit rather snugly into the required timing belt, creating a nice firm fixing. So - this makes the construction of the large gears a matter of rough cutting vague disk shapes, (or better using a nice large circular cutter) four disks from thin ply-wood, then using the stencil linked below - marking out the pin locations, drilling them through (as vertically as possible) with a 0.5mm drill, and then simply pressing the pins through. This and a pair of nuts in the centre yields a beautiful, functional z drive, as modelled by my youngest, as she concentrates on reprap assembly thus:

large gear - with model

Stencils for gears

It turns out to be remarkably hard to draw gears, or lay them out manually by measurement. Luckily most people have a phenomenally accurate ink-jet printer. Thus simply print out this file: gears.odg - clearly using LibreOffice if you don't have it. Then use a bradawl to make holes to enlarge with a drill in the right positions.

Making stepper gears

These smaller gears present a real problem for ply-wood - which would just crack and split, and not provide enough purchase on the shaft of the stepper. After some initial semi-functional attempts with some aluminium, I discovered that the perfect material for small pin gears is near to hand, and luckily is stocked in your kitchen, it looks like this:

small gear - raw material

Naturally, it is only a matter of explaining to a suitably patient wife, her desparate need of a new chopping board, and the invaluable nylon is procured. To satisfy yourself that it is indeed a wonder material, try driving a panel pin into it 5mm from the edge, and then breaking it out. Attack the chopping block with a junior hack-saw or some such device, to make an octagonal piece of suitable diameter. Again use the bradawl, stencil, and 0.5mm drill as above. Drill a larger central hole, which should be of a slightly smaller diameter to the drill shaft (which should have flats filed onto it). Simply 'drift' (ie. wallop with a hammer) the nylon onto the shaft for a fool-proof fix. Eventually you end up with something beautiful like this:

small gear - finished

Why bother ?

Hopefully, after much more wood hackery, adjustment, suffering, remedial medical treatment and so-on you can finally produce a working 3D printer, and hence something actually worthwhile. While this is only a prototype - and died on the first attempt of a lawyer to bend it, the full (more solid) version has resisted the attempts of a long line of hackers in their eagerness to break the end off; enjoy:

prototype bottle opener

Of course, you really need to use RepSnapper on openSUSE for controlling that sort of thing.

2010-10-23: Saturday.

2010-10-22: Friday.

2010-10-21: Thursday.

2010-10-20: Wednesday.

2010-10-19: Tuesday.

2010-10-18: Monday.

2010-10-17: Sunday.

2010-10-16: Saturday.

2010-10-15: Friday.

2010-10-14: Thursday.

2010-10-13: Wednesday.

2010-10-12: Tuesday.

2010-10-11: Monday.

2010-10-10: Sunday.

2010-10-09: Saturday.

2010-10-08: Friday.

2010-10-07: Thursday.

2010-10-06: Wednesday.

2010-10-05: Tuesday.

2010-10-04: Monday.

Re-factoring C++ and the vtable problem

The opportunity

Consider that you have large piece of C++, over many years, for reasons unknown, it has accumulated (at least) four boolean types: FASTBOOL, BOOL, sal_Bool and of course the native boolean type bool. Now consider a class with a virtual method in it:

class Base {       ... virtual void setValue (BOOL b); /* A */ }
class Sub : Base { ... virtual void setValue (BOOL b); /* B */ }

Please notice that these two classes are highly unlikely to be in the same header file, and may even be separated by many leagues of code, so you might never notice.

A small cleanup

Now imagine that we want to cleanup this obsolete 'BOOL' to a 'bool' - that would be nice and pretty; so - since we are hacking on 'Sub' - we change it there, and we change all the callers in Sub's implementation:

class Base {       ... virtual void setValue (BOOL b); /* A */ }
class Sub : Base { ... virtual void setValue (bool b); /* B2 */ }

At this point we have a problem - we suddenly broke the functionality of the Base class, and anyone calling the virtual method A. This is because without realising it we introduced an entirely new method with the same name and a different signature - by the miracle of polymorphism. ie. now we have two virtual 'setValue' methods, and B2 does not override A. That is not good.

Of course, because this is a feature, the compile will just love it, and suddenly, magically compile a completely different piece of code, and better - since the change is almost invisible to the casual reader this will be a nightmare to debug. Interestingly changes such as the above may seem rare, but are only the top of the iceberg - a more common incidence of these crops up in 64bit porting, where there is some mix of different types down the virtual function chain - someone overrides with a different typedef - all of which previously resolved to 'int'.

How to avoid some grief

The (rather dumb) tool I hacked up today tries to avoid this sort of problem. It does this by noticing that when we make this sort of slip, we add a new virtual method to Sub's v-table. Thus - if we simply print-out all the vtables sizes (in slots) before, and then after a change, we can rapidly check if they match. If there is a disparity - we can find the class that changed size, wind back to (all of) its parents, and work out which one is missing a suitable change. This technique was remarkably succcessful in finding 64bit portability problems (by comparing 64bit vs. 32bit builds) when Kendy was working on the original OpenOffice.org port to 64bit architectures. The tool is here

How to re-introduce grief

One final deep joy about C++ is that there is no real need to mark an overriding method as virtual (though most people, most of the time tend to). So we can write the original problem just as well as:

class Base { ... virtual void setValue (BOOL b); /* A */ }
class Sub : Base {    ... void setValue (BOOL b); /* B3 */ }

It is worth noting at this point, C#'s much better, and more readable syntax, mandating an 'override' for B3. Then lets re-add the great change we made before:

class Base { ... virtual void setValue (BOOL b); /* A */ }
class Sub : Base {    ... void setValue (bool b); /* B4 */ }

So - now we have an even nastier beastie - in this case by changing the type, we suddenly stop overriding A, but instead of creating a new virtual method, we create a normal method B4. Worse - this doesn't change the size of the vtable - so it is even harder to notice. At this point, at the moment - you loose.

All is not lost (in future)

Fortunately, this shouldn't be entirely the end of the story; in subsequent iterations, it should be easy to add a 'method count' that can be calculated for each class - and compared before and after, this would allow B4 to be detected rather easily. Perhaps tomorrow I'll expand the tool to do that too. Probably I am missing some other obvious gotchas, but getting this wrong - particularly in deeply inherited hierarchies, with complex interactions can create some particularly nasty problems to debug.

2010-10-03: Sunday.

2010-10-02: Saturday.

2010-10-01: Friday.

2010-09-30: Thursday.

2010-09-29: Wednesday.

2010-09-28: Tuesday.

2010-09-27: Monday.

2010-09-26: Sunday.

2010-09-25: Saturday.

2010-09-24: Friday.

2010-09-23: Thursday.

2010-09-22: Wednesday.

2010-09-21: Tuesday.

2010-09-20: Monday.

2010-09-19: Sunday.

2010-09-18: Saturday.

2010-09-17: Friday.

2010-09-16: Thursday.

2010-09-15: Wednesday.

2010-09-14: Tuesday.

2010-09-13: Monday.

2010-09-11: Sunday.

2010-09-11: Saturday.

2010-09-10: Friday.

2010-09-09: Thursday.

2010-09-08: Wednesday.

2010-09-07: Tuesday.

2010-09-06: Monday.

2010-09-05: Sunday.

2010-09-04: Saturday.

2010-09-03: Friday.

2010-09-02: Thursday.

2010-09-01: Wednesday.

2010-08-31: Tuesday.

2010-08-30: Monday.

2010-08-29: Sunday.

2010-08-28: Saturday.

2010-08-27: Friday.

2010-08-26: Thursday.

2010-08-25: Wednesday.

2010-08-24: Tuesday.

2010-08-23: Monday.

2010-08-22: Sunday.

2010-08-21: Saturday.

2010-08-20: Friday.

2010-08-19: Thursday.

2010-08-18: Wednesday.

2010-08-17: Tuesday.

2010-08-16: Monday.

Why Oracle's Java Copyrights Might Matter

What Copyrights

By now so many, apparently well informed, commentators have noticed and written off the Oracle Java Copyright claims as applying to the open-source implementation, documentation etc. That of course seems weak: how likely is it that Google would have cut/pasted code or documentation into their Davlik implementation, given the intense scrutiny they knew would come eventually. Page 2, Clause 11 of the complaint gives some background:

Oracle America owns copyrights in the code, documentation, specifications, libraries, and other materials that comprise the Java platform. Oracle America's Java-related copyrights are registered with the United States Copyright Office, including those attached as Exhibit H.
And as we go on (Page 8, clause 38) we get to the real grist:

38. The Java platform contains a substantial amount of original material (including without limitation code, specifications, documentation and other materials) that is copyrightable subject matter under the Copyright Act, 17 U.S.C. § 101 et seq.

39. Without consent, authorization, approval, or license, Google knowingly, willingly, and unlawfully copied, prepared, published, and distributed Oracle America's copyrighted work, portions thereof, or derivative works and continues to do so. Google's Android infringes Oracle America's copyrights in Java and Google is not licensed to do so.

40. On information and belief, users of Android, including device manufacturers, must obtain and use copyrightable portions of the Java platform or works derived therefrom to manufacture and use functioning Android devices. Such use is not licensed. Google has thus induced, caused, and materially contributed to the infringing acts of others by encouraging, inducing, allowing and assisting others to use, copy, and distribute Oracle America's copyrightable works, and works derived therefrom.

'Code' is to my mind only an insignifiant and pointless piece of the picture here. An interesting piece to me is the specifications: is it possible that by simply implementing (and perhaps documenting) a new implementation of parts of the Java spec - you infringe Oracle's copyright ?

A bit of History

Despite all the interest (or apathy) stirred up by the standards wars of yesterday (OpenXML vs. ODF) etc. There are plenty of older, interesting pieces that have perhaps been forgotten. Looking back to before the dawn of time itself (1997), some interesting things crawl out:

Java ISO standards battle rages

Sun Microsystems achieved one thing of note - it was the first ever, and only corporate submitter to the ISO PAS process (this is rather like the quick-on-ramp 'fast track' that ECMA enjoys eg.). There is a great contemporary write-up from b-net here which seems surreal in its contemporary flavour:

Last November Sun Microsystems won the right to become a standards submitter over the fierce, and sometimes mud-slinging protests of competitors such as Microsoft, Intel and Digital Equipment Corp. Microsoft, in particular, challenged the right of one company to serve as the submitter of an international standard, claiming that this approach offered unfair market advantage. ... if the Java platform is accepted as the international norm ... it will become tied into the government procurement process.

Despite the opposition ISO accepted the first ever, and only corporate PAS submitter (Sun Microsystems) to ISO. During the process we got all these great quotes from a Microsoft standards strategist consultant Mr. Willingmyre, that could have been written about OpenXML / ODF only with some company names swapped:

Mr. Willingmyre wants to see Sun Microsystems "follow the rules of the international system. If they will not, they undermine the credibility of the system."
Or try Microsoft Program Manager (Charles Fitzgerald):
The problem with the Java process, to date, as Mr. Fitzgerald sees it, is that "Sun has been clever in using the PAS process to get the sanction of ISO (for its product), while keeping full proprietary control. Why do we care? There is a potential marketing advantage for a competitor. ISO is getting in the business of endorsing proprietary technology."... "If Sun is really the generous, altruistic charity they present themselves to be, then why are they not playing by the process?" Mr. Fitzgerald asks. "Sun has done more to clinically exploit the standards process than any company alive."

Of course in 1997, the whole right-thinking world was on Sun's side - clearly Microsoft had some embrace and extend wheeze going, which was per-se 'A bad thing'. Why should another company be able to get changes into Java that benefited their platform ? After all - in those days - Software Freedom was an idea with far less traction than it deserved: the concept of being allowed to hack about the code as you wished without getting strangled was alien. Anyhow, this struggle set an interesting precedent. As CNET of the time wrote Sun wins Java ISO approval:

Giving a single company submitter status is unusual for ISO. Normally. such status is given to trade groups or consortia. Similar status has been given to X-Open, DAVIC (Digital Audio Visual Industry Council), VESA (Video Electronics Standards Association), and IrDA (Infrared Data Association).

The real question is Why ? - why go to all that effort and fight to get something that no-other company has ever wanted or needed ? What was the purpose ? why not form a Java trade association, or use an existing submitter ? What was going on ?

Now we have it, lets not use it: abandoning PAS

My grasp of the details are sketchier here; but by May 1999 they had abandoned the PAS submission process:

As expected, Sun Microsystems Inc. will use ECMA as its route to the standardization of Java at ISO. In this way Sun hopes to be able to retain control over the future development of Java which it would have had to give up under new rules adopted by ISO's JTC1 committee and applied to the PAS process that Sun has now abandoned.

So - because they couldn't retain ownership, control, and make it an ISO standard they switched track to ECMA. Interestingly (in the same article), the year before Microsoft had shot down another ECMA standard, the Public Windows Inititaive (PWI) - preventing it from becoming an ISO standard - why ? was there some amount of loss of property ownership implied by making it a true standard ?

"The PWI was a Sun effort to get Windows APIs put into the public domain...

And, thus we see in another parallel sphere these (strange) ideas of ownership of APIs (the hot currency of the era) being protected. Thus it was odd that Sun - who fought at length to become the first ever corporate PAS submitter, never submitted a standard, and let that capability lapse; such that they lost it. The good news of May 1999 was this:

"Sun's already submitted a Java 1.2.2 specification to ECMA which will be presented to a meeting of the group's general assembly in Kyoto, Japan on June 24. ECMA is expected to vote on the spec in December. Then it goes to ISO for fast track adoption."

There are still optimistic sounding traces of this around -

This announcement ... fulfills the company's pledge to achieve ISO standardization of the Java technology.

Sun drops ISO Java Standards Effort for good

Unfortunately, the fulfillment of that pledge never actually happened. CRN has a nice write-up from Dec 1999 here

During a meeting last month with an ECMA technical committee, Sun pulled specifications for Java off the table after copyright issues surfaced but was scheduled to resubmit last week.

What !? - copyright issues ? how can you have copyright issues around an open specification ? Who would want to retain copyright to an open specification ? and why ?

The speculation bit

My suspicion is that Java is protected by fairly weak patent protection. Ultimately Java - though it is some nice mixing pot of features, bundled up with a lot of tech marketing with great deployment, is perhaps not incredibly innovative. Those who see parallels between Java and .Net and run around like headless chicken proclaiming immediate patent death around Microsoft and Mono - take note.

Why fight so hard to get Java standardised, and then withdraw it, just before it has to be submitted ? the official answer is obvious, summarised: Only Sun is brave and good enough to create the perfect Java - a standards body would just kill it, or worse let Microsoft, HP, Intel and others have some real say in its development. Of course - there is some truth here, sole control of it means Java could move quickly, comittees tend not to produce beauty etc. We have some great quotes from the time from Scott McNeally (as above)

"There are times when . . . things have to be moved at the speed of light and there are times when we need flexibility. We're not moving Java forward in a secret way, in a non-participative way." ... The company is actually losing money on Java, he said.
The idea of Java moving at the speed of light seems slightly laughable now, but perhaps a nugget of a hint as to why they really don't want an open standard is there. Personally I get a bit sick of this generic "pauper's defense": We are not making money, therefore ... anything goes here ... whether it is not contributing to the engineering or adopting malevolent legal approaches - it is sadly still popular today.

Some alternative explanations might be more convincing; with Java's weak patent protection, and general lack of novelty - a really important piece to allow control (ie. so you can't implement, and then extend this specification), and more importantly to allow monetisation of Java by Sun was, perhaps, copyright. Copyright around the API specifications and associated implementation choices (also, conveniently, critical to compatibility). Surrending Java to be a full ECMA / ISO standard - would mean that the opportunity was lost to monetise all the fairly random decisions Sun made in the Java API via copyright licensing. Thus - the submissions were pulled at the last minute. Oh, and bad luck if you travelled to a standards meeting half way around the world, at which no standard arrived. My suspicion is that this plays into the reason that today we have a copyright and patent lawsuit against Google by Oracle.

Copyright assignment and the 'community' process

Normally companies don't like to actually look that bad, so they come up with some twisted process to 'improve the optics', and thus we do (apparently) get a standards body in the Java Community Process (JCP). Clearly it is necessary to put feel-good terms in the name: 'Community' eg. Nothing could be bad with such a friendly name right ? One notable feature of the JCP (apart from its relative dysfunction) is that you need to sign a hefty assignment before you can take part (oh, and pay money to Sun if you are a company). This of course has heavy-duty copyright assignment language (cf. the toxicity of such things in general). There is also out-bound copyright licensing conditioned on passing the TCK (which is itself tightly tied up with proprietary bailer twine).

Interestingly for those that point to percieved weaknesses in the Microsoft Community Promise around .Net (incidentally big chunks of .Net are ECMA standardized, thus reducing the potential for standard / copyright licensing based aggression) - there are great clauses in the JSPA2 around patents that do the CP's necessary claims language to shame:

"For the purposes of this Section 5.B, patent claims covering the Specification shall mean any claims for which there is no technically feasible way of avoiding infringement in the course of implementing the Specification."

But you can't copyright APIs

Indeed, hopefully not. Having said that, the Java API docs that you can see eg. here have a license that is rather similar to the other terms floating out there - particularly those necessary to join the JCP, and the outbound Java licensing text. Hopefully Sun have published their APIs without a similar license at some stage in the past, but presumably lots of care and thought has been put into this out-bound licensing. Is there anyone that hasn't accepted those terms ?

Conclusion

Quite possibly I am deranged; copyrights around Java APIs, specifications, and documentation are not a real issue, they cannot be enforced, and the Sun drive to retain copyright ownership, and impose onerous out-bound licenses on their specifications was a pointless exercise, unrelated to Java's commercial exploitation. Quite possibly Oracle just wants to go on a wide fishing expedition inside Google with their copyright claims - who knows.

Ultimately though, closed-ness doesn't pay. It seems Oracle are now reaping the harvest of the lack of trust and open-ness that sadly characterised Sun's approach to most of its 'Community' engagement. That of tryingto have your cake, and eat it too. To have an ISO standard, but not surrrender ownership and control to others. To open source something but go around spreading license FUD and demanding proprietary licenses behind the scenes, and so on. Sadly this sort of attitude continues today, and not just in Oracle but many other companies. Would it have been so terrible if some of Microsoft's weirdo extensions to Java had become part of the Java standard, and been implemented / deployed everywhere ? would they even have won a vote in a TC if they were that bad ? Having said that - I have deep sympathy with the view that the political and semi-technical sphere of a standards TC is not a great way to drive product direction.

Of course - many in the Free software community approach problems based on their love of the underlying technology - de-coupled from a love of its current commercial owner. As such, we would advocate decisions that were good for the product, potentially at the expense of its current owner. So - what does this mean for people like us ? Guard your heart ! - try not to fall in love with a technology, and give yourself to developing and improving it, if a single company owns, and controls it. As a corrolary - try to avoid assigning your copyright to companies that might use it to harm you later. And finally - try to choose to support, and use good Free Software that grants wide patent and re-use rights under licenses like the GPL.

2010-08-15: Sunday.

2010-08-14: Saturday.

2010-08-13: Friday.

2010-08-12: Thursday.

2010-08-11: Wednesday.

2010-08-10: Tuesday.

2010-08-09: Monday.

2010-08-08: Sunday.

2010-08-07: Saturday.

2010-08-06: Friday.

2010-08-05: Thursday.

2010-08-04: Wednesday.

2010-08-03: Tuesday.

2010-08-02: Monday.

2010-08-01: Sunday.

2010-07-31: Saturday.

2010-07-30: Friday.

2010-07-29: Thursday.

2010-07-28: Wednesday.

2010-07-27: Tuesday.

2010-07-26: Monday.

2010-07-25: Sunday.

2010-07-24: Saturday.

2010-07-23: Friday.

2010-07-22: Thursday.

2010-07-21: Wednesday.

2010-07-20: Tuesday.

2010-07-19: Monday.

2010-07-18: Sunday.

2010-07-17: Saturday.

2010-07-16: Friday.

2010-07-15: Thursday.

2010-07-14: Wednesday.

2010-07-13: Tuesday.

2010-07-12: Monday.

2010-07-11: Sunday.

2010-07-10: Saturday.

2010-07-09: Friday.

2010-07-08: Thursday.

2010-07-07: Wednesday.

2010-07-06: Tueday.

OpenOffice & GStreamer ...

Back to the future

The other day the, secret, internal, 'from scratch' re-write of GStreamer integration was announced by StarDivision. You can read the wonderful news on their corporate blog. There is also some amusingly mis-directed marketing effort focused on Ubuntu as well. What does this mean for Linux users ? Nothing. With this great leap forward in Linux support you are unlikely to notice any difference at all; why ? Because all Linux distributions (SUSE, RedHat, Debian, Ubuntu, Mandriva, and more than I can list) have already been shipping GStreamer support since 2006. That was mostly written by Radek Doulik from Novell, with fixes from Redhat's superstar Caolan McNamara.

The real question is: Why would StarDivision want to draw attention to their traditional feature gap, by making noise about shipping multimedia support four+ years late ? while simultaneously alienating valuable contributors and continuing to tear down its developer community (that would love to help close OO.o's feature gap) ? if that interests you - read on:

Late to the party

Winston Churchill said that some people will always do the right thing ... after they have exhausted all the alternatives.. Now of course, for years I've been fondly wearing the GStreamer T-shirt, and promoting it as the future of multimedia. Sadly my 1st minor contributions were a bit late: in 2001, but the love is there; it's a great technology and a badly needed unifying force in the fissiparous area of media stacks. Did I mention I think it rocks ? it is eclectically owned and apparently developed as a traditional open-source project (despite lots of corporate investment).

Anyhow, despite (to my mind) the obvious-ness of GStreamer as the right backend to pick, StarDivision went ahead, chose and implemented the JMF support that they now admit is horribly inadequate; here is how things panned out:

The Bogus Quality argument

At this point, the people trying to market against a branch of the same code, with additional features added, start to cast aspersions on its Quality. This is about the only half-way plausible argument they can have without hurting themselves. After all - ooo-build is intrinsically more feature (and fix) full than the original it is based on.

Of course, this argument foundered pretty horribly on missing features like 'Media Playback', given that our GStreamer integration is fairly robust (no known bugs). Is overall product quality really higher with totally inadequate media playback ? Is it really that much better to have nothing than something ?

The other part of the quality argument is similarly self-serving and goes a bit like this: "Their bug fixes are of terribly low quality !", this is usually helpfully co-joined to "This is because they don't have a slow and complicated QA process !". Then, of course there is the FUD - usually trotted out by non-programmer 'community' gurus and swallowed by everyone "The code-base is impossibly complicated, only the original authors could fix it". Of course there is some level of self-stultification, among the arguments: if the original code is of such high quality, how can it be comprehensible only by its original author ? [ hint, code review, and care in coding is perhaps more valuable, long term, than black-box testing ]. Is the underlying code really -that- complex and impossible to hack on ? (usually not). Of course among the smoke of a FUD war, any meaningful metrics of whether these bug fixes are actually bad is never forthcoming; it is just assumed.

Of course, in my view we fix many more bugs than we introduce (there being no shortage of them despite the heavy-duty up-stream, black-box process), and we always have a feature edge, though it changes over time; in large part because we send a lot of our work up-stream ourselves.

Ultimately, since all code has some level of bugginess, it can be hard to discern, for the man on the street, what the best code is. Luckily the Quality argument boils this down to something trivially to understand and remember, irrespective of who wrote it:

"If StarDivision owns it - the code is of high quality, if not the same code is of low quality"

Community growth

Of course, developing duplicative code, in secret, internally, and then landing it on the world is not a great strategy for growing a developer community:

"Should I bother adding an OO.o feature, or should I hack on this cool game ?
Well - I know if I try to contribute to OO.o, it is going to be grief and pain, and my code will probably be re-written
or discarded; perhaps the problem has already been fixed in secret anyway. Lets get typing games ! ..."

Needless to say, this GStreamer duplication is not the sort of advert that we want out there, that encourages people to contribute. If code is developed in secret, and then dropped from a height on the project - there will be much reduced benefit from peer review, and external contribution all around. Moving in this direction is extremely unhelpful for the future of OpenOffice as an open and inclusive project.

More amusingly, perhaps, there is a cabal of non-developers and business partners who hang around advising StarDivision management on matters of 'strategic' importance, such as this - who of course get advanced notice of these decisions. It is an interesting strategy to empower these people, and not those writing code. It is also curious that, although the revision history of the new GStreamer support is now hidden (with a single code dump), the ten source module file names match our implementation, while differing from the windows, and xine backend pattern; probably just a co-incidence.

Who ?

I use the name 'StarDivision' above, since it has been made clear publicly that OpenOffice is run at arms length, as a nominally separate business unit. Indeed, Oracle's acquisition of it has only just fully completed. It seems a reasonable (if legacy) name. Perhaps it is a shame that some of the good practice and expertise around Open Source projects that Oracle has in-house is not effectively applied in this piece of the company. People like to give Apple all the credit for their control ambitions around language choice for their app-store, banning their competitors from the arena and so on. That seems rather unfair, Open-Office.org seems more of a crucible of software co-ercion innovation: in order to get your code included it appears StarDivision needs not only to own it, but to do so exclusively.

The Business Case

Clearly, I am a Free Software hacker, not a business man; thus of course, perhaps I've missed something hugely important here around control or somesuch, but since these actions are rationalized to StarDivision's own (humane, and clueful) developers with a pressing 'business' rational, lets look at the pros and cons of duplicating this in-house, vs. the alternative: accepting code ownership, under condition that it is also available under a liberal license:

Of course, I don't think StarDivision's management is actively malicious, they're certainly not stupid - so it is necessary to pad out the re-writing pros a little - there must be a reason: what is it ? Is it really worth fracturing the development effort, wasting resources, re-writing existing, tested, working code, and driving away contributors, simply in order to ensure that StarDivision are the only owner ? is this 'Open'-ness ? How likely is it that external contributors are going to re-write and improve a majority of the OO.o code-base in the next decade anyway (diluting the exclusive ownership) ? Why bother creating conflict and steam-rolling other contributors to this extent, purely in StarDivision's proprietary corporate interest ?

Of course, ideally we would just get the code into OO.o under the LGPLv3 (the outbound project license), it is a tragedy that such a cost is paid, simply in order for StarDivision to have the exclusive right to avoid its terms.

Please note, that this is not a competitive issue. Notice, I am not promoting Novell's version as years ahead of Sun's here. I truly believe that to get the best product for everyone we need a partnership and collaboration of developers inside and outside companies, to create a better OpenOffice for all.

Conclusion

This announcement is non-news, StarDivision re-wrote a small piece of community developed code, and plan to ship it in six months time (in OO.o 3.4). What little news content there is points to an increasingly closed, secretive, and unhelpful development process. Perhaps there are also clear signs of an unwillingness to compromise at all, and a slow dying of the belief that such a thing as an active, and helpful developer community is possible. Please remember that once we all worked together in a more productive and friendly way !

Of course, I anticipate more non-news, if management loses faith or interest in a developer community, and prefers to waste resources rather than working together with others, there are some obvious next steps: waste even more resources ! Unfortunately, as a side effect this yields the development agenda to others, and just builds more walls between those who have common cause to make the code-base better. What a tragedy.

Personally, I believe OO.o can really only thrive and grow if all the contributors work together. By work together I mean a public, transparent co-operation around well defined, fair rules; not a web of tangled back-room agreements. Absent that, I am not optimistic for the future of StarDivision, though it is perhaps positive that they are starting to take Linux integration more seriously - which could be good.

Finally, at some level, this is a sad thing; this is 2.5k lines of code re-written that didn't need to be written (against the current ooo-build patch set size of ~673k LOC). That is a loss of 0.4% of the ooo-build 'edge'. As OO.o, and it's customers finally arrive (in multimedia terms) where ooo-build users were in 2006, I hope they like the scenery: we have long since moved on, as one example: to multi-slide audio.

Update: Amusingly the announcement blog entry finishes: "Don't hesitate to give us feedback." - but strangely, the initial comments and discussion on the article have all been deleted: amazing - what is there to hide ? - the fact that this is duplication ? the bogus quality argument being deployed ?

Update #2: Comments just got re-enabled, showing the great hype on quality. As mentioned, having a fully-pluggable media backend where you can choose Xine or Mplayer or JMF or GStreamer is a terrible idea; hence hard coding GStreamer support. Though of course the calculus of maintaining features as patches imposes some limits to the re-factoring possibilities too.

2010-07-05: Monday.

2010-07-04: Sunday.

2010-07-03: Saturday.

2010-07-02: Friday.

2010-07-01: Thursday.

2010-06-30: Wednesday.

2010-06-29: Tuesday.

2010-06-28: Monday.

2010-06-27: Sunday.

2010-06-26: Saturday.

2010-06-25: Friday.

2010-06-24: Thursday.

2010-06-23: Wednesday.

2010-06-22: Tuesday.

2010-06-21: Monday.

2010-06-20: Sunday.

2010-06-19: Saturday.

2010-06-18: Friday.

2010-06-17: Thursday.

2010-06-16: Wednesday.

2010-06-15: Tuesday.

2010-06-14: Monday.

2010-06-13: Sunday.

2010-06-12: Saturday.

2010-06-11: Friday.

2010-06-10: Thursday.

2010-06-09: Wednesday.

2010-06-08: Tuesday.

2010-06-07: Monday.

2010-06-06: Sunday.

2010-06-05: Saturday.

2010-06-04: Friday.

2010-06-03: Thursday.

2010-06-02: Wednesday.

2010-06-01: Tuesday.

2010-05-31: Monday.

2010-05-30: Sunday.

2010-05-29: Saturday.

2010-05-28: Friday.

2010-05-27: Thursday.

2010-05-26: Wednesday.

2010-05-25: Tuesday.

2010-05-24: Monday.

2010-05-23: Sunday.

2010-05-22: Saturday.

2010-05-21: Friday.

2010-05-20: Thursday.

2010-05-19: Wednesday.

2010-05-18: Tuesday.

2010-05-17: Monday.

2010-05-16: Sunday.

2010-05-15: Saturday.

2010-05-14: Friday.

2010-05-13: Thursday.

2010-05-12: Wednesday.

2010-05-11: Tuesday.

2010-05-10: Monday.

2010-05-09: Sunday.

2010-05-08: Saturday.

2010-05-07: Friday.

2010-05-06: Thursday.

2010-05-05: Wednesday.

2010-05-04: Tuesday.

2010-05-03: Monday.

2010-05-02: Sunday.

2010-05-01: Saturday.

2010-04-30: Friday.

2010-04-29: Thursday.

2010-04-28: Wednesday.

2010-04-27: Tuesday.

2010-04-26: Monday.

2010-04-25: Sunday.

2010-04-24: Saturday.

2010-04-23: Friday.

2010-04-22: Thursday.

2010-04-21: Wednesday.

2010-04-20: Tuesday.

2010-04-19: Monday.

2010-04-18: Sunday.

2010-04-17: Saturday.

2010-04-16: Friday.

2010-04-15: Thursday.

2010-04-14: Wednesday.

2010-04-13: Tuesday.

2010-04-12: Monday.

2010-04-11: Sunday.

2010-04-10: Saturday.

2010-04-09: Friday.

2010-04-08: Thursday.

2010-04-07: Wednesday.

2010-04-06: Tuesday.

2010-04-05: Monday.

2010-04-04: Sunday.

2010-04-03: Saturday.

2010-04-02: Friday.

2010-04-01: Thursday.

2010-03-31: Wednesday.

2010-03-30: Tuesday.

2010-03-29: Monday.

2010-03-28: Sunday.

2010-03-27: Saturday.

2010-03-26: Friday.

2010-03-25: Thursday.

2010-03-24: Wednesday.

2010-03-23: Tuesday.

2010-03-22: Monday.

2010-03-21: Sunday.

2010-03-20: Saturday.

2010-03-19: Friday.

2010-03-18: Thursday.

2010-03-17: Wednesday.

2010-03-16: Tuesday.

2010-03-15: Monday.

2010-03-14: Sunday.

2010-03-13: Saturday.

2010-03-12: Friday.

2010-03-11: Thursday.

2010-03-10: Wednesday.

2010-03-09: Tuesday.

2010-03-08: Monday.

2010-03-07: Sunday.

2010-03-06: Saturday.

2010-03-05: Friday.

2010-03-04: Thursday.

2010-03-03: Wednesday.

2010-03-02: Tuesday.

2010-03-01: Monday.

2010-02-28: Sunday.

2010-02-27: Saturday.

2010-02-26: Friday.

2010-02-25: Thursday.

2010-02-24: Wednesday.

2010-02-23: Tuesday.

2010-02-22: Monday.

2010-02-21: Sunday.

2010-02-20: Saturday.

2010-02-19: Friday.

2010-02-18: Thursday.

2010-02-17: Wednesday.

2010-02-16: Tuesday.

2010-02-15: Monday.

2010-02-14: Sunday.

2010-02-13: Saturday.

2010-02-12: Friday.

2010-02-11: Thursday.

2010-02-10: Wednesday.

2010-02-09: Tuesday.

2010-02-08: Monday.

2010-02-07: Sunday.

2010-02-06: Saturday.

2010-02-05: Friday.

2010-02-04: Thursday.

2010-02-03: Wednesday.

2010-02-02: Tuesday.

2010-02-01: Monday.

2010-01-31: Sunday.

2010-01-30: Saturday.

2010-01-29: Friday.

2010-01-28: Thursday.

2010-01-27: Wednesday.

2010-01-26: Tuesday.

2010-01-25: Monday.

2010-01-24: Sunday.

2010-01-23: Saturday.

2010-01-22: Friday.

2010-01-21: Thursday.

2010-01-20: Wednesday.

2010-01-19: Tuesday.

2010-01-18: Monday.

2010-01-17: Sunday.

2010-01-16: Saturday.

2010-01-15: Friday.

2010-01-14: Thursday.

2010-01-13: Wednesday.

2010-01-12: Tuesday.

2010-01-11: Monday.

2010-01-10: Sunday.

2010-01-09: Saturday.

2010-01-08: Friday.

2010-01-07: Thursday.

2010-01-06: Wednesday.

2010-01-05: Tuesday.

2010-01-04: Monday.

2010-01-03: Sunday.

2010-01-02: Saturday.

2010-01-01: Friday.


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 ([email protected])
Made with Pyblosxom