Stuff Michael Meeks is doing

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:

• 2004-08: StarDivision lands Java Media Framework (JMF) support for Solaris / Linux.
• 2004-08: Simultaneously they commited DirectX support - which is great, Windows had a different, higher performance implementation, with full native platform codec support, etc. Linux is left as a tier 2 platform.
• 2004-10: Noticing that perhaps the situation is not altogether ideal on Linux, (and ignoring my verbal advice to use GStreamer), an effort is made to add Xine support. A nice try of course, but shame about Xine's conflicting GPL license.
• Somewhere around here, StarDivision got slammed for picking the (still proprietary) Java implementation instead of the platform one. As I recall I stood up for them robustly; after all it was technically easier for them to use Java right ? - 'Sun are not evil'
• 2005-02: By early 2005, it is clear that not all is well:

  "I have tried all the dev releases of the upcoming OO 2.0 under Linux. Last I have had in use is the 1.9.77 release. In none of these the native insertion of video file in any format that I have tried (raw, avi, xvid, divx, mpg mpeg4) has worked. It simply can't play any of the formats I throw at it."

  At this point we have Xine and MPlayer mentioned, still the relevance of GStreamer hasn't sunk in.
• 2005-04: Around this time, we get some code contributed from the Helix guys, though it is never merged into mainline.
• 2006: Radek pushes his first cut of GStreamer support, and soon we are shipping something that actually works. Rapidly all Linux distributions pick that code up from ooo-build, or by manually extracting the patches.
• Finally you can play a .ogg inside your presentation, and it mostly works. Admittedly we hard-code a single backend implementation (GStreamer) for Linux, rather than adding a generic, 'select a backend' option.
• four year gap of disaster for Sun OO.o users - during which we try to encourage StarDivision to take our code, either under the LGPLv3 (preferred), or with assigned copyright and a liberal license (less preferred)
• 2010-07: StarDivision announce their re-write as if this is a miraculous advance.

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:

• Pros of Accepting and including existing code
  • Costs: zero dollars
  • Code ownership - means StarDivision can maintain existing contracts
  • Code ownership - means StarDivision can sell indemnity to others
  • No community fragmentation
  • Engineers can be focused instead advancing the state of the art
  • No impression of having spare resources to pointlessly squander
• Pros of Re-writing the code from scratch
  • Exclusive code ownership: anyone that wants rights for this small piece of code has to come to us, there is no liberally licensed equivalent.
  • perhaps macho posture: beat the little guys with glasses up ! it keeps them in line.
  • um ...

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.