I’ve seen everybody hail Lightworks as the messiah that will make all other open source video editors irrelevant. So far, I didn’t blog about this (because frankly, life’s too short to be pessimistic, and I was also quite curious as to how it would play out and wanted to give EditShare the benefit of the doubt—after all, I’m a fan of video editing software in general).

However, after all these years, most of the blogs or news sites (including the most popular ones) still don’t bother checking for factual accuracy and just blindly accept what corporate press releases would have them believe. I would have thought they would have grown more careful with time, but the situation has generally not improved, to the point where I am now compelled to say this now, officially, in public: Lightworks is currently not open-source and never has been. Furthermore, if it ever is open-sourced, it most likely won’t be anywhere close to a truly open project.

From what I’ve seen by reading the comments on these articles, the Lightworks forums or elsewhere, it seems that those who point out the very issue that I’m about to explain are routinely labelled as ungrateful, arrogant freetards or considered trolls to be banned. It is my hope that you will read this blog post with an open mind, and that you might see where I’m getting at with the last section.

The source code that never saw the light

EditShare announced two years ago their intention to make Lightworks “open-source” someday, and that’s it. They have never released any source code since then. A code drop was planned for 2011 and it was postponed indefinitely. Calling Lightworks an “award-winning open-source video editor” currently is a lie. Even if they do open-source it someday, until the very day they do so, that statement remains a lie. Such a statement can only be a “truth” when you start saying it after the source code has actually been released under an open-source license.

Until then, you can’t simply trust a corporation on that promise without some cautious skepticism. They have a ton of business imperatives and constraints: the bottomline, strategic direction, competition, logistical and legal challenges, investors to answer to… and virtually no compelling reason to open-source their product (we’ll come back to that further below).

Although I do have some faith that they might release it eventually, personally, after two years of waiting, I’m even beginning to doubt that. I’m not saying that EditShare wishes to do evil or just throw a marketing ploy together; I heard the numerous justifications/excuses along the lines of “we’ve got bigger priorities”, “we have a reputation to uphold” and “we’re stuck in legal review”, I just don’t buy those arguments.

Anyway. Whether or not not you believe they will release the source code someday is irrelevant, that’s not the point I want to make here in the first part. The point is: until then, it should not be considered open-source and should be treated with the default assumption that it may never be. If you see articles spreading inaccurate statements along the lines of “Lightworks is an open-source video editor” or “Lightworks, the professional non-linear video editor that was open-sourced in mid-2010” (instead of “Lightworks is supposed to be open-sourced sometime in the next decade, according to press releases”), please comment and request the authors to correct or back their statements with references to publicly available source code repositories. We cannot stand by while untrue statements are being repeated all over the place, it is a disservice to the public.

What if they do release the source code then?

Most likely scenario: it won’t change a thing.

It’s a million lines of code (compare and contrast)! Good luck attracting people to work on such a monster codebase with 20 years of history. Most of which has been on the Windows platform (some of which on DOS… before that, I don’t know). Those of you who have done software maintenance know what this means. If projects with clean, modern and simple codebases like Pitivi struggle to attract any developers at all, don’t expect a “community” of benevolent hackers to form around your project anytime soon.

(compare and contrast)! Good luck attracting people to work on such a monster codebase with 20 years of history. Most of which has been on the Windows platform (some of which on DOS… before that, I don’t know). Those of you who have done software maintenance know what this means. If projects with clean, modern and simple codebases like Pitivi struggle to attract any developers at all, don’t expect a “community” of benevolent hackers to form around your project anytime soon. The open source version will be crippled . As far as one can understand from their communications and their pricing page(see the image further below), there would be three editions: the open-source edition, the “free” (freeware) edition, and the “pro” edition. Currently, only the “free” and “pro” editions are available. The open-source version probably won’t support anything but, say, Theora and Vorbis. It wouldn’t make sense to have the “open-source” version have support for the codecs that their “free” edition currently offers: They can’t just bundle patented codecs for Free. Licensing those (if you can license those) is typically done on a “number of installations” basis and with limits on redistribution. You can’t do that with fully free and open-source software on which you have no control over. They won’t switch their plumbing to use GStreamer or ffmpeg/libAV, for various obvious reasons (technical, manpower, QA, control, legal, etc.). A significant part of their business model will be to differentiate the “freeware/premiumware” version from the fully “open source” (crippled) version. You want proprietary codecs? Pony up. This is how it works pretty much everywhere, and arguably, this is what their clients expect and accept. And that’s fine. As I said, it makes sense. For them and their intended clients. Ignoring the whole codec issue for a minute, it is possible that the “open-source edition” will be only a portion of the application (ie: “crippled”). Anything that touches DRM, trade secrets, whatever, might be stripped out—it’s hard to tell currently, as no source code has ever been released. If the current differences in featureset between the “Free” and “Pro” versions are any indication, then this might be a real scenario.

. As far as one can understand from their communications and their pricing page(see the image further below), there would be three editions: the open-source edition, the “free” (freeware) edition, and the “pro” edition. Currently, only the “free” and “pro” editions are available. The open-source version probably won’t support anything but, say, Theora and Vorbis. It wouldn’t make sense to have the “open-source” version have support for the codecs that their “free” edition currently offers: It won’t cater to those who want a simple, native application that is well-integrated with their desktop environment. Or those who want a workflow for on-set redundant assets management as their top priority (Novacut). It will only solve the problems of a particular niche.

Community-wise: there are many ways Editshare can screw their community management (see further below).

With all that in mind, it would be very surprising to see the open-source edition start appearing in your official Linux distribution repositories.

I might add some amusing observations from trying the beta:

You’re forced to accept a EULA with a restrictive (non-free, non-open-source) license, which just confirms my points above about the various “editions”. However, do take note that the Lightworks beta was explicitely not the “open source release”. Again, that’s not the license the open-source edition is meant to be released under. Nobody knows what the chosen license will be at this point in time.

Lightworks is riddled with DRM and copy protections. It refuses to run in a virtual machine (such as VirtualBox) and cannot be run in a debugger (because it would be a threat to its copy-protection mechanisms).

Why would they even still care?

The typical Lightworks demographic usually doesn’t give a damn about the code being open-source. That’s secondary. They just want software that is reliable, efficient, supports their crazy formats, and is reasonably priced (bonus points if it’s free or very cheap, given the competition from other pro-level packages). “Open source”? Nice to have in theory, cool for bragging with friends at the pub, but not much else. Kinda like saying that you’re using a “green” product. The typical Lightworks user is never going to study or modify Lightworks source code.

With that in mind, what does EditShare hope to achieve? They’ll be lucky if they get more than two crazy geeks to hack benevolently on the code outside of their official paid developers. I know because I’ve dealt with open source projects for years, and even those that are incredibly well-managed and welcoming to contributors struggle to attract and retain them. EditShare is aware of this, and they express it with some snobbism (warranted, to some extent):

Of course users want software that’s written by us at this stage. Is there anyone other than the original developers of Lightworks, and the best of developers that have moved across to us from other products, who are better placed to move Lightworks forward? Of course there are great Open Source developers out there, but they would be working from a standing start. This is a specialist and complex product. We are not going to release it to Open Source until it is ready. Do to otherwise would cause untold issues.

It is quite clear that they are expecting to shoulder the whole burden of development and maintenance. If someone else bothers to investigate a bug and send them a patch for it, they’ll certainly consider it, but I’d be surprised to see them giving “commit access” to anyone else than themselves (but hey, who knows). If my guess is correct, we’ll just be inheriting another Cinelerra (except that the base application is arguably of much higher quality this time).

Open-source “product” vs open-source “project”

This subtle distinction is probably only obvious to those who are familiar with the open-source ecosystem (don’t flame me for my choice of words here, I’m trying to be comprehensible to the average person!), but there are countless ways in which EditShare LLC can screw up their “community” before even considering technical details like the ginormous codebase. They can screw up their licensing, they can try to exert too much control over the direction of the project, they can do like HeroineVirtual with Cinelerra and just release a monolithic code drop every six-to-twelve months, they can do like Sun/Oracle did with OpenOffice.org, like Canonical with their copyright assignment clauses, like Google does with its “read-only” open-source development model for Android, etc. That’s just from the top of my head.

It’s not the first time we see a company try to “open-source” a product and mess things up. And so far, EditShare has had a terrible track record when it comes to communication, multiple delays and broken promises, and just being clueless about how to properly interact with the “open” world generally speaking: the fact that they hyped their upcoming Linux alpha launch for months and then suddenly revealed, at the time of the release, that they were releasing it only to a select few insiders… All that without foreseeing the harm it would do to their already strained relationship with the public? That’s just pitiful—and terribly far from Kdenlive, OpenShot, Pitivi, and all the others whose development has occurred fully in the open from the start.

The greater ecosystem: being a good open-source citizen

An open-source project is not about throwing together a pile of code and slapping a copyleft license on top of it. It’s about a superior software development model (given equal manpower) where you foster reuse and collaboration with other open-source projects. It is about being a living cell of an organism, an active part of an ecosystem.

Lightworks might be released under an open-source license someday, but unless they rewrite the whole application (which would make no sense), it’s still going to be one monolithic “bundle everything, do everything in-house” piece of technology.

This has all sorts of technical implications I won’t be getting into. More importantly however, there are some absolutely crucial implications on the greater scale of the “Free Software ecosystem” that I must mention.

When you contribute to open-source projects that have been doing things “the open-source way” (that is: depending on shared libraries and contributing to them—be it testing or providing fixes upstream), such as Pitivi/Kdenlive/OpenShot/etc., you end up fostering the use and improvement of the technologies that are the heart and soul of your open-source desktop/operating system.

In the long run, you end up improving GTK+, Qt, GStreamer, Webkit, Pango, FFmpeg/Libav, GES, MLT, Cairo, X/Wayland, goocanvas, Clutter, GLib, the icon themes and artwork… the list goes on.

Recently, over the course of two months, Pitivi contributors have reported (and often fixed) more problems in GTK+, GLib and PyGObject than EditShare could ever hope to achieve in a lifetime—and that’s not even taking GStreamer into account.

Lightworks, as far as I know, doesn’t use any of these. Improvements you make there will not find their way to your desktop or mobile device. Whatever you do with Lightworks stays within Lightworks—and that’s it.

If you take “collaboration with the greater cause” out of the equation, one might argue that you could just as well have bought a package on the shelves for 80$ way back in 2003, instead of spending years hoping for an open-source “project” to solve your problem. Unsurprisingly, that’s what many people do.

Post-publication updates: