Zed is open source, and that has always meant more to us than a license. Our codebase runs to well over a million lines of Rust, and it moves quickly, shaped every week by people who don't work for us but show up as if they did. We're a small team, and we've never believed that the best version of Zed is something we could build on our own. The best editor for developers gets built alongside the developers who use it.
The Guild is one of the ways we put that belief into practice. It's a 12-week program that brings a focused group of contributors inside our process to triage issues, fix bugs, and ship features next to our team. Members commit five to ten hours a week, pair directly with Zed engineers, and work on real parts of the product.
We ran the first cohort this spring. Hundreds of developers applied, and we invited about a quarter of them to join. By the end, 33 active contributors had merged 148 pull requests. And we are thrilled to announce the Zed Guild Cohort 1 grand prize winner: feitreim. Finn showed up every week, took feedback seriously, and kept shipping. 23 merged PRs later, fixing screen flickering in Vim mode, improving fuzzy path matching, and landing 256-color ANSI rendering in the terminal, he earned the grand prize: a trip to Rust Week in Utrecht to spend time with the Zed team in person. We couldn't be more grateful.
At this point, some of you may be asking, "How exactly did the Guild work?"
How it worked
We designed the Guild around a simple idea: meet contributors where they are, and build from there.
With that in mind, we built three tracks into the program:
Repro Specialist is where new contributors start, and it's designed to help them get to know the product and the codebase from the inside. Repro Specialists triaged, verified, and reproduced issues across setups so the team could see clearly what was broken and prioritize what to fix.
Bug Basher is where contributors begin writing code. They pulled from a curated board of issues in stable parts of the codebase, the kind without heavy dependencies or design complexity, which let them ship real fixes without first having to hold the whole system in their head. The board ranged from issues a beginner could take on to ones that demanded expert-level Rust.
Feature Shipper was the most advanced track this time around. Everyone on it was a contributor we already knew, whose work had earned our trust over time. They took on some of the most requested features in Zed, each paired one on one with a dedicated engineer to get the work over the line.
To support the work, we built some structure around it. We stood up a private Slack channel for day-to-day questions and hosted office hours to review PRs. We paired people with engineers who knew the parts of the codebase they were working in, and we kept a clear path to move up across tracks as their skills and confidence grew.
Who showed up
- feitreim: 23 PRs merged — fixed screen flickering in Vim mode, improved fuzzy path matching, fixed 256 color ANSI rendering in the terminal
- lingyaochu: 13 PRs merged — went deep on semantic token highlighting
- MostlyKIGuess: 10 PRs merged — shipped pinch gestures across all devices
- OmChillure: 28 PRs merged — fixed agent panel UI issues across Linux and Windows
- Dnreikronos: 27 PRs merged — fixed multiple agent panel and extension bugs
- iam-liam: 5 PRs merged — fixed a GPUI scrollbar bug
- dongdong867: 5 PRs merged — fixed Git panel empty state labels
- prertik: 5 PRs merged — improved project panel reveal and format-on-save LSP support
- AmaanBilwar: 5 PRs merged — fixed Windows shell environment errors
- nihalxkumar: 4 PRs merged — fixed true-color rendering in the terminal
- seanstrom: 2 PRs merged — added Vim regex mode default setting
And a huge thank you to the rest of the Guild members whose code shipped into Zed: mufeedali, loadingalias, ishaksebsib, transitoryangel, virajbhartiya, polyesterswing, notJoon, criticic, th0jensen, YEDASAVG, alanpjohn, 11happy, TwistingTwists, SkandaBhat, austincummings, Steven-Weng, HiteshRohira, sarmadgulzar, emamulandalib, ayushk-1801, mchisolm0, and prayanshchh.
Most of them did this around full-time jobs, coursework, and lives that were already full. They had no obligation to spend that time on Zed, and they spent it anyway. We don't take that lightly, and we're grateful for every contribution that came out of it.
They also taught us a lot.
What we know now
Go deep, not wide
It's tempting to scale a program like this, especially with AI in the mix, but you can't build real relationships at scale. In hindsight that feels obvious, and yet running the cohort is what taught us: the quality of the work tracks closely with the depth of the connection between a contributor and the team. Investing in that connection means keeping the cohort small. With fewer people, you can actually learn each contributor's strengths, the kind of work they want to do, and why they showed up in the first place. That understanding is what lets you point them at the right problems and support them well, which is where the good work comes from.
Control quality without becoming a bottleneck
For most of the cohort, contributors had to wait for us to assign them an issue. We'd look at what someone had shipped, validate whether it matched their skill level, and make a call. We thought we were being careful, and to some extent, we needed that oversight to keep quality high. But we were also the bottleneck, and everyone felt the pain early. Even worse, the problem compounded over time. For Cohort 2, work will be organized differently. Rather than contributors spreading across a wide surface area, we want to build tighter groups around specific parts of the codebase, where contributors and Zed engineers can work more collaboratively.
Invest in coming together as a group
The original goal was to invest in relationships with a select group of contributors. This meant creating spaces where the Zed team and Guild members could come together to share work, ask questions, and build something as a group. What came naturally were the one-on-one relationships built through PR reviews and pairing sessions. But we didn't nail coming together as a group. In Cohort 2, we're building more shared rituals into the program, like demo days, code reviews, and office hours, so progress feels like something the group is doing together and not a race.
What's next
The Guild is a contributor journey. Repro Specialist is where you start, getting to know the codebase, understanding the product, and working closely with our team. From there, contributors move into Bug Basher and Feature Shipper as their skills grow.
The code contributing tracks will be much smaller and more selective. We're going deeper with fewer people, building around specific areas of the product, and investing in the relationships that make the work better.
Cohort 1 showed us what's possible when the right people show up for a product they love. We can't wait to see what we build together next.
Interested in Cohort 2? Keep an eye out in our /community page.
Related Posts
Check out similar blogs from the Zed team.
Looking for a better editor?
You can try Zed today on macOS, Windows, or Linux. Download now!
We are hiring!
If you're passionate about the topics we cover on our blog, please consider joining our team to help us ship the future of software development.