Hey :) Voiden is not a rich text editor (non offense to rich text editors). It is executable API docs: requests, docs, and explanations that all live in Markdown… and actually run. (Yes, your docs that do stuff). As far as I know it is the first tool to collapse design, testing, and documentation into one file, one format, one workflow. If you know another tool that does this, I genuinely want to hear about it (definitely not trying to be cocky, just curious :)
Yaak has some ideas and concepts that I like a lot. One thing that is similar with Voiden is that they are extensible through plugins. This way the core can stay lean and new functionality can be added up without bloating the app.
hey - thats great :) Happy you downloaded it :) curious to hear your feedback - I will send you a discord link as a message so its not seen as spamming.
Let me see if I understand your question: you mean how Voiden would look when its more mature?
What I am most excited about is that Voiden already does a few things differently from most API tools. Reusable blocks, plain-text everything, and the ability to go from testing to docs to publishing from a single source are already working and shaping how teams can work in a more consistent way.
There is still a lot ahead (for example I want to see what kind of plugins people come up with for the tool, or how AI will eventually play a bigger role) but the principles of Voiden (reusability, composability, plain text, collaboration through git, single source of truth etc.) are the ideas I believe will define and set a new tone/standard of how API tools should be.
I thought no one would ask :) just open sourced it a few weeks ago. But I promise I will never pay someone to praise it pretending to be a developer.
haha I dont know how to take this
yeah, do agree with part of it. Without HashiCorp Terraform, we probably wouldn’t have OpenTofu at least not in the form it exists today. In that sense, VC money did indeed help bootstrap something that eventually became broader open infrastructure.
You could argue the same happened with Elasticsearch leading to OpenSearch, or Redis eventually leading to Valkey.
So yes, venture funding can indeed accelerate the creation of useful open ecosystems.
The tension I am pointing to is more about the transition phase. When a project grows under the assumption of being open community infrastructure and then the business incentives shift later, it tends to create friction: license changes, forks, community distrust, etc.
Forks are actually a feature of open source: they are like the ecosystem’s pressure valve. (But they also show that the incentives between companies and communities drifted apart at some point.)
So I would frame it less as “VC-funded open source is bad” and more as: “VC-backed projects often bootstrap great ecosystems, but the sustainability model tends to get figured out later, and that’s where things get messy.”
In some cases we end up with something great like OpenTofu. In others we end up with fragmentation and uncertainty. Both can happen.
haha indeed - modern has this “blinking lights” connotation. something that is shiny.
True story - once, in primary school, I went to a halloween party, where all the boys were dressed as batman and all the girls as macarena (guess my age). The host of the party was maybe the only one not dressed as batman.
He was wearing some weird jell in the hair, like a punk kind of thing, with a lot of strass, stars all over his body, some heart or thunder shaped big mirror glasses, a shiny jacket and the best looking blue mocasines I have ever seen. He also had a big radio antenna (??) coming through his nylon electric yellow vest.
I asked him: what are you dressed as? and he replied: “Modern”.
true as well
true :) I heard this actually even from ex insomnia folks - the direction could have been much different.
yes, sorry for the confusion - yes I mean API Client tool - postman, insomnia etc. etc.
this is the “joke”. that every API client calls themseleves modern without this essentially meaning much.
and certainly not, I dont mean Postman. But this is the easy answer. What I also mean is that many of the tools that came as a response to Postman being “old fashioned” are basically mimicking the same things or principles with a few things here and there.
so everything is like “postman but with a better XYZ feature” or “Postman but open source”…
what about people that are not JS?
You either die a hero or live long enough to become the villain?
Apologies…missed that. Yeah this is what we are currently working on - part of the next release actually :)
I actually agree with most of your premise.
Voiden is not coming from “people are too scared of the terminal, let’s save them with buttons.” It comes from almost the opposite direction. A lot of us are terminal people too. The problem is not that curl, hurl, scripts, OpenAPI, or plain code are bad. The problem is that API work tends to get fragmented across too many places once it becomes real.
You have raw requests in one place, auth logic in another, docs somewhere else, examples in Slack, test cases somewhere else again, and then different teams consuming different versions of what is supposedly the same API. That’s the mess we care about.
So the goal with Voiden is not to replace power-user workflows but to give them a better structure, while also making that same source of truth usable by the rest of the team, including people who are not living in the terminal all day, or simply have different preferences.
That is also why composability matters so much to us. Reusable headers, auth, query params, payload fragments, shared blocks, documentation alongside execution , not because curl cannot do requests, but mainly because nobody wants to maintain the same slightly different request 100 times across scripts, docs, and collections.
And on the “UI tools become dead ends” point: yes, that is the trap we are trying to avoid. We do not want a bespoke black-box UI where if there is no button, you are stuck. The idea is to have one source of truth that can still work for power users, can be versioned in Git, can be shared, can be documented properly, and can evolve into automation/CLI/agent workflows as well.
So from my side it is not “UI versus terminal.” That debate is honestly a bit too small. What if we reframe this to: “Can we have one composable, reviewable, reusable representation of API work that serves both the terminal-native people and the wider team without duplicating everything across five tools?”
That is basically the whole bet.
So yeah, I get the skepticism. I have it too. The world does not need another glossy “API client” that turns into a toy the moment you step outside the happy path.
The point of Voiden is precisely to avoid that fate. I am sure you will see how radically different Voiden’s take is, if you just give it a spin for a few mins. In a world full of postman clones - we want Voiden to really stand out with a different approach to api tooling. :)
this is the fundamental meditation.
yes :) welcome to try
yay - feel free to add few of these QoL tweaks here: https://github.com/VoidenHQ/voiden/issues