Glonce

Rune IDE goes open source under GPLv3, plans a revenue share for contributors

toolsThe Glonce editorsHacker News🔥66Glonce rating66Impact65Novelty60Relevance70Surprise50Players38Credibility85

Unstable Build has open-sourced its IDE Rune under the GPLv3 and put the source on GitHub. The company frames the move as a deliberate alternative to what it calls a "reverse rug pull": rather than asking contributors to sign a broad contributor license agreement that could let Unstable Build relicense the project later, contributors keep copyright in their own contributions under the same GPLv3 terms as the rest of the code, and the company says it will hold no special right to make the community's work proprietary.

In place of that kind of agreement, Unstable Build is opening a new, optional contributor program that shares a cut of its own revenue with participants. Accepted contributions earn "contribution credits," and a still-undecided percentage of what the company calls "eligible service receipts" will fund a pool that is divided among contributors in proportion to the credits active during each period. The calculation is meant to run through a public, auditable ledger on GitHub covering receipts, permitted deductions, contribution awards, active credits and each allocation, so contributors can reproduce the numbers themselves rather than trust a figure produced behind closed doors. Joining is optional; contributing under plain GPLv3 and the Developer Certificate of Origin still works without it. The program will not make participants employees, equity holders or members of Unstable Build, and it will not transfer any additional software rights to the company. Sign-ups are open from the Rune account page, though Unstable Build says it is still finalizing the pool percentage, which services count toward it, how long a credit stays active, and the payment schedule.

Rune itself is a native, keyboard-driven IDE written primarily in Go, built as an alternative to editors written in Rust or C/C++ for speed, which the company argues are slow to write and compile, or built on JavaScript and TypeScript runtimes such as Electron, which it argues are hard to bend around performance-critical work. Its interface is a GPU-accelerated character grid that looks like a terminal multiplexer, though Rune is a standalone native graphical application rather than something that runs inside a terminal. A built-in console works as a durable REPL for installing packages, configuring models, and managing extensions and processes, while a single fuzzy-searchable command prompt handles editor operations, window management, language tooling and agent workflows together, with commands that can be typed, contributed by extensions, chained into aliases or bound to specific keys. The editor core itself stays small and exposes its functionality to extensions over an explicit gRPC API, so Rune can be extended in any language rather than only Go. Each running instance also joins a private, secure peer-to-peer development network, and a custom rune:// scheme lets a user open a workspace on any of their own development machines remotely, subject to NAT traversal.

A specific engineering story anchors the release: Rune's terminal, written in Go, was initially nearly two orders of magnitude slower than Alacritty, Ghostty and Kitty (written in Rust, Zig and C respectively) at raw pseudoterminal (PTY) throughput. Closing most of that gap took better algorithms, distributing work more evenly across goroutines, tuning goroutine wake-ups to cut Go-runtime overhead, and switching the renderer from the frames-per-second model inherited from its underlying game engine to an event-driven one that reduces latency, all without dropping into cgo or manual memory management. Unstable Build measured the result with vtebench, the Alacritty project's own terminal benchmark, comparing Alacritty, Ghostty, Kitty, Terminal.app, iTerm2, WezTerm and Rune across ten workloads on an Apple M4 Max laptop with 128 GB of RAM, then narrowing to just Alacritty, Ghostty and Rune on that same machine, and again across twelve workloads on a 2016 Apple MacBook now running Linux on a low-power Intel Core m3-6Y30 chip. On the full Apple-chip comparison, iTerm2 in particular ran one to two orders of magnitude slower than the rest on several scrolling workloads, which is why that chart uses a logarithmic time scale. Unstable Build is explicit that none of this is a language benchmark and does not show Go matching Rust or Zig in general; its claim is narrower, that profiling and engineering effort gave Go enough control to close most of that gap and make Rune's terminal competitive, though not necessarily fastest, on the specific workloads it tested.

Go and Python are Rune's first-class languages today, meaning full project discovery, tool provisioning, syntax and indexing, debugging and workflow integration, not just a connected language server; Rune exposes rust-analyzer operations beyond the standard Language Server Protocol through its own rust command and makes rustup available inside the console, but Rust and Zig support is still in beta and has to be built from the main branch rather than installed as a packaged release. The Python extension is itself written in Go on top of a public Go SDK, and an equivalent Python SDK is emerging, with a "Languages" developer guide walking through how that kind of integration is built. Unstable Build says it does not want to guess what a good Elixir, OCaml, Clojure, Java, C# or TypeScript environment should feel like, and is asking developers who use those languages to help design and lead that support themselves, starting from the source repository, its contribution guide and its open issues.

Key facts

  • Unstable Build put Rune's source on GitHub under the GPLv3 and says it will hold no special right to relicense contributors' work later, a policy it frames as an alternative to CLA-driven "reverse rug pulls."
  • A new, optional contributor program will pay out a still-undecided percentage of "eligible service receipts" as revenue share, tracked as contribution credits through a public, auditable ledger, without making anyone an employee, equity holder or company member.
  • Rune's Go-written terminal started out nearly two orders of magnitude slower than Alacritty (Rust), Ghostty (Zig) and Kitty (C) at pseudoterminal (PTY) throughput; algorithm and goroutine-scheduling work plus a shift to event-driven rendering closed most of that gap in vtebench tests on an Apple M4 Max and a 2016 MacBook.
  • Go and Python are Rune's first-class languages today; Rust and Zig support is still beta and only buildable from the main branch, and Unstable Build is recruiting maintainers to lead first-class support for languages such as Elixir, OCaml, Clojure, Java, C# or TypeScript.
  • Each Rune instance joins a private, secure peer-to-peer development network, with a custom rune:// scheme for opening a workspace on any of a user's own machines remotely, subject to NAT traversal.

Why it matters

Rune's announcement matters less for the IDE itself than for the licensing model attached to it. Unstable Build frames broad contributor license agreements, the kind that let a company relicense a project once it becomes valuable, as a "reverse rug pull" waiting to happen, and says such agreements can be legal without being what it wants for Rune: contributors keep copyright in their own work under the same GPLv3 terms as the rest of the code, and the company gets no special right to make that work proprietary later. The product underneath is also more architecturally settled than a typical early open-source release: Rune treats its terminal as a first-class part of the environment, adds a durable REPL-style console for installing packages and managing extensions, and unifies editor operations, window management and agent workflows behind one fuzzy-searchable command prompt, all rendered as a GPU-accelerated character grid rather than run inside a separate terminal window. Choosing Go for that native GUI, rather than Rust or C/C++ for raw speed or an Electron-style JavaScript stack for iteration speed, is also a bet the company says matters more given what it calls the advent of "automatic programming."

Who it affects

The people most affected are developers deciding what to build or contribute to next. Go and Python programmers already get full IDE support today; Rust and Zig users get a beta that still has to be compiled from the main branch rather than installed as a release. Unstable Build is explicitly recruiting maintainers to lead first-class support for other ecosystems, naming Elixir, OCaml, Clojure, Java, C# or TypeScript as languages it does not want to guess about on its own. Anyone who contributes code also has a new choice to make: keep contributing under plain GPLv3 and the Developer Certificate of Origin as before, or opt into the revenue-share program, which pays out through contribution credits without turning a contributor into an employee, equity holder or company member. More broadly, the move speaks to open-source maintainers and companies watching how a revenue-sharing alternative to restrictive CLAs plays out in practice.

How to use it

Rune's source is on GitHub under the GPLv3. Go and Python are supported as first-class languages out of the box, covering project discovery, tool provisioning, syntax and indexing, debugging and workflow integration rather than just a connected language server; Rust and Zig support exists but is in beta and only buildable from the main branch. Extensions talk to the small editor core over an explicit gRPC API, so the project offers a Go SDK, a Python extension written in Go, and an emerging Python SDK as starting points, alongside a "Languages" developer guide for adding a new one. To contribute, the entry points are the source repository, its contribution guide and its open issues; to also join the paid contributor program, sign-up happens from the Rune account page, though contributing under plain GPLv3 and the DCO needs no sign-up at all.

How solid is it

Every claim here comes from Unstable Build's own announcement, bylined "ernest" in the site's post metadata with no other individual named in the article text, and the performance numbers are self-published rather than independently reproduced. The terminal comparison uses vtebench, the Alacritty project's own benchmarking tool, run on two machines chosen to sit at opposite ends of the company's hardware: an Apple M4 Max with 128 GB of RAM, and a 2016 MacBook now running Linux on a low-power Intel Core m3-6Y30 chip, across ten and twelve workloads respectively. The box plots cover the middle 50% of runs with whiskers extended to 1.5 times the interquartile range, a disclosed charting convention rather than a hidden choice, and the Apple-chip comparison uses a logarithmic scale specifically because iTerm2 ran one to two orders of magnitude slower than the rest on several scrolling workloads. Unstable Build is also unusually explicit about the limits of its own numbers, stating directly that these are not language benchmarks and do not show Go performing like Rust or Zig in general, only that engineering effort closed most of an initial, nearly two-orders-of-magnitude gap and made Rune's terminal competitive, not fastest, on the specific workloads tested. The revenue-share program's economics cannot be checked at all yet, since the pool percentage and every other financial term remain undecided.

Risks and caveats

The contributor program's financial mechanics are not yet defined: Unstable Build says only that a defined percentage of "eligible service receipts" will fund the pool, without stating that percentage, which services count as eligible, how long a contribution credit stays active, or a payment schedule, and it gives no launch date for the program itself. The announcement also does not separate the timing of GPLv3 licensing from the timing of the payment program, presenting both as happening together. Because the performance results are self-published and limited to the vtebench workloads Unstable Build chose to run, they have not been independently reproduced. And because Rust and Zig support is still beta and unpackaged, developers in those ecosystems cannot yet get a ready-to-install build, only a main-branch source checkout.

“The company should not gain special rights from contributors while keeping all of the economic upside for itself.”

— Unstable Build