Building and Operating with Open Source: Lessons from AFFiNE with Yifeng - AFFiNE x Supabase

AFFiNE built an offline-first, open-source knowledge base and editor by treating early prototypes as learning tools, then tightening engineering discipline until the project could ship stable, production-ready releases—while keeping community momentum and data ownership at the center. The product experience blends document editing with whiteboard-style work: users start in familiar “note” editing, then switch into a whiteboard view where content is automatically reorganized. Under the hood, collaborative content is enabled by default, but users retain ownership of their data, and the system is designed so networking is optional rather than mandatory.

The origin story traces a sharp pivot from an unstable early prototype to a staged rewrite. The first AFFiNE prototype began as a web page with multiple modes (including “paper mode” and address-node style views) and delivered features that were novel enough to gain traction quickly—reportedly reaching 10K GitHub stars within 40 days and topping GitHub trending without paid promotion. Yet the early architecture couldn’t converge into a stable state: fixing one bug tended to introduce others, making long-term reliability difficult. That instability became the reason for a rewrite, and the team brought in new full-time focus to rebuild toward production readiness.

The rewrite followed a step-by-step release strategy aimed at shipping usable subsets at every milestone. Early major releases focused on a “pure markdown editor” with minimal UI widgets—enough to function reliably—while the team enforced “dogfooding,” using the product internally to surface real-world issues. Only after the core editor stabilized did the project expand into richer interfaces, including draggable UI widgets and progressively more complex content types. Later stages added structured capabilities such as table views that can behave like multi-dimensional spreadsheets, along with a more polished whiteboard experience. The overall goal was to reach “progressive richness” without sacrificing stability.

As the product matured, engineering management shifted toward modular ownership: each team member took responsibility for core subsystems and actively worked to reduce quality issues. Scaling the work required more than feature delivery; it demanded stronger system design in the editor and collaboration layers. That’s where open source became both a recruiting and a quality engine. Community contributors volunteered because they liked the ideas, and the project built sponsored relationships with core contributors. Traction also helped attract additional talent.

Operationally, AFFiNE centralized development on GitHub as a “single source of truth,” using public issue workflows such as “help wanted” to invite outsiders—especially beginners—into meaningful tasks. The team also tracked backlog health using ratios of opened versus closed issues, aiming to lower backlog entropy and improve maintenance.

On the business side, AFFiNE frames open source as a mutual benefit for commercialization: GitHub exposure lowers trial barriers via a try-demo web option and a Docker image for local deployment. The company also positions its ecosystem strategy as more open than closed competitors, with plans for plugins and integrations. Finally, AFFiNE open-sourced general-purpose collaboration infrastructure—Block Suite for editor and front-end collaboration, and an additional backend structure (AutoBase)—with the intent to reduce reinvention for future collaborative applications, even if those infrastructure projects weren’t yet ready for broad public reuse while AFFiNE itself remained the priority.