An Unlikely Open Source Journey
When I started Zeon, I didn't set out to build an open-source project. I set out to solve a problem: customer support was broken, and AI could fix it. But somewhere along the way, the decision to make Zeon open-source transformed not just the project, but how I think about design.
This is the story of that journey, and what I learned about designing for a community rather than just users.
Why Open Source?
The decision to make Zeon open-source wasn't purely idealistic. There were strategic reasons too:
Building Trust for AI Products
AI is a trust-sensitive space. Businesses are wary about where their customer data goes, how it's processed, what happens behind the scenes. Open-source addresses these concerns directly -anyone can audit the code.
For Zeon, which handles customer conversations, this transparency was essential. Open-source became a trust signal.
Community as a Feature
Open-source projects have something proprietary products can't easily replicate: a community that contributes, improves, and evangelizes. Every bug report is a quality improvement. Every feature request is user research. Every contribution is free development.
The Distribution Advantage
Open-source projects spread organically. Developers discover them on GitHub, try them out, and recommend them. This distribution channel costs nothing but creates exponential reach.
Designing for Community
Here's what surprised me most: designing for open-source is fundamentally different from designing for traditional products.
Your "Users" Are Also Builders
In open-source, the people using your product might also want to modify it, extend it, or contribute to it. This changes everything about how you design.
For Zeon, I had to think about:
- How easy is it to customize the interface?
- Can developers extend functionality without forking?
- Is the codebase understandable to new contributors?
- Are design decisions documented and rational?
The design system became not just a UI guide, but a contribution guide.
Defaults Matter Even More
Open-source users have power. If they don't like something, they can change it. This might seem like it reduces the importance of defaults -after all, people can customize whatever they want.
Actually, the opposite is true. Most people won't customize. They'll use defaults. And in open-source, your defaults shape how thousands of deployments look and feel. Bad defaults spread.
I obsessed over Zeon's defaults. Every default color, every default behavior, every default message -these would represent the product in the wild.
Documentation as Design
In traditional products, good design reduces the need for documentation. Self-evident interfaces guide users. But in open-source, documentation is part of the design.
Contributors need to understand not just what the interface does, but why it does it that way. Design documentation -explaining the rationale behind decisions -becomes as important as the decisions themselves.
I started writing design documentation for Zeon with the assumption that someone might need to modify any component. That meant explaining:
- The problem this design solves
- The alternatives we considered
- Why we chose this approach
- When it's appropriate to deviate
Balancing Idealism and Practicality
Open-source sounds romantic until you're maintaining it. The reality involves difficult trade-offs.
Saying Yes Is Expensive
Every feature request you accept becomes your responsibility. In open-source, where contributions come from many sources, this creates complexity. Different contributors have different coding styles, different assumptions, different levels of polish.
I learned to say no kindly but firmly. "Great idea, but it doesn't fit our current scope" became a frequent response. The project's integrity depended on it.
Designing for Multiple Use Cases
Zeon serves many different types of businesses: startups wanting quick setup, enterprises needing customization, developers wanting to build on top of it. Each has different needs.
The design had to be:
- Simple enough for quick wins - New users should see value immediately
- Configurable enough for customization - Power users should be able to adapt it
- Extensible enough for developers - Builders should be able to extend it
This is the tension every open-source project navigates.
Time Is a Finite Resource
Maintaining an open-source project is a job. Responding to issues, reviewing PRs, updating documentation, planning roadmaps -it adds up quickly.
As a designer founding a project, I had to accept that some design work would be "good enough" rather than perfect. Shipping something useful beat polishing endlessly.
What I'd Do Differently
Looking back, a few things I'd change:
Document Design Decisions Earlier
I started documenting design rationale too late. By the time I got around to it, I'd forgotten why I made certain decisions. Now, I document decisions as I make them.
Create Contribution Guidelines for Design
Code contributions have clear processes: fork, branch, PR, review, merge. Design contributions are messier. I should have created clearer processes for how design suggestions get evaluated and implemented.
Build More Visual Examples
Open-source projects live on GitHub, which is text-heavy. Design gets lost. I should have created more visual documentation -screenshots, videos, interactive examples -that show the product's design quality.
Set Clearer Scope Boundaries
Early on, I accepted feature requests too readily. The project scope crept. Setting clearer boundaries earlier would have kept things more focused.
The Unexpected Benefits
Despite challenges, building Zeon has been transformative:
Designing in Public Forces Rigor
When your design decisions are visible to anyone, you think harder about them. Open-source eliminated my tendency to take shortcuts. Everything had to be defensible.
Community Feedback Is Unmatched
The feedback I've received from the Zeon community is higher quality than any user research I've conducted in proprietary products. People who use open-source tools are technically sophisticated and articulate about their needs.
Personal Growth Through Vulnerability
Putting work into the world -knowing anyone can critique it -is vulnerable. It's also incredibly growth-inducing. I've improved faster as a designer through open-source than through any other method.
Building a Network
The connections I've made through Zeon are invaluable. Other open-source maintainers, developers who use the tool, designers who share the approach -this network emerged organically from building in public.
Should You Build Open Source?
If you're a designer considering an open-source project, here's my honest advice:
Do it if:
- You have a genuine problem you want to solve
- You're prepared to maintain it long-term
- You value community and collaboration
- You can accept that it will never be "finished"
Don't do it if:
- You want quick results
- You're doing it for resume padding
- You can't handle public criticism
- You're not prepared to support users
Open-source isn't for everyone. It's a commitment. But for those who embrace it, there's nothing quite like watching something you built help people around the world.
The Ongoing Journey
Zeon continues to evolve. The AI customer support space moves quickly, and keeping up requires constant attention. But every time I see someone deploy it, every time a contributor improves it, every time a user thanks us -it reminds me why open-source matters.
Building in public as a designer was uncomfortable at first. Now I can't imagine building any other way. The accountability, the community, the growth -they've become essential to how I work.
If you're on the fence about open-source, consider starting small. Contribute to existing projects. Document your design decisions publicly. Get comfortable with transparency. See if it resonates.
You might find, like I did, that it changes how you think about design entirely.
Have you contributed to or built open-source projects? I'd love to hear about your experience.