OpenScreen: an open-source screen recorder for shipping product demos

What OpenScreen actually solves for demo videos

The gap OpenScreen targets is the one between a raw capture and something you can post. A plain screen recording gives you a full-frame video with a wandering cursor and no sense of where the viewer should look. The polished version, the category the README credits to Screen Studio, adds a background, a smoothly moving zoom that follows the action, a scaled-up cursor, captions and a trimmed timeline. That work is normally done by hand in a video editor or paid for with a subscription recorder.

OpenScreen puts the recording and the polish in one desktop app. The README describes the output as ready to post to X, Reddit, YouTube, a docs page or a landing page, and lists the editing primitives directly: auto or manual zooms with adjustable depth, duration, easing and position; cursor size, smoothing and click effects; wallpapers, gradients or your own background image; motion blur; crop, trim and per-segment speed; text, arrow and image annotations. The intended user is a developer or product person making a short walkthrough, not an editor cutting a long-form video.

The project is a continuation rather than a fresh start. The README states that Siddharth Vaddem created the original repository and archived it after v1.5.0, and that development moved to getopenscreen/openscreen with his approval under the same name and the same MIT license. That history matters when you are reading old issues or comparing notes with someone who used the earlier builds.

How capture, editing and GPU export fit together

The repository layout tells you most of the architecture. The top level holds electron/, src/, crates/, build/, scripts/ and a workbench/ directory, and package.json declares TypeScript, Vite, Electron and electron-builder. So the shell is an Electron app with a Vite front end, and the parts that need real performance live in Rust crates compiled as native addons.

The build scripts confirm the split. build:native:mac compiles a ScreenCaptureKit helper, build:native:win builds a Windows Graphics Capture helper, and build:native:linux builds a PipeWire helper. There are separate compositor addon scripts for macOS, Windows and Linux. Capture is therefore platform-native code called from the Electron process, not a portable screen-grab library. The README states that export is rendered and encoded on the GPU with Metal on macOS, D3D11 on Windows and Vulkan on Linux, with an automatic CPU fallback. The topics list wgpu, and the build scripts fetch an ONNX runtime, which lines up with the on-device transcription claim: captions are produced locally, with no upload, and the README says they work offline.

A recording is saved as an .openscreen project, which the README describes as JSON. That file is the unit the CLI edits. The CLI can record headlessly, modify zooms, annotations and trims in the project JSON, and render MP4 or GIF through the same export pipeline with no visible windows, emitting NDJSON when you pass --json. On Linux, capture prefers the xdg-desktop-portal and PipeWire path; without them the app falls back to browser capture, which the README says works but with fewer capabilities.

Installing OpenScreen and recording a first demo

The README gives a different recommended route per platform. On Windows the recommended route is the Microsoft Store. Everywhere else it is the installer from the GitHub Releases page. On macOS you download the .dmg and drag OpenScreen into Applications; builds from 1.9.0 onward are signed with a Developer ID certificate and notarized, so Gatekeeper does not block them. Before recording starts you must grant Screen Recording and Accessibility in System Settings > Privacy & Security, and the README is explicit that recording cannot begin until both are granted.

If you are upgrading from a build older than 1.9.0, expect to re-grant those two permissions. The README explains why: earlier builds were not signed with a Developer ID certificate, and macOS ties the grants to the app's signature, so it cannot tell the new build is the same application. The README also notes that macOS 15 and later re-asks for screen-recording permission periodically, and that this prompt comes from macOS and applies to every third-party recorder.

Linux has its own prerequisites. The system requirements list xdg-desktop-portal and PipeWire for native capture and system audio. Without them, recording still works through the browser-capture fallback with fewer capabilities. The minimum RAM is 8 GB, with 16 GB recommended.

The fastest way to check that the toolchain works is the headless CLI. The README gives these two commands:

openscreen record --duration 20 --project demo.openscreen --json
openscreen export demo.openscreen -o demo.mp4 --json

The first records twenty seconds into a project file, the second renders that project to MP4. With --json the output is NDJSON, which is what makes the pair usable from a script or a CI job. The README points to the CLI reference at getopenscreen.com/docs/cli/ for the full flag set.

If you want to build from source instead, package.json pins the toolchain tightly. The engines field requires Node 22.22.1 and npm 10.9.4, and the package manager is [email protected]. The dev script is plain vite, and the full build chains the native helpers, the FFmpeg and ONNX runtime fetches, tsc, vite build and electron-builder:

npm run dev
npm run build:mac

Only run the second one on macOS; the Windows and Linux equivalents are build:win and the Linux native scripts in package.json.

The AI editing assistant is bring-your-own-key and off by default

The README describes an AI editing assistant that takes a chat instruction and applies it to the timeline: cuts, zooms, speed ramps, annotations, camera framing. You supply the key, and the supported list is Claude, OpenAI, Gemini, Mistral, OpenRouter, MiniMax, or any OpenAI-compatible endpoint. The README states that nothing is enabled by default.

That default is the right call and worth noting, because it changes what the feature is. It is not a hosted service bundled with the app; it is a client for whichever provider you already pay. If you work somewhere that forbids sending product footage descriptions to third-party APIs, the assistant is simply a feature you leave off, and the rest of the editor is unaffected. The transcription path is the opposite: the README says captions are transcribed on-device with no upload and work offline, so the two AI-adjacent features have different privacy properties. Do not collapse them into one category when you are assessing the tool.

The editable transcript is the more interesting half of the caption feature. You can cut from the transcript, and subtitle translation is optional. For a walkthrough with a spoken narration, cutting from text is usually faster than scrubbing a waveform, though the README also lists an audio waveform and timeline snapping guides for manual trimming.

Where OpenScreen is the wrong tool

The README says it plainly: OpenScreen is under active development, expect rough edges and occasional breaking changes, including to the .openscreen project format and the CLI. That is the single most important constraint on adoption. If you archive .openscreen files as source material for a documentation pipeline, an update can invalidate them. If you wrap the CLI in a CI job, a flag or an output shape can move. Pin a version and read the release notes before bumping.

The release history backs the warning up. The most recent entries are v1.13.0-rc.3 and v1.13.0-rc.2, both published on 2026-09-18, alongside the stable v1.12.2 the same day. Release candidates are the top of the list, which means the newest features land there first. If you need predictability, track the stable tag rather than the newest artifact on the releases page.

There are also hard platform floors. macOS requires 13 (Ventura) or later because ScreenCaptureKit is required for capture. Windows requires version 1903 (build 18362) with Intel 8th Gen or AMD Ryzen 2000 series or newer at minimum, and the README recommends Windows 11 with Intel 12th Gen or Ryzen 4000 series or newer. The README points to a fuller table with notes on older integrated graphics, which is a hint that integrated GPUs are the weak spot even when the CPU meets the floor.

Finally, this is not a general video editor. It handles crop, trim, per-segment speed, annotations and backgrounds. It does not claim multicam, colour grading, audio mixing or long-form timeline work. If your output is a forty-minute tutorial with b-roll, OpenScreen is the wrong end of the pipeline.

OpenScreen compared with OBS and Screen Studio

The searches people run against this project cluster around two comparisons, and the two differ in kind.

OBS Studio is a live production and streaming tool. You compose scenes, switch between sources, and record or stream in real time. Its output is a capture, and any zoom, background or cursor emphasis is something you add afterwards in another program, or build into a scene before recording. OpenScreen is the reverse: it records, then treats the recording as an editable project with zooms, cursor effects and annotations attached to the timeline, and renders the result through a GPU export pipeline. If you need to stream, or to capture a webcam and a game and an overlay simultaneously, OBS is the tool and OpenScreen is not. If you need one clean product walkthrough with a moving zoom, OpenScreen does that work in one place.

Screen Studio is the commercial product that defined the category, and the README says OpenScreen is the open-source entry in it, explicitly not a clone. The practical differences are licensing and cost on one side, and maturity on the other. OpenScreen is MIT-licensed and the README says it is 100% free for personal and commercial use with nothing behind a paywall. In exchange you accept the breaking-change warning, the release-candidate cadence and the platform floors above. A paid tool generally does not ask you to re-grant permissions after an upgrade or to check whether a project file still opens.

Recordly also appears in the search data as a comparison point. The README and repository files do not describe Recordly's approach, so there is nothing concrete to weigh it against.

Licence, maintenance and the cost of keeping up

OpenScreen is MIT-licensed, and the README states the continuation kept the same licence as the original repository. The practical implication is that you can use it commercially and fork it. The repository also carries a THIRD-PARTY-NOTICES.md file, which is where the obligations for bundled components live: the build scripts fetch FFmpeg and an ONNX runtime, and those arrive under their own terms rather than the project's MIT grant. If you redistribute a build, that file is the one to read. This is a description of what the repository contains, not legal advice.

The maintenance signal is straightforward. The repository is not archived, and the last push was on 2026-09-18, with releases published the same day. That is recent enough to call the project actively developed, and the README makes the same claim about itself.

The upgrade cost is the part people underestimate. The README asks for bug reports and warns about breaking changes to the .openscreen format and the CLI, so an upgrade is not a drop-in for anyone with automation. The macOS permission model adds a second tax: because grants are tied to the app signature, the pre-1.9.0 upgrade path forced users to re-grant Screen Recording and Accessibility, and macOS 15 and later re-asks for screen-recording permission periodically regardless. On Linux, a distribution change to PipeWire or xdg-desktop-portal can silently move you onto the browser-capture fallback, which the README says has fewer capabilities. None of these are blockers, but each one is a thing to check after an update rather than before.

Editorial conclusion

Adopt OpenScreen if you record short product walkthroughs on macOS 13+, Windows 1903+ or a Linux desktop with PipeWire and xdg-desktop-portal, and you are comfortable running release-candidate builds. Do not adopt it if you need a frozen project format for archival work, a full NLE, or a signed and notarized build on a platform other than macOS. Verify three things first: that your GPU path is covered (Metal, D3D11 or Vulkan, with CPU fallback), that the CLI flags in your scripts still exist in the version you pin, and that your Linux capture stack is present, because the browser-capture fallback drops capabilities.

Frequently asked questions

Official sources

1. getopenscreen/openscreen on GitHub
2. License: MIT
3. Project website
4. README
5. Releases