getopenscreen · EtienneLescot · Sep 1, 2026 · Sep 1, 2026 · Sep 1, 2026
@@ -0,0 +1,39 @@
+---
+title: Picking up OpenScreen
+description: The original repo was archived after v1.5.0. I forked it, kept the name and the MIT license, and moved it to a new home.
+authors: [etienne]
+tags: [announcement]
+image: /img/og-image.png
+---
+
+The last commit on [siddharthvaddem/openscreen](https://github.com/siddharthvaddem/openscreen) landed on June 6, 2026. It bumped the Nix package to v1.5.0. Then the repo went read-only, like the README had been warning it would for a while. 39k stars, and v1.5.0 as the final release.
+
+I picked it up on June 15, with the original author's approval. Same name, same MIT license, new URL. This post starts a journal of what happens next.
+
+<!-- truncate -->
+
+## Where it lives now
+
+[github.com/getopenscreen/openscreen](https://github.com/getopenscreen/openscreen). It started as a personal fork and moved under the `getopenscreen` org in the first week. It stays there.
+
+The archived original is still online and still read-only. Every commit of it is in this repo's history.
+
+I tagged v1.5.0 on day one with no code changes at all. Same code, same installer, same version number. It only exists to prove the release pipeline works on my infrastructure before anything real ships through it. v1.6.0 is the first release with new work in it.
+
+## What I'm committing to
+
+Forking a popular archived project is a good way to quietly turn it into something else. So, written down where you can hold me to it:
+
+- Free forever, MIT. No paid tier, no premium features, no usage caps. Nothing is gated on who you are.
+- Stability before features. The recorder has to work on macOS, Windows and Linux. Bugs from real users go first.
+- It's not production-grade, and I'll keep saying so. Expect rough edges and breaking changes, including to the project format.
+
+The [roadmap](https://github.com/getopenscreen/openscreen/blob/main/ROADMAP.md) is public: record, edit, export, plus an optional AI editing layer that's off by default and never required. There's a [Discord](https://discord.gg/VvT6Vtnyh) with a roadmap channel if you want to argue about any of it.
+
+## It already had contributors
+
+Four days in, before I'd shipped anything, someone I'd never met opened [a fix for exports stalling](https://github.com/getopenscreen/openscreen/pull/4) when trim regions leave long decoder gaps. Real bug, correct diagnosis, regression test included.
+
+That's roughly what the job turned out to be. Very little of it is features. Mostly it's release candidates that mean something, CI that fails loudly, and diagnostics for the parts that break on other people's machines. Native capture on Windows and macOS is as finicky as its reputation.
+
+I'll write up what ships and what breaks here. Next: v1.6.0 and v1.7.0.
@@ -0,0 +1,50 @@
+---
+title: v1.7.0 was mostly written by people I'd never met
+description: Eight first-time contributors shipped most of v1.7.0, including memory-safe handling of long recordings and a software H.264 fallback. Before it, v1.6.0 built the release process that made merging their work safe.
+authors: [etienne]
+tags: [release]
+image: /img/og-image.png
+---
+
+Two releases in the first month, [v1.6.0](https://github.com/getopenscreen/openscreen/releases/tag/v1.6.0) on July 4 and [v1.7.0](https://github.com/getopenscreen/openscreen/releases/tag/v1.7.0) on July 19. The second one is the one worth writing about. Eight people who had never touched the project shipped most of it, and several of those changes fix things that had been broken since before the archive.
+
+<!-- truncate -->
+
+## v1.6.0, so that merging is safe
+
+The fork inherited a codebase with no release candidate process. Merging a stranger's PR into a project with no RC step means the first person to find the regression is a user, so this came first: RC tags, a promote workflow, release notes generated from the PR history.
+
+The Windows Graphics Capture helper, the native code that does the actual recording on Windows, got per-step stop timing and a diagnostic tool. "Recording fails on stop" is not a fixable bug report when all you know is that it failed, and it was the most common one.
+
+The Linux HUD got its drag handle back. The overlay's pointer-events handling made the bar unmovable there, which nobody had noticed because nobody on the original team ran Linux.
+
+Three PRs from outside landed in this one: the macOS cursor offset in single-window capture ([@giulio333](https://github.com/getopenscreen/openscreen/pull/22)), copy/paste for timeline region attributes ([@446f6e6e79](https://github.com/getopenscreen/openscreen/pull/33)), and a CI refactor ([@psychosomat](https://github.com/getopenscreen/openscreen/pull/40)).
+
+### The release branch rule
+
+If you maintain something with a promote step, this is the part to steal. One release branch per stable version, cut at the RC, frozen until promote. Only cherry-picked bugfixes land on it, and anything merged to `main` after the cut ships in the next cycle.
+
+I wrote that rule after the promote workflow tagged the tip of `main` instead of the RC snapshot people had tested. The release went out containing commits nobody had signed off on, and I replayed it. The rule is in the repo docs now and every release since has followed it.
+
+## v1.7.0
+
+Eight first-time contributors:
+
+- Large recordings stream instead of loading into memory. The editor and exporter used to run out of RAM on long captures, which made the app unusable for exactly the recordings people care most about ([@rainyflash](https://github.com/getopenscreen/openscreen/pull/74)).
+- A software H.264 fallback for Windows machines whose hardware encoder is missing or locked, which is a large share of corporate laptops ([@My-Denia](https://github.com/getopenscreen/openscreen/pull/73)).
+- The webcam recorder now starts after native macOS capture does, so the first seconds of camera footage stop vanishing ([@josiahcoad](https://github.com/getopenscreen/openscreen/pull/85)).
+- A fix for the cursor drifting out of place after a crop ([@SakuraiSatoru](https://github.com/getopenscreen/openscreen/pull/65)).
+- A notes window that capture ignores, so you can keep your script beside the recording without it showing up in the video ([@Itzadetunji](https://github.com/getopenscreen/openscreen/pull/43)).
+- Playback speed up to 100x, for finding the one moment you want in an hour of footage ([@rainyflash](https://github.com/getopenscreen/openscreen/pull/80)).
+- The Full Camera timeline effect. Press a key and the webcam PiP grows to fullscreen for a stretch, then eases back ([@rodrvc](https://github.com/getopenscreen/openscreen/pull/66)).
+- A custom gradient editor for backgrounds ([@psychosomat](https://github.com/getopenscreen/openscreen/pull/81)).
+
+The platform work in that release was mine. Preview recovery from WebGL context loss on Linux and Wayland. Vulkan off on Wayland so PipeWire capture can import DMA-BUF frames. webm duration patching rewritten so hour-long recordings stop killing the editor on load.
+
+## Why this matters more than the feature list
+
+An archived repo with 39k stars has a lot of people sitting on fixes they wrote for themselves and never upstreamed, because there was nobody to merge them. Reopening the repo released about a month of accumulated work in two weeks, from people who had already done it.
+
+That is the argument for continuing an archived project rather than starting a new one. The users are already there and some of them are already contributors.
+
+Next: v1.8.0, where an AI layer and a whole new rendering engine shipped under one version number.
@@ -0,0 +1,67 @@
+---
+title: v1.8.0, local whisper and a Rust compositor
+description: Export went from about 8 fps to about 126 fps, and the profile that explains why says the encoder was never the bottleneck. Plus an AI editing layer that runs on your own machine and stays off unless you turn it on.
+authors: [etienne]
+tags: [release, ai, rendering]
+image: /img/og-image.png
+---
+
+Exporting a 1080p60 project with full effects used to run at about 8 fps. The same project now exports at about 126 fps on the same laptop. The bottleneck was never the encoder, which is the part of this worth writing down.
+
+[v1.8.0](https://github.com/getopenscreen/openscreen/releases/tag/v1.8.0) shipped that on August 4, alongside an optional AI editing layer that transcribes and edits entirely on your own machine.
+
+<!-- truncate -->
+
+## The AI layer
+
+It is off by default. If you never turn it on, nothing downloads, no model is contacted, and you have exactly the 1.7.0 feature set. That was in the roadmap from week one and I don't intend to change it.
+
+Turn it on and you get four things.
+
+**Transcription on your machine.** Whisper via whisper.cpp, with Metal on Apple Silicon, Vulkan on Windows and Linux, CPU everywhere else. DTW word timestamps. Nothing is uploaded and it works offline.
+
+**Editing through the transcript.** Select words, delete them, the span is cut from playback and export. Word boundaries get re-anchored against the audio so the cut lands where the word actually starts.
+
+**Captions derived from the transcript**, instead of generated once and then maintained by hand. Restyle or regroup them with no regeneration step. Translation into 15 languages if you want it.
+
+**Editing by chat.** Describe an edit in plain language and an agent applies real timeline operations: cuts, zooms, speed ramps, annotations, camera framing. `Ctrl/Cmd + Z` undoes an agent edit the same way it undoes yours, with per-message rewind.
+
+The chat uses your own LLM key. Anthropic, OpenAI, Google, Mistral, OpenRouter, MiniMax, or anything OpenAI-compatible. Keys go in your OS credential store and requests go from your machine straight to the provider. There is no OpenScreen server in the middle, because there is no OpenScreen server.
+
+1.8.0 also *removed* the ChatGPT and GitHub Copilot sign-in options the pre-fork codebase had. Using someone's existing subscription there meant shipping GitHub's and OpenAI's own client IDs against endpoints they reserve for their own clients, from inside a signed installer. I didn't want to be in that position. If those vendors open a sanctioned surface, the integrations come back.
+
+## The compositor
+
+Export at 1080p60 with full effects ran at roughly 8 fps. The same project now runs at roughly 126 fps on the same laptop, an AMD Ryzen 5 7520U with its passive integrated Radeon. That machine is deliberately weak. Your number will be different. The order of magnitude is the point.
+
+It is one GPU-resident chain with no CPU readback between stages:
+
+```text
+demux -> hardware decode -> GPU composite -> RGB to NV12 -> hardware encode -> MP4 mux
+```
+
+I didn't set out to rewrite it. I first rebuilt the Canvas2D compositor to cache by what invalidates a cache instead of by layer. That was worth about 2x, and I verified it byte-identical (SSIM 1.000000 across all 1418 frames of the reference export). What it really did was make the profile readable: compositing was 79% of the time, encoding was 4.5%. The bottleneck was the compositor, running on the CPU inside a browser.
+
+Preview and export now both consume the same `SceneDescription` the app builds, so there is no second renderer to drift. The frame in the editor is the frame that gets written.
+
+## Three backends
+
+| Backend | Stack |
+| --- | --- |
+| Windows | Direct3D 11, HLSL, D3D11VA decode, hardware encode |
+| macOS | Metal (all nine shader entry points ported to MSL), VideoToolbox decode/encode, CoreText text rasterizer |
+| Linux | wgpu/WGSL, software H.264 encode, MP4 mux with AAC audio |
+
+There is a CPU backend too, software render and decode, picked automatically when there is no usable GPU. The UI tells you when you are on it, so a slow export has a visible reason.
+
+### The macOS decode detour
+
+Profiling the first working Metal export showed 74% of wall time in decode. The compositor was at 0.2 ms/frame. The hardware decoder pays a fixed per-frame latency, and OpenScreen's own capture writes Constrained Baseline H.264, which software decodes in a few hundred microseconds.
+
+So the decoder is picked by profile now. Baseline goes to software, which came out 2.4x faster end-to-end on the test export (182 fps against 76). High, HEVC and 4K go to VideoToolbox, where the arbitration flips the other way.
+
+## Still open
+
+Hardware encode on Linux. It is correct today and slower for being software. And every number above comes from one weak laptop, so discrete GPUs and Intel QSV still need real measurements.
+
+Next: v1.9.0 through v1.9.6 in twelve days, and v1.10.0.
@@ -0,0 +1,60 @@
+---
+title: Recordings that survive a crash, and an app you can actually install
+description: v1.10.0 put OpenScreen in the Microsoft Store, on Fedora and on ARM64, and made capture write fragmented MP4 so a helper that dies mid-recording leaves a playable file.
+authors: [etienne]
+tags: [release, distribution]
+image: /img/og-image.png
+---
+
+Two things in this stretch matter more than the version numbers. Capture now writes fragmented MP4, so a recorder that dies halfway through leaves you a playable file instead of a corrupt one. And the app finally installs the way people on each platform expect it to.
+
+That is [v1.10.0](https://github.com/getopenscreen/openscreen/releases/tag/v1.10.0), August 24. Before it, v1.9.0 through v1.9.6 in under two weeks.
+
+<!-- truncate -->
+
+## Losing a recording used to be possible
+
+A screen recorder that can lose the take is not a screen recorder. The old capture path wrote a single MP4 whose index is finalised at the end, so a helper crash, a forced quit or a dead battery left a file no player could open. The recording had happened. It was just unreadable.
+
+Capture writes fragmented MP4 now. The file is valid at every fragment boundary, so whatever was captured before the process died is still there and still plays.
+
+The same release stopped two other ways to lose work. The native webcam stream writes to disk while it records, so killing a recording can't take the camera track with it, and the Windows capture helper stopped hanging on stop, which used to require killing the process and losing the file.
+
+## Where you can install it now
+
+Most of v1.10.0 was packaging. Distribution is where free desktop software quietly fails: the build works, and nobody can get it.
+
+**Windows.** The appx goes to the Microsoft Store from the release build, with branded tiles. That is the route I'd recommend on Windows now. winget stopped skipping silently. There is no Visual C++ Redistributable dependency any more, and the OpenMP runtime the transcription backends actually import is bundled, so transcription works on a clean machine.
+
+**Linux.** Fedora RPM ([@Mundo-Dev0ps](https://github.com/getopenscreen/openscreen/pull/101)), ARM64 builds ([@zebster-cmd](https://github.com/getopenscreen/openscreen/pull/293)), and DMA-BUF negotiation so capture works on niri and other wlroots compositors, which had no working screen recorder from this project at all. Packages now respect the glibc floor of the distros they claim to target, declared and proven on a clean machine, and AppStream metadata is in place for Flathub.
+
+**macOS.** The Homebrew cask job runs again instead of sitting dormant.
+
+Capture is also DPI-aware and stops guessing which monitor you meant, and there is a GPU DXGI encode path behind a flag, opt-in until it earns the default.
+
+## v1.9.0, three weeks earlier
+
+v1.9.0 shipped August 5, the day after v1.8.0 was promoted. That is a backed-up queue rather than speed: the 1.8.0 RC window ran through nine candidates while `main` kept moving. The frozen release branch is the only reason the two didn't tangle.
+
+Two features in it:
+
+- Teleprompter mode in the notes window. Your script scrolls next to the capture, mirrored so it reads right in a webcam ([@My-Denia](https://github.com/getopenscreen/openscreen/pull/152)).
+- A headless CLI with `record`, `export` and `info`, driving the same engine the app does, which makes OpenScreen usable from a script or on a server ([@PeterTakahashi](https://github.com/getopenscreen/openscreen/pull/176)).
+
+It also removed a PID-file instance lock that could permanently brick startup, notarized macOS RCs like stable builds, and made the AppX package declare all 13 locales instead of one.
+
+## What changed in the patch releases
+
+v1.9.1, v1.9.2, v1.9.5 and v1.9.6 went out over ten days. 1.9.3 and 1.9.4 never left RC and their fixes rolled forward.
+
+Roundness, shadow and motion blur are on by default now, which is the look most people were assembling by hand on every project. The Windows cursor sampler became DPI-aware. The chat agent learned `addTrims` and `addZooms`, so asking it for a cut stopped costing a round trip through a slower path.
+
+Every release's regression pass is written up in the repo's testing docs, including the ones that caught a candidate breaking something. This site was rebuilt in the same window, and gained its light theme.
+
+## On `main` right now
+
+Webcam background effects have landed on all three compositor backends. Blur or replace what is behind you, including an AI cutout that doesn't need a green screen. The transcription helper reports its real timing and which compute backend it used, so "how long will this take" has an answer instead of a progress bar with no scale.
+
+Still open: hardware encode on Linux, and measurements on discrete GPUs and QSV. It is still pre-1.x, so rough edges are expected and bug reports are welcome.
+
+Three months, ten releases. [Discord](https://discord.gg/VvT6Vtnyh) is open if you want to argue with any of it.
@@ -0,0 +1,5 @@
+etienne:
+  name: Etienne Lescot
+  title: Maintainer, OpenScreen
+  url: https://github.com/EtienneLescot
+  image_url: https://github.com/EtienneLescot.png
@@ -210,7 +210,24 @@ export default async function createConfig(): Promise<Config> {
 						sidebarPath: "./sidebars.ts",
 						editUrl: `${REPO_URL}/tree/main/website/`,
 					},
-					blog: false,
+					// A development journal, not a marketing blog. Each post is dated to
+					// the milestone it covers, so the list reads as a timeline.
+					blog: {
+						routeBasePath: "blog",
+						blogTitle: "OpenScreen development journal",
+						blogDescription:
+							"Release notes with the reasoning attached, from the maintainer of the community-maintained OpenScreen continuation.",
+						showReadingTime: true,
+						postsPerPage: "ALL",
+						blogSidebarCount: "ALL",
+						blogSidebarTitle: "All posts",
+						feedOptions: {
+							type: "all",
+							title: "OpenScreen development journal",
+							description:
+								"What I have shipped since picking OpenScreen up in June 2026, and what broke along the way.",
+						},
+					},
 					theme: {
 						customCss: "./src/css/custom.css",
 					},
@@ -282,6 +299,14 @@ export default async function createConfig(): Promise<Config> {
 						label: "Docs",
 						className: "navbar-link-strong",
 					},
+					{
+						// A router link (not href) so it gets SPA navigation and route
+						// prefetch, like the Download CTA below.
+						to: "/blog",
+						label: "Blog",
+						position: "left",
+						className: "navbar-link-strong",
+					},
 					{
 						href: `${REPO_URL}/blob/main/ROADMAP.md`,
 						label: "Roadmap",