How Fred Schott built two open source projects with 20,000+ GitHub stars
Astro co-creator Fred Schott shares the lessons behind multiple breakout open-source projects: move at the speed of early users, prototype before architecture hardens, dogfood seriously and build a community that can take real ownership.
Fred Schott co-created Astro, a server-first web framework for content sites, after years contributing to Node projects and leading Pika and Snowpack. Snowpack’s rise and eventual eclipse by Vite became a particularly useful source of lessons.
Fred explains Astro’s community-first governance and then turns practical: how to use licensed code well, why messy prototypes accelerate learning, how maintainers discover real priorities and why steady presence matters more than bursts of heroic effort.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
What is Astro trying to change about web development?
The previous decade treated full-stack JavaScript and single-page applications as the default even for content sites. Astro renders server-first HTML, then adds React, Vue, Svelte, Solid or another framework only where interaction needs it. That returns to a simpler web architecture without abandoning modern component tooling, reducing shipped JavaScript while keeping a productive developer experience.
How is the Astro company separated from the project?
The open-source community is Astro; the company exists to support it and does not own it. Employment does not automatically grant authority over governance. A volunteer who earns a core maintainer role can hold more project privilege than a new company employee. The separation is intended to keep commercial sustainability from converting community participation into a company-controlled funnel.
What did Snowpack teach you about open-source community?
I wanted to build software and underestimated that excited users were also the project. Discord created a place that felt social and expressive rather than another workplace inbox, making questions, memes and responsibility part of the same community. The broader lesson was not merely to choose Discord over Slack; it was to treat human connection as part of how an open-source tool grows.
What superpower does a project have with its first users?
A solo maintainer can hear one person’s request, fix the bug that day and learn what the product should become without organizational delay. That speed would look dangerous in a mature project, but it reassures someone taking a chance on an early one. The tight loop turns feedback into both product direction and proof that the new community member matters.
Is it acceptable to build on another project’s source code?
Astro’s first compiler forked Svelte because that made an experimental component language feasible. Reuse is central to open source, provided you follow the license and preserve attribution instead of claiming the code as your own. Bringing the MIT notice and credit is a tiny obligation in exchange for being able to remix strong foundations and take them somewhere new.
Why deliberately tolerate messy early code?
Before people use a project, you do not know which assumptions will survive. A beautiful abstraction creates sunk effort and rigidity around a product that may change next week. A working, hacky prototype lets you see the idea, enjoy building it and collect evidence. Refactor after the use case becomes clearer, when architecture can encode knowledge rather than speculation.
Why was dogfooding decisive in the Snowpack and Vite outcome?
I maintained Snowpack full-time without a serious application exercising its full surface, so committed users repeatedly found another bug after each fix. Evan You built VitePress on Vite and created a demanding, self-sustaining test case. Maintainers who cannot use their tool at work should partner closely with a real user, test changes on that repository or invent a substantial application that forces the hidden problems to appear.
How does direct use change roadmap priorities?
Dogfooding exposes both sharp failures and the thousand small cuts that silently make unfamiliar users leave. Snowpack chased an exciting CDN direction while its everyday experience remained difficult because I was maintaining rather than using it. Astro later added a public roadmap and community voting, but even lightweight polls and one-to-one conversations can reveal where maintainer enthusiasm has diverged from user pain.
How much community infrastructure should an early project create?
Match it to the community that actually exists. One general channel may serve thousands of stars until traffic creates a specific problem. Add support channels, roles, automation or governance when pressure makes their purpose obvious, not because a large project has them. Visible gaps can also invite contributors to step into real responsibility; solving everything yourself can suffocate people who want to help.
Why does consistency matter more than bursts of effort?
For a durable project, one day of work every week is more valuable than an exhausting sprint followed by a month of silence. Contributors need to believe their issue or pull request will be seen while they still care. Absence creates a feeling of abandonment that spreads through a community, whereas a modest, predictable presence builds trust and makes long-term participation possible without requiring constant heroics.