Document Freedom Day and missing interoperability opportunities

On March 27 Free Software Foundation Europe was celebrating information accessibility and raising awareness of open standards by running Document Freedom Day. But how well does free software perform there?

Why even asking?

One might assume that free software honours open standards and is extremely interoparable, because all the information about file formats is freely available, contrary to proprietary software.

FSFE makes a point of that while talking about importance of compatibility:

Remember when you were sent an important file that your computer couldn't read properly? Remember having to buy or download a new application just so you could open an attachment that you needed for work?

Incompatibilities like this are usually caused by ways of storing information that are secret ('closed'), and privately owned ('proprietary'). They cause huge problems for people, companies, and governments, and cost society an awful lot in creativity, productivity, and efficiency. Incompatible standards are used to manipulate markets and allow companies to charge people huge fees simply for the privilege of accessing their own data. Closed standards are also the basis of the worlds worst technology monopolies.

Sounds about right, was it not for a few things.

First of all, reverse-engineering proprietary file formats isn’t as bad as it’s typically pictured by free software advocates. Often the problem is to find a developer willing to write the importing/exporting code in end-user software. This is exactly our (re-lab’s) experience with Corel DRAW, Visio, Publisher and a bunch of other file formats: we had no use for the knowledge we acquired until LibreOffice team got interested.

It is true, though, that project files tend to become very complex, with questionable design decisions piling up on top of each other and lots of version-specific changes. Hence software vendors typically discourage direct use of such files in 3rd party applications. Examples:

1. PSD specification wasn't publicly available until just a few years ago, and Adobe still wasn't exactly happy about that.
2. There was no documentation on XCF (GIMP's native file format) until Henning Makholm started working on xcftools and wrote it from scratch. The team still doesn't encourage fiddling with XCFs outside GIMP, although the reaction is mild: “If people do it right, where's the harm?”

The solution to ensuring compatibility between complex software is typically to use a file format that represents a subset of all features. Various non-destructive data (such as adjustment layers in image editors) is then “flattened” and becomes uneditable, although visual and/or audible representation of the project is the same.

Unfortunately this is where free software for multimedia production fails badly. Let’s have a look at three cases and explore missing opportunities.

HTML5 animation

The worldwide hatred for Flash is gradually decreasing, in part thanks to Apple’s decision to ditch the Flash player from iOS. However there’s a problem with free HTML5 animation authoring tools: they don’t exist, while Adobe already has Edge Animate.

Both of the two existing active projects, Synfig Studio and Tupi, currently focus on feature film animation and do not make any attempts towards HTML5 animation support. This is mostly due to lacking manpower. For instance, in an earlier conversation Gustav Gonzalez (Tupi) said:

HTML5 animation is tempting due to the fact that Tupi works with XML/SVG objects all the time, so it should be very possible to extend the exporting interface to support it. What is the only problem? This specific feature requires a L-O-T of work, and right now I’m really busy fixing a long bug list and coding around other features. Anyway, could the HTML5 format be part of Tupi extensions in the future? Of course!

On top of that, Synfig Studio and Tupi aren’t interoperable, although given the amount of users of both animation editors it sounds more like a corner case.

At the same time, LibreOffice team doesn’t seem to have a plan regarding HTML5 animation exporting from Impress, and Apache OpenOffice still mentions support for Flash animation on its GSoC2013 ideas page, admittedly, along with HTML5.

As far as we can tell, the only free authoring application that does some actual work towards standards compliant animation is Inkscape, and that’s only thanks to developers of 3rd party extensions, such as Sozi and JessyInk (this one is also shipped with Inkscape).

Compatibility between non-linear video editors

Proprietary video editing software relies mostly on two file formats for exchanging data: EDL and AAF. E.g. these are the two file formats that Adobe Premiere uses to make its project data available in software made by other vendors.

What about free software? Only Cinelerra opens and saves EDL, Blender only imports EDL files, and a 3rd party script exports EDL from Kdenlive project files (Blender fails reading those). None of the existing free video editors reads or writes AAF. Is there a plan?

• PiTiVi needs the EDL support to be implemented in GStreamer Editing Services, AAF support was only discussed in the past (around 2007).
• Kdenlive needs more developers for EDL support, AAF was only briefly discussed in the mailing list years ago.
• Novacut tracks AAF support (and not EDL yet), but it seems to be a low priority task.
• Blender has no records of tracking AAF support as a desired feature (unless this wiki record counts for one), same for exporting EDL.
• OpenShot tracks a request for EDL, but not for AAF.

Compatibility between digital audio workstations

The situation is pretty much the same with DAWs: you cannot easily go from Qtractor to Ardour or MusE, or vice versa. Even though their file formats are, technically, open and XML-based, there are no converters available.

None of the free digital audio workstations or MIDI sequencers supports OMF files either. Ardour has initial code for that, but it hasn’t been worked on since early 2010, and Paul Davis recommends AATranslator as the solution, plus there’s also ArdourXchange (both proprietary).

Conclusions

While there are some very nice examples of support for open standards in free software, such as OpenDocument, COLLADA, or OpenRaster, the community still needs to do a lot of work to make free software an encouraging example of open standards’ use.

Interoperability doesn’t magically happen. Interested to work on it? Contact developers of your favourite projects and ask them, what kinds of contribution would help them to improve support for open standards.

Hint: you could even get paid for that, if you are eligible for participation at Google Summer of Code program. E.g. GIMP lists an OpenEXR plug-in among its GSoC project ideas.