We’ve talked at length about building a creative Linux workstation before. We’ve also discussed what viable alternatives to subscription-only Adobe and Autodesk products exist out there. You may have noticed that open source projects tend to be sparse in both pieces. There’s a very good reason for that — but it’s one that may not be immediately obvious if you’ve never worked in a creative field professionally.

This site is ad-free and always will be. Consider supporting us on Patreon if you like our work and want to see more from us.

Their exclusion has little to do with the fact that these applications are open source. It has everything to do with the outcomes that open source project incentives create. Projects like Blender — while flawed — are still usable in production, because the maintainers run the project differently than the majority of open source creative apps.

The norm, though, is that OSS creative software projects are driven by “scratching a coding itch” or technical curiosity. This isn’t an intrinsically bad motivation, but it’s one in direct conflict with meeting users’ requirements. As a project like GIMP or MLT reaches code completion, the maintainers become less receptive to criticism or change. They don’t want to hear that they implemented something incorrectly, or in a way that makes their software less usable.

Incentive Structures Matter

In commercial software, or open software governed by industry needs, the opposite happens. Maintainers change code that doesn’t work for users to retain customers and/or industry investment. It’s a bit of a chicken and egg problem for new open projects to go this route, because you can’t get institutional interest without adoption, and vice versa. It’s not unheard of though. There’s a Linux VFX reference platform and a whole host of Linux compatible open AV standards used every day in the creative industry.

Ironically, only commercial software (Nuke, Davinci Resolve, Filmlight, etc.) seems to care about properly implementing those open standards. Blender has made some progress here, but things like color management (via OIIO and OCIO) and implementing support for EXR, DPX, or open encoders for Prores/DNx are broken or non-existent. In the wider world of open creative software, things get bleak.

So, What’s Out There?

GIMP fails every metric worth mentioning here. The Linux sound architecture cripples native DAW functionality, and plugin support ranges from bad to unusable. Worse still, though, open video and VFX applications completely fail to thrive in the best supported category of Linux creative software.

Other than Olive, there are really only 2 open video packages in the FOSS ecosystem: MLT and Cinelerra. Cinelerra’s GUI is anachronistic to the point of being useless, but it does support a smattering of professional features like optical flow retiming. The most recent mainstream interest in the project comes in the form of a few articles on it from 2003. What’s worse is it isn’t even available in most mainstream distribution repos any more. You have to go out of your way to install this garbage.

MLT is both more modern, and harder to use than Cinelerra. Its various front-ends range from unstable to “pick this specific git branch if you want a working copy.” It mangles color. The timeline and effects plugins are single threaded and CPU bound. There’s no OFX support to speak of. No presets for Prores, DNx, EXR, etc. outside of the ffmpeg command line. The combination of stability and usability drawbacks make anything outside of short, low resolution projects extremely frustrating to complete. Before Olive, there wasn’t a single video application with a hint of potential for professional use.

Extending an Olive Branch

Given the previous state of affairs, you can imagine my surprise at just how good Olive is shaping up to be. It already has a node editor, modular interface, and seems to handle color management well for the most part. Olive even supports ARRI Raw in the latest builds. The NLE is still bare-bones at the moment, but the unprecedented display of competence shown by this project is staggering.

As a frame of reference, Blender, the most usable and user-responsive open source creative application, took more than 20 years to implement any color management at all, and still doesn’t support any popular video interchange formats properly. Olive has a much shorter history, and already lets you export to EXR and Prores, no problem.

I’m way beyond enthusiasm for most of the open creative software ecosystem, but Olive has me making feature wish lists and cheering on the sole maintainer every time he updates it. (Yes, you read that correctly. One person seems to be responsible for most of the code in Olive, and he’s working tirelessly on improving it.)

Olive Editor Exporting Elegantly

Olive will export to Prores, an extremely rare feature in FOSS

In fact, many features on my wish list are already on his development roadmap, including OCIO support, node-based effects and compositing, and standardized hardware acceleration that lets you make use of your GPU. There’s a few big features that are still missing, though, and they could be make-or-break for Olive’s adoption in production environments.

Making Olive a Well Oiled Machine

The first missing feature is a big ask, but it’s just as essential: OFX plugin support. Frei0r’s plugin library is OK in a pinch, but OFX is the (open) industry standard. This one feature would open the editor up so much, empowering users to extend the application in any way that suits their demands with a large library of existing plugins. Additionally, support for OFX plugins like Neat Video, Mocha, and color correction plugins like Nobe Remap would reduce his burden by reducing the need for native functionality that these plugins would provide. Getting OFX plugins working would immediately make Olive enticing.

The next feature might seem strange, but it’s nearly as important in the long run. I would love to see Olive completely standardize on VFX reference platform libraries. This might seem pedantic or confusing but, it makes supporting the many open standards I’ve previously mentioned easier, and versioning stays in lock-step with what everyone else in the industry is doing. In essence, it levels the playing field and makes extending the project easier for people with previous experience in the field.

Database driven media management isn’t as essential as those first two features, but it would be really nice to have. I can’t tell you how many times just re-linking a file or changing a source directory has saved my ass on a tight deadline before. It also helps people with fast turnaround requirements get started and keep going. By making the NLE aware of the video files on disk and building an extrinsic profile of said media, you open up a lot of possibilities for the people using your application.

Other Good Tweaks

There’s another, smaller ask that would make Olive a lot more attractive to professionals working in video production. It’s not a feature so much as a software distribution tweak: shipping RHEL rpm or .run packages. Everyone doing video on Linux professionally needs commercial software, and outside of RHEL and CentOS, commercial software support is horrible.

Since professional users are stuck on RHEL/CentOS if they use Resolve, Fusion, Syntheyes, Nuke, or any number of 3D suites, it makes sense to make that your 1st tier support distro for Linux. Centos is also the closest distro to the VFX reference platform out of the box, so it’d serve double duty in making a good build system. It’d also make implementing network rendering at scale easier, since most render farms and large studios run RHEL family distros on their render nodes.

Releasing an appimage is good, but an rpm or .run that actually integrates with RHEL systems would be a whole lot better. At the end of the day, no one employed to do video production is using Ubuntu or Arch or [insert laundry list of other distros here] if they need to use Linux at all, so it’s just not as productive to target other platforms directly.

Lastly, it would be phenomenal if he were to add an AVP/AIFF/xml timeline import function. the existing interchange format support is great, like I said, but most professionals are going to want to do round trip editing for post audio or color grading, and that’s not really possible with rendered out files.

Call to Action

It’s fun to speculate on Olive’s potential and sing its praises, but none of this happens without our support. Olive’s development is driven by donations. The maintainers have a Patreon, and their time is worth the money if you can afford to support them. If any open creative project deserves support right now, this is definitely the one. If they make the right design decisions, Olive could grow to change the video production landscape in a great way. We’ve put some of our money towards development, and hope you will in turn.


Consider Supporting us on Patreon if you like our work and want a say in what we cover and access to early content. We provide RSS feeds as well as regular updates on Twitter if you want to be the first to know about the next part in this series or other projects we’re working on. If you need help or have questions about any of our articles, you can find us on our Discord.