METAL

Unstable Build open-sources its Rune IDE under the GPLv3

Developer-tools company Unstable Build released the full source of its Rune IDE under the GPLv3 on September 12. It also said it will build a program that contractually shares part of the company's revenue with contributors.

Unstable Build open-sources its Rune IDE under the GPLv3

Image: METAL

Summary

  • Unstable Build open-sourced the Rune IDE under the GPLv3 on September 12 and put the code on GitHub.
  • Rewritten in Go, Rune's terminal started out nearly two orders of magnitude slower than Alacritty, Ghostty and Kitty, and closed the gap without dropping into cgo.
  • The company announced a credit-based revenue-sharing program for contributors, but the pool percentage and payment schedule are still being settled.

Developer-tools company Unstable Build has opened the entire source code of its Rune IDE. A post published on the company blog on September 12 said Rune is now open source under the GPLv3 and that the code is available on GitHub. In the same post the company said it will also create a program that shares part of its revenue with contributors. Plenty of companies open their code; very few write down a promise to split the money it earns.

Rune is not a program that runs inside your terminal. It is a native GUI application built around a character grid, GPU-accelerated, and written from scratch in a single language, Go. The post argues that most modern IDEs sit on top of large stacks that are hard to understand, compile, profile or change unless you already know your way around a systems-language or browser-runtime codebase. Either the barrier between having an idea and changing your working environment is high, or the thing is simply slow.

The price of that choice is on the record as a number. According to the post, Rune's terminal, written in Go, was initially nearly two orders of magnitude slower at pseudoterminal throughput than Alacritty, Ghostty and Kitty. Those three are written in Rust, Zig and C respectively. The company says it closed the gap without dropping into a manual-memory-management language through cgo.

There were four moves. Better algorithms, a better distribution of work across goroutines, balancing goroutine wake-ups to cut Go runtime overhead, and switching from the frames-per-second model inherited from the game engine used for rendering to an event-driven one. To an engineer the last item is the big one: instead of redrawing the screen on a fixed cadence, the program moves only when input arrives, which is where the latency went.

The measurements come from vtebench, built by the Alacritty side. The company ran the same tests on the fastest laptop it could get hold of, an Apple M4 Max MacBook with 128GB of RAM, and on the slowest machine it still develops on, a 2016 MacBook running Linux on a low-power mobile Intel Core m3-6Y30. The first chart includes iTerm2, which on several scrolling workloads is one to two orders of magnitude slower than the rest, so a logarithmic scale was needed to fit every terminal into one picture.

The company draws its own line in the same place. The post says, "These are not language benchmarks, and they do not show that Go is as fast as Rust or Zig." What it claims instead is that profiling and careful engineering closed a nearly hundredfold gap and made the terminal competitive on these workloads, without giving up the simplicity and iteration speed that made Go the choice in the first place.

The post also answers why now. The company says it had wanted to open the code for a long time but waited for the right stage. Early on, a small team can move through foundational design questions at a density that is hard to reproduce in public, and an IDE has such a large surface area that a single early implementation choice can accidentally become an API, a compatibility promise or an architectural constraint. "We did not want to open source it while we were still soul-searching," the post says.

The company lists six things that now give Rune its center of gravity. The terminal is a first-class part of the environment, and the console is a durable REPL that handles package installs, model configuration, extension and process management, and driving the debugger. A single command prompt covers editor operations, window management, language tooling and agent workflows on one fuzzy-searchable surface, and commands can be typed, contributed by extensions, chained into aliases or bound to keys. The editor core stays small and extensions talk to it over an explicit gRPC API, so extensions can be written in languages other than Go.

The sixth is the network. Each Rune instance becomes a node in a private development P2P network, and a new rune:// scheme lets you open a workspace on any of your development machines from anywhere. The caveat printed alongside it is that this holds as far as NAT traversal allows.

The contributor section is the strangest part of the announcement. The company calls what has happened in parts of the open-source world in recent years appalling: companies that grew a project in the open, took the help of users and contributors, then changed the license once the project became valuable. It also points at broad contributor license agreements, which make that easier by asking contributors to hand over copyright or by granting relicensing rights to the company alone.

Rune says it is going the other way. The GPLv3 stays, contributors keep copyright in their own work, and they contribute under the same terms as the rest of the code. Unstable Build will not hold a special right to take the community's work proprietary later, the post states flatly. On top of that sits a promise to give contributors a contractual right to share in the revenue Rune generates.

The mechanism is credits. Accepted work earns contribution credits, a defined percentage of eligible service receipts funds a contributor pool, and each allocation is divided in proportion to the credits active in that period. The calculation is to live in an openly auditable ledger covering receipts, permitted deductions, contribution awards, active credits, the total denominator and each allocation. The design is meant to let contributors reproduce the number themselves rather than trust one produced behind closed doors.

The company also wrote down what is missing. The pool percentage, which services are covered, how long credits stay active and when payments happen are all still being settled. Participation is optional, anyone can still contribute through the normal GPLv3 and DCO process without joining, and joining does not make a contributor an employee, an equity holder or a member of the company. Only the principle is settled, the post says: "the company should not gain special rights from contributors while keeping all of the economic upside for itself."

The to-do list is about languages. Go and Python are supported as first-class languages today; Rust and Zig are in beta and have to be built from source on main. The company points to reaching rust-analyzer operations beyond standard LSP methods through a rust command, and to managing toolchains with rustup from the console without leaving the environment, as its example of what first-class means. The Python extension, it notes, is itself written in Go.

The full post METAL read is marked as a 13-minute read and carries the byline ernestrc. METAL has reported that OpenAI's Codex CLI is an open-source coding agent that runs in the terminal; Rune, instead of parking an agent next to the terminal, pulls agent workflows into the editor's own command surface. That is why the post says the arrival of automatic programming makes this matter more than ever.

Ownership structures around open-source projects have been shifting all year. METAL has reported that DuckLabs joined AWS on terms that preserve the governance of open-source DuckDB. Opening the code and splitting the money that code earns are two different problems, and Rune is the side that said first it would put a contract behind the second one.

What remains to be checked is the numbers. Until the pool percentage and the payment schedule are written down, the size of this promise is unknown, and the recalculation only becomes possible once the ledger actually opens. The code is open; the books are not yet.

Comments