The decision changes a lot depending on whether you're building developer tools or vertical SaaS for a specific industry.

I build accounting automation software. The defensible part isn't the code architecture - it's years of accumulated domain knowledge. How different platforms handle VAT codes differently. How the same merchant shows up as fifteen different description strings on bank statements. What a "partial invoice payment with a currency adjustment and a bank fee" actually looks like when you need to post it correctly.

Open sourcing that would hand competitors the playbook without helping end users, because end users are bookkeepers, not developers. They don't want to read source code. They want to log in and have their transactions coded.

For developer tools the logic flips entirely - your users CAN evaluate and contribute to the source, and trust matters in a way that only auditability can satisfy (as another commenter noted about credentials). But the article's framework seems to assume your end user is technical. For vertical products where the complexity is domain knowledge rather than code patterns, staying closed is usually the right call.

Why not a single word about competition with other companies?

Even before AI ElasticSearch got smashed by Amazon with their own product.

Now with AI "translation", they don't even care about license.

I dabbled in my own open source projects over the years. I learned that I really just like serving my customers directly. I don't enjoy managing PRs or responding to feedback from strangers. I think "who you enjoy to serve" is a useful frame for deciding how to go to market. Each type of go-to-market approach has it's own type of 'customer.'

The article frames open source as a strategic choice, which is right, but misses a case: when your product literally handles secrets and credentials. If your agent framework touches API keys, tokens, and personal data, closed source is a non-starter for the security-conscious. You cannot audit what you cannot read.

We are building an agent platform (SEKSBot, a fork of OpenClaw) and open source is not a growth hack for us — it is a prerequisite. Nobody should trust an opaque binary with their API keys.

Finally, an AI article I enjoy. Give me nice bulleted summaries (and actually accurate content, unlike most blog posts) over 6-page paragraphs any day.

I know some people want to ban AI posts, but I want the opposite: ban any post until AI has looked over it and adds its own two cents based on the consensus of the entire internet & books it's trained on.

> After building Airbyte into a large open-source data infrastructure company...

Didn't Airbyte rugpull their license to ELv2?

I would love to see any journal showing how profitable an open source company vs closed source one (as a software house). imo terrible business idea?

This matches how I’ve been thinking about it.

With consensus.tools we split things intentionally. The OSS CLI solves the single user case. You can run local "consensus boards" and experiment with policies and agent coordination without asking anyone for permission.

Anything involving teams, staking, hosted infra, or governance sits outside that core.

Open source for us is the entry point and trust layer, not the whole business. Still early, but the federation vs stadium framing is useful.

Startups fail because of a lack of adoption far more often than by any other reason, including competitive and monetisation factors.

If your developer company gets popular you’ll be rich enough anyway. You might need to choose between screwing over your VCs by not monetising or screwing over your customers by messing around with licences.

But yourself as a founder will likely be okay as long as the tool is popular.

Didn't scroll past the vomit inducing AI generated "illustration" at the start of the article. If the author thinks that adds anything of value to the post, what else will they get wrong?