Frequently Asked Questions

At the moment, it is not possible to contribute code to Zed or GPUI, but this won't always be the case. See "will Zed be open source?".

If you'd like to help out, there are a few ways to get involved today. You can:

• help to improve our documentation: docs repository
• add a keymap or fix issues with an existing one: keymap repository
• share a tip or answer a question: forum
• help with issue maintenance (identifying duplicates, providing answers, etc.): issue tracker

You can obtain the release build via the download page.

We're focusing on a single platform for now because we're a small team. At our current scale, maintaining additional platforms would represent a big cost without much additional learning. We plan to support Linux and Windows before 1.0, and to support a web version some time after that.

Any news will be posted to our platform-tracking issues.

While we are committed to building a stable, professional-grade editor, you'll likely run into bugs and pain points throughout the beta phase. Additionally, Zed may not support all languages you use and may not be available for your preferred operating system. What we can confidently say is that we are working hard to bring you the features, support, and stability you need to make Zed your homebase editor for building great software.

As diligent as we try to be with every line of code we write, human error is inevitable, especially during periods of rapid development. Make sure to properly backup any code you are working on in Zed to protect yourself from potential catastrophic events. While we believe Zed to be safe to use, it is always advisable to err on the side of caution in these early stages.

We are currently a small team, so it's critical for us to be laser-focused. As a startup, one of our key priorities at this early phase is learning, and right now, we're focused on the following questions:

• What are the key features we need to get traction on any platform?
• Are our assumptions about our eventual business model valid?

While we'd obviously love to support users on Linux and Windows, adding those platforms doesn't really help us answer those questions. We're investing a lot to make Zed portable, but adding other platforms comes with opportunity cost in the short-term and maintenance overhead going forward. Right now those costs don't make sense for us.

As Zed matures on a single platform, this cost/benefit ratio will shift, and it will make sense to expand to other platforms. We hope you'll give it a try when that happens.

Language servers are stored at ~/Library/Application Support/Zed/languages. See language servers for more information.

The settings.json can be found at ~/.config/zed/settings.json. See configuring Zed for more information. The keymap.json can be found at ~/.config/zed/keymap.json. See key bindings for more information.

The last 1000 lines of Zed's log file can be opened in a Zed buffer by searching for zed: open log within the command palette. If you need to view more history, you can find the full log file at ~/Library/Logs/Zed/Zed.log.

We stopped working on Atom and started on the foundations of Zed when we realized that we couldn't shape Atom into our vision for the ultimate editor. While we respect and appreciate the innovations brought by Visual Studio Code, we never found ourselves loving it enough to give up on the dream. Ultimately, we think we're going to add the most value to the world by creating something new. It's also a lot more fun.

As the last letter of the alphabet, Zed symbolizes the ultimate in our pursuit of building the perfect editor. This is the tool we've always envisioned using, and we believe it to be the last one we will build.

We plan to make Zed extensible via WebAssembly, but we're taking a different approach than we did with Atom. Our goal is to make Zed fast, stable, and collaborative first, extensible second. We'll be taking a more conservative approach with our APIs to ensure we can preserve our core values even as users add extensions.

Yes. Zed will be free to use as a standalone editor. We will instead charge a subscription for optional features targeting teams and collaboration.

We know that users enjoy contributing to projects like Zed. We also understand that being able to audit the codebase of a critical tool helps to establish trust in both the tool and its creators.

We'd like to be as open as possible while maintaining the ability to run a profitable business (see "how will you make money?"). This probably means some kind of "open core" model, where the editor is available under the GPL but other parts of our system remain proprietary. We also intend to open source our Rust-based graphics library, GPUI.

The exact timing of when these pieces will be open to the public isn't clear to us at this point. We need to develop plans for both untangling the code and for how we will handle pull requests from the commumnity; we will share updates as they emerge.

This isn't something we're worrying too much about right now, but we anticipate adding enterprise-focused features eventually.

When we started on Zed the Rust UI framework space was much younger. In absence of a mature solution that met our exact needs, the simplest path for us was to build it ourselves. We're too far into things now to change at this point. We also like our framework. It's working well for us.

Yes. All interactions between collaborators are proxied through our servers. This ensures much greater reliability than peer to peer connections. It also allows us to store a small amount of server-side state about each shared project, which makes it faster for new collaborators to join the project.

user identification - When you're not signed in, we don't send anything to our servers. When you do sign in, we establish a WebSocket connection to one of our servers that's associated with your Zed account, but we don't send any other data.

project metadata - When you're in a call and you share one of your projects, we send to our servers the name of that project, and the relative paths of all of the files in that project. We also send the names of any language servers that are running for that project, and their status messages. Note that we only store the relative file paths and the language server statuses of the shared project on our server; all other data stays on the host and is proxied through our servers when requested by a guest.

file contents - When you're sharing a project in a call, your collaborators can open any file in your project, as well as files that are returned by your language servers from requests like 'go to definition' and 'find all references'. When they do open these files, we send them to our servers, which forward them to the collaborator. File contents are never stored on our servers.

Zed collects and sends its own crash reports to our server so that we can quickly get a pulse on what users are experiencing and begin implementing fixes to these issues. We also collect user telemetry to help us understand how Zed is being used. The collectiong of crash reports and user telemetry can be be disabled via the settings. See Telemetry in Zed.

Our EULA can be found here.

Check our jobs listings.

We plan to monetize optional network-based services integrated into the editor. The editor itself will be free to use.

Yes. We sold equity in our company to investors to enable ourselves to give Zed the focus it deserves.