Zed: a 298-word README where licences and sponsorship take half the page

A 298-word README where licences and sponsorship take half the page

Zed is introduced as a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter, and then the file changes subject. Installation is one sentence pointing at a download page and three per-platform documentation anchors for package managers, followed by a note that other platforms are not yet available. Developing Zed is three links to build guides for macOS, Linux and Windows. Contributing is one link to CONTRIBUTING.md and a line saying the company is hiring.

Consequence: the file answers none of the questions an editor usually gets asked. There is no keybinding story, no extension model, no language server detail, no configuration reference, and nothing about multiplayer beyond the adjective in the first line. What you get instead is unusually complete on the two subjects a commercial project has to be careful about, licensing and money.

cargo-about fails the build in three named ways, each with a different file to edit

The licensing section states that licence information for third party dependencies must be correctly provided for CI to pass, and that cargo-about is used to comply with open source licences automatically. Three failures are then named one by one. A no license specified error on a crate you created is fixed by adding publish = false under [package] in that crate's Cargo.toml. A failed to satisfy license requirements error on a dependency is fixed by adding the licence's SPDX identifier to the accepted array in script/licenses/zed-licenses.toml, and the guidance there is to work out whether the system is sufficient and, if unsure, ask a lawyer. A dependency whose licence cargo-about cannot find at all is fixed by adding a clarification field at the end of the same toml file, following the cargo-about book.

Consequence: adding one dependency is a paperwork task with a legal step buried in it, and the person doing it may be a first-time contributor who has never opened a licence file.

The primary licence is GPL-3.0-or-later, and the Apache-2.0 carve-out is per component

Zed's source is licensed primarily under GPL-3.0-or-later, with Apache-2.0 components where marked, and the root carries two licence files, LICENSE-GPL and LICENSE-APACHE. A copyleft grant and a permissive exception are therefore both in play, and the README states the split without saying which parts fall on which side of it.

Consequence: mostly GPL with some Apache is not something you can act on without opening the files. A reader who needs to know whether one particular component is permissively licensed has to find the marking, and the README names no component at all. Anyone planning to ship Zed inside a product should expect that lookup per component rather than once.

Web is the one platform the file names as not yet available

macOS, Linux and Windows each get two routes: a direct download from zed.dev/download, or the local package manager, with a separate documentation anchor for each platform. Then comes the exception. Other platforms are not yet available, and the single entry is Web, which points at a tracking discussion rather than a build or a package.

Consequence: the README lists no web build. A tracking discussion is a place where progress is recorded, not a schedule, so the README offers no way to judge when that changes. The package manager routes also point at documentation rather than naming a package, so a scriptable install has to go and read the page first.

compose.yml starts an object store and a media server with credentials in the file

The tree carries a compose file with two services, and both are infrastructure rather than editor code:

  blob_store:
    image: quay.io/minio/minio
    ports:
      - 9000:9000
  livekit_server:
    image: docker.io/livekit/livekit-server
    ports:
      - 7880:7880
      - 7881:7881
      - 7882:7882/udp

Credentials sit in the same file as MINIO_ROOT_USER and MINIO_ROOT_PASSWORD placeholders, MinIO's data directory is bind-mounted from ./.blob_store, and the LiveKit configuration is bind-mounted from ./.config/livekit.yaml.

Consequence: this is a development stack, and it reads like a deployment template. Copied onto a shared host it puts an object store on port 9000 and a media server on 7880 with the placeholder values untouched. Nothing in the file marks it local-only.

One workspace, one crate per integration, and no list of them in the README

Cargo.toml declares a workspace with resolver 2 and an explicit member list, and the visible part of that list runs to about sixty-five crates. The names cluster by concern rather than by layer: acp_thread, acp_tools, agent, agent_servers, agent_settings, agent_skills and agent_ui sit together, anthropic, bedrock, codestral, deepseek and copilot each get their own crate, and edit_prediction appears in cli, context, metrics, types and ui variants.

Consequence: a reader looking for where a feature lives has dozens of plausible crates to open. The README mentions none of them, which leaves the tree itself as the only map.

Two tags on one afternoon, and the higher version is a pre-release

Three releases sit at the top of the tag list: v1.27.0-pre published at 15:18 on 2026-10-28, v1.26.2 published at 15:16 the same afternoon, and v1.25.3 on 2026-10-23. The last push to the repository is dated 2026-11-02 and the project is not archived.

Consequence: a pre-release and a stable cut land two minutes apart, so a script that takes the highest semver tag ends up on a -pre build rather than on the release it wanted. A team pinning versions by hand is fine. An automated installer is guessing.

Editorial conclusion

Read Zed's repository when you want to know how the project handles licence compliance or what the company says about funding it, because those are the two subjects the README genuinely covers. Do not expect it to answer how to configure the editor, because that lives under docs/ and the file's own links are three build guides and a contribution document. Two things to check before you build. CI fails on unresolved dependency licences and the fix is a hand-edited entry in script/licenses/zed-licenses.toml, which makes every new dependency a paperwork task with a legal question in it. And if you plan to run the collaboration stack from the compose file in the tree, read it first: it starts a MinIO object store and a LiveKit server on fixed ports with credentials written into the file.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes