Advice for going open source
Planning to open source Voiden (https://voiden.md/) soon.
This isn’t a “maybe someday” idea anymore, it’s a deliberate step we want to take in the coming weeks.
We started Voiden as a tool we wanted for ourselves: a minimal, offline-first API client that works with plain text, no accounts, no cloud sync, no SaaS gravity. Just something that respects how developers already work.
Open sourcing feels like the right next move, but I’ll be honest: it also raises a lot of questions for us.
We have talked to many devs who strongly believe tools like this should be open. At the same time, we are thinking carefully about:
how to structure the repo and contributions
how to balance direction vs community input
what we wish we had known before flipping the switch
etc etc.
So I wanted to open this up and ask directly:
If you have open sourced a project (especially a dev tool):
What do you wish you had done differently at the start?
What mistakes are common but avoidable?
Anything you underestimated, emotionally, technically, or community-wise?
Any advice you’d give before making it public?
I want to stay committed to doing this thoughtfully, not performativel, so learning from people who have been through it already would help a lot.
Appreciate any hard-earned lessons you are willing to share 🙏
Replies
@nikolas_dimitroulakis You’re asking the right questions at the right time. From patterns I’ve seen across successful open-source dev tools, a few hard-earned lessons keep repeating:
1. Be opinionated from day one
The biggest early mistake is trying to please everyone. Healthy projects stay clear about:
what problems they will solve
what’s explicitly out of scope
Open source doesn’t mean community-driven roadmap by default. Direction still needs an owner.
2. Set contribution boundaries early
Have a clear CONTRIBUTING.md and governance note. Not because you’ll get tons of PRs, but because you’ll get:
feature requests
“why not X?” debates
Clarity saves emotional energy later.
3. Maintenance is the real cost
Most people underestimate the ongoing load:
issues > PRs
support > code
context switching > building
Plan for sustainability, not just launch excitement.
4. License choice matters more than you think
Changing it later is painful. Pick one that aligns with your long-term intent (community growth vs protection vs commercial flexibility).
5. Expect feedback to feel personal at first
This is underrated. People will critique something you built for yourself. That sting fades, but only if boundaries are clear.
Practical tip before launch:
Clone the repo fresh, follow the README, try to make a tiny change. Anything confusing there will be magnified once it’s public.
Given Voiden’s philosophy (offline, minimal, no SaaS gravity), open sourcing makes sense — just remember:
open source works best with clarity, not consensus.
ApyHub : The All in one API Platform
@alpertayfurr thanks a lot!