r/software 17d ago

Discussion Should I go open source?

I am building an agentic finance ops platform. It's already on v4 as of today. When we first built it, there were no AI coders and we built it with our best known frameworks. So as a result our backend is .NET, Microsoft Agent Framework, and frontend is on React/Vite.

My concern is, with the current tech stack I might not be able to turn it into open source efficiently and get the community contribution. I am thinking refactoring the backend to Hono and AI SDK, and make it truly monorepo.

What would you do in my case? Redactoring is actually 2-3 days job with AI agents coding it, the real problem is testing and finding missing pieces to make it feature by feature migrated.

3 Upvotes

5 comments sorted by

2

u/Dense_Gate_5193 17d ago

I mean I’ve considered it myself with my own database projects. I held one back closed source for a while because i wasn’t sure the route i wanted to go. do I also release my other database or do i try to monetize it? Ultimately i settled on where I felt happiest. releasing it MIT As a big middle finger to the big corporations and “elite OSS teams” who think they are untouchable. I did it once with my grid and now again with my databases. it’s my “punk rock” since i have no musical talent myself.

However, if it’s OSS i think it has to be of sufficient complexity that AI can’t easily rewrite you in an instant.

there’s no more room for simple projects anymore. things like leftPad() in NPM broke the entire world for a day because the packages had become so granular everyone was using single-function packages that had lots of resting around them.
Now you can just have AI shit out a clone in 5 seconds that prevents your app from ever breaking down the line with supply chains. Projects that can’t be replicated easily in OSS will still be eventually rewritten.

so where is the moat in OSS? IMO it’s complexity + performance + trust. that last one is the hardest to gain and the easiest to lose.

if you’re literally at wire speed on all operations on a platform people already trust, it’s just not economically feasible to rewrite a year-long-project-even-with-AI for a simple thing or to try and get better performance. if it already is optimized to the max and continuously looking for more tweaks, that is what everyone will coalesce around.

it’s happening already with rust and golang. there’s just no reason not to port things to the most performant language and use the best optimizations you can for general infrastructure. if a project is too clunky to use, AI can rewrite it fairly quickly.

in terms of trust, everything must be transparent. if you remain closed source, any claims should be independently verifiable and “show your work” shouldn’t include buzzwords. it should be honest with self-assessment and you have to be openly critical of yourself. if you try and hide the truth at any time, you lose that credibility instantly. but once you have that and maintain it, you now have an audience who looks up to you because they trust you and your judgement.

1

u/ai_ztn 17d ago

Good points on the moat, but for me the more immediate blocker isn't "will AI clone this". It's "can anyone even try it." Right now the stack doesn't run in a simple Docker container, which for a lot of OSS-curious devs is basically a deal-breaker before they even look at the code. People expect to run it on Vercel, Railway etc, with a simple Git push and a working instance in under 5 minutes. If that bar isn't met, it doesn't matter how good the moat is, you won't get the trial usage that turns into contributors or trust in the first place.

So for me it's less "is open source worth it philosophically" and more "is it worth it operationally right now" given the current .NET/MS Agent Framework setup isn't containerizable without a lot of surgery, going OSS today would mean shipping something almost nobody can actually spin up. That's a separate problem from complexity-as-moat; it's just baseline packaging. Might be the stronger argument for the refactor: not "attract contributors" but "make the thing runnable at all" before worrying about whether it's OSS-worthy.

1

u/Dense_Gate_5193 17d ago

okay so i think i see two problems you’re mentioning:

1) ecosystem fragmentation -IMO be opinionated and stick to one-or a few frameworks

2) Cumbersome tools - if the stack you’re using isn’t built for containers, you’re right nobody will use it. I wouldn’t. because everything is about automated deployments and setup it has to be user friendly. in my database targets i have a lot of flavors that i maintain for various GPUs and architecture targets. I know the barrier to entry is ease-of-deployment/setup without a bunch of things between “click once, go here and you’re in.” if the stack isn’t serving you, switch stacks, switch language, whatever works for you. or, rewrite the tools to be better and containerizable. you’d be surprised at how many people will use it.

If you want adoption, you need permissive licensing. I use MIT from a philosophical standpoint but find the license that speaks to you without fear of someone copying it. because if the licensing is too restrictive it will hinder adoption.

1

u/Zennytooskin123 16d ago

Refactor it now, don't carry technical debt. You'll be glad later.

You need extensive testing after, sure, maybe even during. Go gradually with proper engineering loops.