Lightworks is not anywhere close to open-source

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.
  • 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:

    The upper portion of the comparison table between the free and pro version

    • 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.
  • 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.

  • Update: it is claimed in the comments below that Lightworks does use Cairo and Pango.

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.

47 thoughts on “Lightworks is not anywhere close to open-source

  1. EditShare is aware of this, and they express it with some snobbism (warranted, to some extent)…

    It’s not snobbism, it’s common sense. You forgot the Xara story too soon.

    but there are countless ways in which EditShare LLC can screw up their “community”

    What you just wrote is typically called FUD :)

  2. Couldn’t you say more before calling the arguments FUD? They sound rather sensible for me.

  3. The arguments sound sensible to you? Good for you.

    i don’t particularly approve (as if it mattered to anybody) of calling an currently closed source project an open source one, but going around and speculating about how a “competing” project has so many reasons to fail is exactly what FUD is. Check the dictionary.

    And then there is the whole cultural context thing. PiTiVi and LightWorks are driving towards community from opposite ends. Claiming that the other one is wrong is simply childish. You are not seeing things as people in a corporation. So what? It works for them.

  4. I doubt Lightworks is going to “fail” as a product. As an “open” open-source project however, with the way EditShare is handling things so far, things are not looking good, and I’m expressing my disagreement after a rather long period of observation.

    Especially worrying is the issue of the “ecosystem”.

    One might argue that an open-source “project” like we typically know is not the endgoal, and that would be a fair thing to say – to which I inevitably end up asking again: “Why do/would they care about open-sourcing it at this point then?”

    You are not seeing things as people in a corporation. So what? It works for them.

    Of course I can empathize with their situation and their probable viewpoints. I was taking those into account, for instance, when I was saying that “it makes sense for them”. Still, the fact that I’ve got a very different perspective (yet empathetic, I think) doesn’t mean I shouldn’t tell the public about the different ways these things are handled. I hope my text above (at the very least the last section) to be insightful in some way.

  5. FUD: Fear, uncertainty and doubt

    “FUD is generally a strategic attempt to influence perception by disseminating negative and dubious or false information.” (wikipedia: http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt)

    So you are claiming that all of his argumentation is false or dubious?

    He says that the program is not open source yet and if the open source development is not well handed it could result in a failure, from an open source environment point of view. At least that’s how I understood, I admit I didn’t give the text too much thought, I just want to understand how is this FUD.

  6. Good warnings, hopefully the future doesn’t turn out the way you portend.

    It’s important to note that EditShare’s whole plan was to get the codebase to a working level on GNU/Linux, Mac OS X and Windows before releasing the source code. Still, they’re just in the midst of an *alpha* for GNU/Linux and haven’t released much of anything for OS X.

    It seems a large part of your issue is that they’re not releasing the source code soon enough. While they could definitely do better in actually making this an open source editor, when they say it’s an open source editor is true. However, the open-sourceness clearly isn’t a high priority for the present time.

    Lets just wait and see.

  7. So you are claiming that all of his argumentation is false or dubious?

    I find it hilarious that you need to twist quotes to prove me wrong. The original says “negative and dubious or false”. And yes — it’s both negative and dubious. It’s how I see it. If you see fluffy bunnies instead — I’m glad for you.

    As an “open” open-source project however, with the way EditShare is handling things so far, things are not looking good…

    Things are not looking good for any existing open source NLE, in terms of being able to complete a commissioned project. One of the reasons I temporarily stopped producing screencasts is because even simple things take too long to accomplish. And even when I do use the software, it’s Blender’s VSE which isn’t your average NLE.

    Here is what you wrote above:

    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.

    Ye gods, how many bolds. Doesn’t it bother you that PiTiVi goes back to, lemme see, 2003? And still doesn’t do some fairly simple things? If this was an accomplishment contest, would you reach TOP10? TOP100? Then why the hell are you trying to make it look like one?

    It’s their code. They own it. If it takes 2 or 3 years to polish it before releasing, that’s OK by me. I’m fine about perfectionists. I’m one.

    One might argue that an open-source “project” like we typically know is not the endgoal, and that would be a fair thing to say – to which I inevitably end up asking again: “Why do/would they care about open-sourcing it at this point then?”

    Because they had that intention and didn’t mind telling about it?

  8. Too much/little coffee today?

    There’s no need to be agressive, I simply saw a claim to FUB without argumentation and wondered why.

    As far as I see it, the author claims that an open source project without available code has a problem, and could face more depending on how do they release the code, although I think that the author seems more concerned about an “open source environment” that don’t need to exist on the plans of the creators of Lightworks.

    Also, I’m not the author, why quote what he has said as if those were my words?

  9. Too much/little coffee today?

    I don’t drink coffee at all, thanks for your concern.

    although I think that the author seems more concerned about an “open source environment” that don’t need to exist on the plans of the creators of Lightworks

    Having their own environment seems to be part of their business model.

    Also, I’m not the author, why quote what he has said as if those were my words?

    I thought you were intelligent enough to see when I was talking to you, and when I was talking to the author. Was I wrong? I could start writing “@Daniel”. Would it help you?

  10. I don’t think Alexandre was confusing me with you, Daniel ;)

    I have to say I value his viewpoint just as much as mine. I’m fully aware of how crappy existing open source solutions are for getting even the basics right (let alone satisfying the needs of the prosumer or pro segment). I’m the first to admit the whole situation sucks. I’ve been waiting since 2004, and I’ve grown to be patient in a different way: I’ll be infinitely patient towards “fully open” projects, and I also have some respect (from an engineering standpoint) for state-of-the-art proprietary solutions.

    In other words, while never losing sight of the endgoal (ie: a pro-grade editing tool) for projects that aim for it (such as pitivi and kdenlive), my enjoyment now is in the process of seeing them evolve, rather than the actual “I require a pro editing tool, ASAP” need. This is what I meant with the ending of my blog post, when I basically said that if all I cared was about getting editing done, I would have used $insert-your-favorite-pro-editor-here back in 2003 and not bothered with all this.

    Also: Alexandre, let’s keep this discussion civil please :)

  11. @nekohayo

    If you point your finger at someone, thousands of fingers will be pointing back at you, so only compete against yourself and you’ll get head.

    Some years ago there where some very promising Windows builds of Pitivi, but they where ignored. If you guys would release Windows builds of Pitivi I’m sure you would see your user base and number of eager developers explode.

  12. tin2tin: I’d like you to point me to such Windows builds of Pitivi, beyond Andoni Morales’ one-day experiment in fixing bits of code and packaging it as a proof of concept. Afterwards, the package was not maintained and nobody else stepped up to offer their help on that front.

    When asked (in comments, or in my talks in conferences such as LGM), I always replied that we’re open to having a Windows (and/or Mac OS X) version of pitivi… if someone shows up to do the packaging and associated maintenance.

  13. @tin2tin

    You know, the “Windows port → more users → more developers” argument hasn’t proven to be correct for too numerous projects to mention. Even maintaining builds on regular basis is a living hell.

    E.g. Inkscape had probably half a dozen of releases delayed (I’m talking about months rather than days), because Windows-specific bugs couldn’t be fixed in a timely manner, or noone was available to make the builds. In fact, the team skipped announcing 0.48.3 for that very reason.

    I could go on listing examples. The fact is: the users/developers ratio on Windows is much smaller than on Linux., and once a maintainer is gone, you have a lot of unhappy users and you can’t do anything about that.

    Yes, there are some opposite examples like Firefox and LibreOffice. I’d call them exceptions.

  14. Hello Nekohayo,

    First off, THANKS a lot indeed for your very interesting article! By all comments I have read so far, it looks like it really enticed the interest of many readers :-)
    Believe it or not, I always read your posts with great care ;-)

    About Linux – open source video editors, It might have been useful in your article to mention Lumiera [1] and Shotwell [2] as well. Unfortunately, both softwares are NOT ready for professional use at present and who knows whether they might ever be (due to their lack of manpower)… :-(

    As for me, I hope Lightworks will succeed! IMHO it might be useful to spread Linux on the PC desktops a bit further. With Wine [3], for instance, to my knowledge, you can not easily run, on Linux, Adobe Premiere softwares (Elements 11 and Pro Cs 6). Even if you might do this, I doubt performances would be great…

    Personally, I would have NO problem to pay for using Lightworks on Linux (and I am aware of many guys who think the same…). If you think at Adobe Premiere Pro CS6, it costs more than 1000 euros and yet, professionals guys keep buying it. When you are a “professional” spending money for a software licence is an “investment”. You naturally hope to earn back “quickly” this amount with your personal work.

    This being said, I suppose even Lightworks might have some problems on Linux. I am NOT an expert on this topic (very far from it!) but it looks like:

    1. Its interface is not “standard” (it sports many windows floating over your desktop: it reminds me Gimp 2.6…);
    2. I have read some features will not work on Linux (their libraries are only available for Windows now);
    3. Its use is not “standard” compared to other NLE (e.g. working with the clips on the timeline).

    Please, correct me in case I am wrong (maybe these points are not completely true)…

    At present, on Linux, I think only Blender might succeed as a professional editor in the future. This because Blender has full time developers who work on it. Given the right motivations (that is, money in the form of sponsorships) they could improve their NLE feature much further. Blender is multi-platform and it is very stable both on Linux and Windows (I suppose on Mac too). To top this, its documentation (books, videos etc) is huge :-)

    I admire A LOT Pitivi and Kdenlive (not to mention Openshot) BUT IMO you *NEED* full time developers to work on a *professional* NLE. Otherwise, it might take centuries to have something as powerful as other Windows and Mac professional sofwares (e.g. Adobe Premiere Cs6):-(

    With Windows 8, even Movie Maker (the Microsoft NLE software you get when you buy Windows 8) will have many interesting new features [4]. For example: Stabilization effect on shaky clips, export to Mp4 (before Microsoft forced you to only export to wma format), new sound options etc. All Movie Maker old versions have already a Title editor and the ZOOM – Pan feature (which Pitivi now lacks…).

    At present, all NLE professional users are “spoiled” with tons of features to try. You need a VERY powerful software to get their attention :-)

    Maybe, even releasing a Pitivi build running on Windows would prove this not useful right now (to spread Pitivi use). This since, for instance, even Movie Maker on Windows 8 has already many basic features which now Pitivi lacks (e.g. the Title editor). NO offense here, I am aware these features are in the Pitivi pipeline… :-)

    My best regards (and, please, keep blogging)!

    Silvio Grosso

    [1] http://lumiera.org/
    [2] http://www.shotcutapp.com/
    [3] http://appdb.winehq.org/objectManager.php?sClass=version&iId=20644
    [4] http://www.pcmag.com/article2/0,2817,2408212,00.asp

  15. Well, it’s amazing how one could mess up article which actually has quite valid title…
    Do not forget that the people developing Lightworks are doing it for a long time and it is possible, just possible, that their stuff are much-much better then what we have as open source today. In that regards if they open it, one does not need to push patches to them, one could take their *open source* stuff and improve Kdenlive/Pitivi/WhateverUnsuccessfulVideoEditor

    Btw, there’s very little number of “pro level” media creation tools which “integrate” with ones desktop, 3DS Max, Ableton LIve, Cubase…, have very distinctive look, feel, workflow…

    P.S. As it shown today, there’s no useful open source “pro level” applications without “LInuxFoundation”/”BlenderFoundation” behind them. So, it just looks that for current FOSS video editors it’s much more sane path to go in amateur movie for dummies path…

  16. P.S. As it shown today, there’s no useful open source “pro level” applications without “LInuxFoundation”/”BlenderFoundation” behind them. So, it just looks that for current FOSS video editors it’s much more sane path to go in amateur movie for dummies path…

    Ardour would disagree with this statement when talking about “Pro Level” tools;) And considering i use it nearly daily (Along with Mixbus) to create lots of material I am paid for I would to:)

    Blender is useful for 3D, and very good at it actually. But I spent some time a while back trying out every video editor available on Linux trying to find something to replace Final Cut with, I did not have any luck. The NLE in Blender is great, but is strongest when you are creating media in Blender rather than editing other media created elsewhere, and I don’t think that should change personally, so even that really doesn’t apply IMO.

    In general I think Alexandre mentioned everything else I would say

  17. 1st. Editshare doesn’t plan on releasing code, until they have actually gone through the alpha, beta and probably the official release. So anything you have said on the matter is nothing more than speculation and more often then not, just plain FUD. As others have pointed out but i again will say – i have no problem waiting for source code if the plan is to work out the (major) bugs, first. (which we have already been doing in the alpha program – i had 3 bug fixed already).

    2nd, You are incredibly TRANSPARENT – you work on a video-editor that doesn’t even do some of the basics (of a circa 1990’s windows video editor), While lightworks is actually a reasonable video editor (and yes, i would know – since i am using the linux/alpha version and have years of experience with professional video editors ~ and by professional i mean video editors that aren’t pathetic, half-working GPL’d ones, like the one you work on. :\

    3rd, you claim the free version will be crippled, yet the difference between the pro and free versions is simply additional codecs / plugins – ie: HD related plugins, which you can obtain via subscription ~ which EditShare has little choice in, being as it’s licensed technology that they cannot give away, nor release sources for. So this really isn’t a case where the free version is going to be crippled. What it is actually a case of is a jealous gnome-developer spreading FUD, whom is pissed because the video-editor he works on is destined for the dustbin and will never be able to compete with LW.

    4th. LW is planned to have an ‘opencore’ model, not to be a purely open-source project. So maybe it will fail by your standard of what an OSS project should be. But from my perspective, i would rather have an opencore video editor (and pay for the extra plugins/codecs) than use a truly OSS video editor that isn’t competitive and truly sucks for editing video (which currently describes EVERY video editor for linux with _maybe_ Kdenlive being an exception).

  18. @Silvio Grosso

    You are wrong on points 1-2-3;

    1. LW’s interface is a single-fullscreen window, where (yes) there are many windows, but they are still managed in a single-window – so it’s nothing like Gimp 2.6. A better notion of LW’s interface, would be to compare it to Gnome-Shell. LW has dynamic-workspaces, where you can place it’s various windows/widgets (example, timeline, video windows, etc) and LW saves these positions on a per-project basis.

    2. LW does have binaries for linux, but only people participating in the Alpha-program have access (myself included). The current binaries are for Ubuntu, although there has already been discussion of a generic installer. (that being said, i have LW running in both Ubuntu and Archlinux).

    3. you DO use a timeline in LW – after all, it is an NLE – there are plenly of video’s on youtube or pictures on their website where you can clearly see the timeline.

  19. @Silvio Grosso

    Stabilization is nothing fancy anymore. It’s already available in Kdenlive via MLT (which derives code from vstab project), and in latest Blender. It’s a matter of time when this gets into PiTiVi.

  20. Reading through the comments have left me a little baffled. First of all I would think everyone would agree that until the day you have actually released source code under an accepted open source license, your project should not in any way or form be called ‘open source’. Announcing that you plan to release code no more makes your application open source than planning to learn the guitar makes you a guitar player.

    Secondly, people seem to think that LightWorks will have great code. Yes, there is a theoretical chance of that, but so far it has never been the case that a big closed source application has beautiful code. Even for successful open source projects like Mozilla/Firefox and OpenOffice their codebases what quite ugly upon initial release (and in many cases still is). This isn’t because the people working on these closed source applications were incompetent, but sacrificing code quality for making your deadlines is how things tend to pan out in a closed source setting (and often even in open source apps).

    And as for the code of Lightworks finding its way into other open source NLEs, that is extremely unlikely to happen to any major degree. The history and tooling of such code is most likely too unique to be useful for any other projects, just like OpenOffice code didn’t go into Abiword or KWord for instance. Only code that I could see coming out of this useful for anyone else is if there is code in there for specific codecs or hardware that might be re-purposed into a library. Like the echo cancellation code in Google WebRTC which has been pulled into a stand alone echo cancellation library now used by WebKit. But to expect large scale code migration is completely unrealistic.

  21. I think one of the biggest stumbling blocks for adoption is that the open-source A/V tools are written almost entirely by non-videographers. You do have a chicken-and-the-egg problem at work. The pro videographers started using the pro tools that were available at the time and have not switched to open-source ones and not around to comment on nor help with them.

    A basic issue is getting standards-compliant video. One must be aware of how video aspect ratios work and what colour spaces are. DVDs are a bit tricky, but the ITU Recommendations and H.262-264 documents are all available online. Even LAME has had its struggles, but to MP3’s ubiquitous use the problems with playback, bit reservoir, etc get noticed and reported rather quickly.

    For the projects to be more than an exercise in coding they must take into account basic standards. Look at Doom9 and videohelp.com and you’ll see people who know the stuff quite well. It doesn’t take long to get video-literate. Adobe’s Premiere was the joke of video-editing programs for years because it was an afterthought by the Photoshop and PDF company. When they made a really good program with CS 5 (and especially w/6) the forums had questions over the changes. It really indicated that Premiere’s fanbase was at a non-professional level whereas ProCut, Vegas, etc had qualitatively different queries. All my personal experience and blog reading has not indicated that (maybe before CS 4) many video professionals touched anything but Final Cut or Vegas (excepting Hollywood of course with Lightworks usage).

    The skill sets are not ones that overlap much unfortunately. Lightworks has got Hollywood dollars backing them but most creative tools on Linux are so far from what creative types would typically use. Audacity is the one hands-down awesome Linux multimedia program, but even that is much less intuitive than it should be. Compare the interface of GIMP with Photoshop wrt to a simple resize of a layer with one’s mouse. Hell, try to use the full capabilities of x264, ffmpeg or libAV outside of the command line….you can’t!

    The best thing PiTiVi has over its Linux competition is the interface which is “getting there”. Kdenlive while robust is a nightmare to navigate much like KDE brethren AmaroK. Likewise GStreamer has a great future, but the libAV/ffmpeg split has not helped (redup. of efforts), and due to the GPL licensing of the Yadif and Yadif2x de-interlacers, the de-interlacing is far behind VLC, MPlayer, avidemux.

  22. Gosh, these people in the comments look like PHP devs! Any criticism of their beloved product is to be denied! The Article is about this product not being Open Source! It talks more about Open Source than Lightworks. It’s a tale for people that care about Openness. There’s nothing in for you if you don’t mind using a closed-source product. Just disable auto-updates in your preferences and be happy! Just don’t go about saying that this is open-source because it isn’t. You should worry about this article if others of this kind also worry you.

  23. @Gaelsano

    Compare the interface of GIMP with Photoshop wrt to a simple resize of a layer with one’s mouse.

    Oh? I’m all ears.

  24. @gaelsano
    I agree with most of your post except this…

    Audacity is the one hands-down awesome Linux multimedia program, but even that is much less intuitive than it should be.

    Really? Have you used most of the true professional level audio creation/editing tools on Linux? Audacity is an audio editor, it has it’s place but I would say it is far from kick ass at that as well compared to professional tools.

    A realtime DAW is by far the tool of choice for most audio professionals, which while there are many selections out there my personal preference is for Ardour, which I use to edit and mix down audio in. I will pull out a single file editor on occasion, but it is far more common for me to use Ardour and only pull out the single file editor when needed.

    I do agree with your basic premise about professionals not being involved in the development for the most part. Maybe that is why I enjoy using Ardour, I tend to find it’s workflow very good for me as a professional, and I know of other professionals besides me that are involved in it’s development that help to make it so.

    Seablade

  25. Secondly, people seem to think that LightWorks will have great code. Yes, there is a theoretical chance of that, but so far it has never been the case that a big closed source application has beautiful code. Even for successful open source projects like Mozilla/Firefox and OpenOffice their codebases what quite ugly upon initial release (and in many cases still is). This isn’t because the people working on these closed source applications were incompetent, but sacrificing code quality for making your deadlines is how things tend to pan out in a closed source setting (and often even in open source apps).

    To be fair I think everyone was more than aware that Staroffice’s code was going to be crap when it was open sourced. In some ways I think the quality of the experience reflects the quality of the code, and Staroffice’s experience was VERY bloated to start with.

    Navigator’s experience reflects that as well, to a lesser degree. I don’t know about Blender’s experience to comment on that really when it was purchased back from NaN.

    I also haven’t used Lightworks yet, I am not a huge fan of their interface from what I have seen of it, but again haven’t used it. More important to me is that it can do the job that I need it to quickly and easily, I will learn the interface. But what I have seen of the interface does suggest it might be able to be improved, so my thought is that the code may reflect this as well like you mentioned.

  26. Hello.

    Without getting into a point-by-point response to the article, the central point is a valid one: Lightworks is not and never has been Free or Open Source Software, in the “pure” FSF etc sense of the term. We are moving in that direction, but we aren’t there yet, and so have not been using such terms to refer to any currently available version of Lightworks.

    Everything else is speculation.

    That said, the thrust of the article seems to be a few main observations, and a few others that are 100% speculation that don’t seem to merit a response:

    1. There will be limitations with the free and Free versions of Lightworks
    2. The codebase is huge, and “the typical Lightworks user is never going to study or modify Lightworks source code.”
    3. Whether EditShare will contribute back to The Community is an open question.

    So, to those points briefly:

    1. Yes. The Pro version exists because there are third-party codecs needed for professional production workflows that are not EditShare’s property to give away. There are restrictions on releasing code, and there are licensing fees required to implement them. Yes, projects like ffmpeg & x.264 exist and are useful, but there are questions about whether these can be used without interfering with relevant patents & licenses, and it is imperative that we be a good citizen here: we have to implement support for these things the right way, and that means in part that we are required to collect royalties for the license holders. Where necessary to charge fees, we’re basically going to pass this along at cost. Anything that we own & control, we’re going to do at no charge, and eventually we’ll release as much of the Lightworks codebase as possible to remain within these licensing requirements.

    2. Yes. This is high-end video production software, and the overlap between people that we anticipate using it and people that will want to modify & extend it is probably going to be nonzero, but very small. Thus, we have no choice but to assume that we are going to remain the primary developers of Lightworks. If that assumption is wrong, and a community of hackers springs up around it, that’s fantastic — we’ll welcome anyone that wants to get involved. But the software will continue to move forward regardless.

    3. Yes, it remains an open question whether EditShare will contribute back to the community. But it’s worth pointing out that most of our existing server product line is built around F/OSS technologies: we write software in Python, and we build servers running Linux, and we work with a variety of storage, archival, and networking software. We have developers participating in relevant mailing lists for these projects, and have submitted patches in the past in places where we’ve found ways to contribute back to the community. That will continue.

    The new role for us isn’t contributing back, but in managing a major open source project of our own. Obviously there is a learning curve to doing this right, and missteps will happen. We’re in it for the long game though, and we’re looking forward to it.

  27. @ESLightworks:

    Everything else is speculation.

    Given that the source has not been released, there are some points in this analysis here that cannot be anything else than educated guesses. If you end up proving them all wrong in the long run, fine by me. I think it is quite clear that I do not think you have any bad intentions, but that the technical and legal constraints you are working under make it such that this can never be considered a project that caters to the same needs as the other existing open source video editing projects (however crappy they may look like to you).

    I find it a bit exagerated to say that everything else in my article, including the section on “why would they still care” and especially the last section on the “ecosystem”, is worthless speculation.

    Whether EditShare will contribute back to The Community is an open question.

    Not under any reasonable foreseeable circumstances. Do you folks plan to replace your UI with clutter/webkit/gtk, use pango for fonts, do the work to allow an optional pluggable gstreamer of ffmpeg backend? Of course not. That wouldn’t make sense. And thus it is not an “open question” to me whether or not you will contribute to these projects that are the heart of the Linux desktop ecosystem: you’ve already got enough stuff to chew on. Maybe you’ll work with GPU vendors and the kernel for something that optimizes your product, but I don’t see much else unless you decide to rewrite a huge chunk of your codebase for fun and giggles.

    If that assumption is wrong, and a community of hackers springs up around it, that’s fantastic — we’ll welcome anyone that wants to get involved.

    I understand, and it is very noble of you to shoulder the burden of maintenance to begin with. However, I’d like to clarify the essence of my point, that you may have missed: if such a thing as an army of community hackers showed up on your doorstep to help, would you trust them enough to give them full governance over the direction of the project? ;)

    And about point #1, I’m fully aware of your situation/position regarding the redistribution of codecs. I don’t “blame” you for this. But those who are familiar with gstreamer and ffmpeg know what this means.

  28. I don’t mean to suggest that “everything else” in your article is “worthless speculation”, but rather that, as it is speculation, it wouldn’t be fruitful for us to comment on it one way or another. By all means, if you & your readers want to have a spirited discussion about such things, have at it, but in speaking for Lightworks, I can only comment on concrete facts, not suppositions about what may or may not happen.

    If you want to fault us for not contributing to things we aren’t involved with, well, okay, I guess. Not sure I follow your reasoning there though. Lightworks also doesn’t use StarOffice, nor (as far as I know) readline(); do we get dinged for those, too? (Personally, I’m a big fan of Request Tracker, but does it win bonus points for using half of Perl’s CPAN library? I’m not so sure about that.)

    To your penultimate point, again, that gets back into the realm of speculation: given that many of the details of the open source project haven’t been determined yet — what license it will use, whether it will be on Github or somewhere else, etc — it doesn’t make any sense to comment on how much autonomy “community hackers” will have. We can, I think, take as a starting point that it will be possible to fork the project, so if we do turn out to be poor gardeners of the Lightworks development community, then people with other ideas will certainly be welcome to head off in some other direction. But within the umbrella of the doesn’t-even-exist—yet project that we’ll be starting? We welcome good ideas. Whether or not others agree with our idea of “good” ideas is the same as others isn’t for us to decide.

    (Unrelated: What HTML is allowed in the text on your site?)

  29. Thanks for clarifications of intent – I don’t doubt that you collectively want to do the “Right Thing”. We will have to see how this plays out with the constraints you have to deal with.

    For HTML tags, I think it’s mostly http://en.support.wordpress.com/code/#html-tags (I’ve been adding blockquote tags around stuff in comments to improve clarity).

    The live preview/rich text UI is a good idea. I’ll have to search through available WordPress extensions that might do that.

  30. Came over from Dean Howell’s blog.
    So reading the mouthpiece’s words, as we stand now Lightworks IS NOT open source but it does use some open source technologies.
    That’s what I figured. Let’s hope bloggers pick that up (ya good luck with that lot!).

    Best line goes to Christian:

    Reading through the comments have left me a little baffled. First of all I would think everyone would agree that until the day you have actually released source code under an accepted open source license, your project should not in any way or form be called ‘open source’. Announcing that you plan to release code no more makes your application open source than planning to learn the guitar makes you a guitar player.

    Loved it.

  31. @garry: Sorry, but to clarify: Lightworks, as it stands today, is 100% proprietary software. I’m not aware that it used any F/OSS components in the current form, as most of the codebase predates most of the open source projects that it could potentially have borrowed from.

    EditShare, on the other hand, does use & contribute to the F/OSS community. Our primary business is in making servers & software for video production workflows, so we make storage servers, asset managers, archival systems, etc. Most of our servers run Linux, and the software atop these servers makes use of various open source technologies.

  32. @nekohayo

    Not under any reasonable foreseeable circumstances. Do you folks plan to replace your UI with clutter/webkit/gtk, use pango for fonts, do the work to allow an optional pluggable gstreamer of ffmpeg backend?

    Um, wait. Let’s be honest here. According to your logic, when GIMP developers quit Motif and created GTK+, they stopped contributing to the community. Is that so? :D

    Because, you see, anything that is released under a copyleft license is a contribution.

  33. @nekohayo

    Do you folks plan to replace your UI with clutter/webkit/gtk, use pango for fonts

    Lightworks already uses gtk+, pango & cairo..

  34. @Greatwhite:
    Simply encapsulating your custom widget in GtkWindow and not using the other GTK widgets does not seriously count as using GTK to me.

    As for pango: possible. Could you care to provide the source of that?
    Cairo: I doubt it. I definitely need to see the source of that.

    @Alexandre: you can guess that my view is along the lines of Christian’s. If some parts are wonderful and would benefit from being turned into a shared library, then it’s a positive contribution. But I don’t really expect any multimedia part (hello, patents and licensing) to be available as such. And Christian exposed the point better than I could do in this short paragraph.

  35. @nekohayo

    As for pango: possible. Could you care to provide the source of that?
    Cairo: I doubt it. I definitely need to see the source of that.

    I wrote it – I’m not sure how much more of a source you want. The whole of the UI is rendered using cairo/pango with the exception of the video windows which use OpenGL/GLX

  36. Oh, so you actually draw the shapes and widgets and all that using Cairo? That’s good news. I’m positively surprised, and I’m sorry then; you have to give me some slack for not having the source code to guess that one out ;) and for seeing too many projects using their own drawing library.

  37. Oh, so you actually draw the shapes and widgets and all that using Cairo?

    Absolutely

    you have to give me some slack for not having the source code to guess that one out ;)

    We’re working as fast we can :)

  38. @nekohayo

    If some parts are wonderful and would benefit from being turned into a shared library, then it’s a positive contribution.

    Excuse me, what’s a positive contribution? :) And, for that matter, what’s a negative contribution?

    It’s how you use it.

    I could think of at least half a dozen of possible ways the code could be useful, and none of them involve codecs. And I’m not even an NLE developer. And I haven’t even used the application.

  39. eslightworks, alexandre: I think the point nekohayo is making wrt ‘contribution’ is kind of a subtle one that isn’t clearly enough elucidated (and based on Great White’s last few posts, is actually at least partly simply wrong, which neko has acknowledged).

    Writing code and releasing it as F/OSS is of course a ‘contribution’, but to some of us, there are distinctions to be drawn. It’s a bit hard to draw clear lines, but there’s this thing called the F/OSS ecosystem, and we tend to think it works out better if you work within that than outside it.

    It’s probably easiest simply to look at a couple of extreme examples: Android’s UI layer, and GNOME.

    They’re both, basically, graphical user environments. They’re both F/OSS code. They’re both contributions. But Android’s UI layer is pretty much an independent entity that was created from scratch and doesn’t play nice with anyone else. The Android devs aren’t above snatching code from other F/OSS projects when it’s convenient to them, but they don’t consume other F/OSS code properly in its shared library form (most of the time) – they just grab what they want, link it statically, and start forking it to become something that’s useful more or less only to them. nekohayo referred in passing to GTK+, Pango, Cairo…these are elements of the ‘F/OSS ecosystem’ in that they’re maintained as general-purpose libraries and there’s a community around them, with a whole set of often unspoken rules about how you play nice: when you need GTK+ to do something it doesn’t currently do, you don’t just fork it, you write a patch, send it upstream, and consider other people’s use cases in doing so.

    I think this is what nekohayo was driving at: that he was assuming Lightworks was more of an Android than a GNOME, that its UI layer was probably written from scratch or at least not consuming GTK+, Cairo etc ‘properly’.

    Arguably a project like GNOME is more of a ‘contribution’ than a project like Android, because even though all the Android code is F/OSS, there isn’t a process and a community to hook it into the rest of the F/OSS ecosystem. If Android was a thin layer on top of GTK+, the GL libraries, the X libraries, Cairo, Pango etc, and the Android devs had built Android by contributing changes to those ‘ecosystem’ components and only writing new code for stuff that just wasn’t done yet, all their work on touch interaction, UI fluidity and so on would be there in the ‘ecosystem’ for everyone else to use. As things stand, it really isn’t: technically that code is open, but it’s in a codebase which isn’t really consumable by anyone else – Android isn’t neatly split up into generically usable libraries that other projects can use.

    That’s the distinction Jeff was suggesting, I think, but I suspect those of us who think in those terms are guilty of not explaining them explicitly enough. It’s something that seems ‘obvious’ when you’ve been working in the F/OSS ecosystem for years, but if you haven’t, it’s not obvious at all.

  40. What a troll article. Who cares about open source anyway. As long as we linux guys get a decent NLE its all ok. I am testing the alpha of Lightworks on Ubuntu right now – and even as an alpha it will blow every other crappy NLE (pitivi, openshot, kdenlive, cinelerra) out of the water easily. Lightworks is a pro tool for people who want a fast and stable NLE for serious projects. I dont need that open source tag. I am willing to pay a small amount of money to either support development by editshare or for licenced and high quality codecs.

    • Norm, if you do not care about open source, why do you even bother running Linux? As I said, you could have used one of the myriad of very good proprietary video editors on Windows and Mac OS ten years ago instead of waiting on Linux.

      If you don’t care about open source at all in your life, commenting here in that way is pointless.

      • See, you are unable to understand. I knew that beforehand. Running and using Linux has nothing to do with Open Source. Nothing at all.

        But people like you dont even understand this simple fact. Linux was my choice cutting cost and having a stable system for my work. A system I can setup to my needs. I take from the community and give back in terms of services. I use OSS as well as propriety software. So what ? You are totally wrong here. And it would be better to deny small-minded geeks like yourself access to the Internet. Linux and the Open Source community should get rid of people like you and be more open minded and tolerant. For you the world is black and white, for me and people like me the world is full of colours and shades. I don’t envy you.

        • You are free to run whatever you want, proprietary or not. Just don’t criticise those like me who stick to their principles.

Comments are closed.