Skip to Main Content
Improve Capture One

Request a new feature, or support for a camera/lens that you would like to use in Capture One.

Status Awaiting review
Workspace Feature requests
Created by matt windover
Created on Sep 3, 2026

Linux B2B case

I've said this before but I'll make my case in its own thread instead of as a comment. I am a user of C1 and I would like to be able to use this on linux, it would allow me to dump Windows. Having said that putting forward a real business case for a Linux port would likely be a win on two fronts for C1.

A lot of the discussion on the forms miss the actual business case for a linux version. This isn't just about personal OS preference or open-source philosophy; it’s about untapped b2b volume licensing and enterprise revenue. There are three distinct avenues where capture one is leaving money on the table:

  1. studio volume licensing: high-end vfx, 3d animation, and major film pipelines operate almost entirely on linux. Right now, these studios are forced to maintain separate windows or mac machines just for artists to process raw photo references. If capture one supported linux natively, these studios would purchase volume licenses to integrate it straight into their centralized pipelines alongside tools like nuke and davinci resolve.

  2. enterprise e-commerce (headless server): if redesigning the ui for linux desktop environments is the main bottleneck, consider a headless linux version of the raw processing engine. massive e-commerce studios and commercial catalog companies use linux servers to automate and batch process tens of thousands of raw files daily. a CLI or docker container for the capture one engine would let you capture that enterprise-tier server volume without needing a full graphical desktop port.

  3. the low-friction compromise (proton/crossover): if a native port is completely off the table due to dev resources, the easiest middle ground is valve's proton or codeweavers crossover. Valve has already done the heavy lifting to make complex windows software run seamlessly on linux. Spending minimal qa time to ensure the windows installer doesn't actively block proton/wine compatibility would take a fraction of the time of a native port, but it would completely remove the bottleneck for linux users who actually want to pay for a subscription.