Even before AI ElasticSearch got smashed by Amazon with their own product.
Now with AI "translation", they don't even care about license.
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.
Community efforts should almost always be kept separate from commercial works.
The one exception occurs during product deprecation, as there is no longer commercial interest in the investors property or curatorship. =3
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.
Didn't Airbyte rugpull their license to ELv2?
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.
It helps me to set the tone, improve the readability, and layout, but I do have to watch that it doesn't insert bad information (which is easy for me to either recognise or verify).
If you target developers, open source vs closed source will make a difference. For others, customers probably don't even know what GitHub is.
Startups die for a variety of reasons, even if products are popular and loved.
Having first hand experience with building multiple open source and open core dev infra companies, the advice in this article is spot on. If it is AI slop, it's still good advice.
I'd prefer comments focused on content vs. trying to Turing-test AI generated text.
Use AI creatively. This is not it.
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.
In reality, since about 1 year into the project, it's operated with a mix of open and "less open" licenses for different parts of the codebase, in a way that would make it difficult to just use the MIT licensed bit.
I think that kinda proves the point you were going for.
[0] https://github.com/airbytehq/airbyte/commits/master/LICENSE
If it was truly "for everyone" then we'd be seeing many more small tech startups succeed and a more vibrant ecosystem where open source devs would be supported and have access to opportunities. Also, getting traction would be more merit-based.
Currently, open source, in certain domains, is almost exclusively monetized by users whose values oppose my own. I'd rather sell or even give away cheap unlimited, permissive licenses to users of my choice, one by one and give them an actual competitive edge, than this faux "share with everyone" attitude. I explicitly don't want to share with bad actors. I explicitly don't want to empower bad actors.
The value extraction pipelines in the economy are too strong, all the value goes into a tiny number of hands. It's so direct and systematic, I may as well just hand over my project and all IP rights exclusively to big tech shareholders. This is an immoral or amoral position given the current system structure.
Open source is fundamentally not what it used to be because the composition of beneficiaries of open source software are fundamentally different. Well I guess it depends on what kind of software but for what I'm doing, it's definitely not going to benefit the right people.
They were OSS for a long time, but once the IPO took place and the investors needed a return, the licences changed..
> The only question that matters is this: Does open-source structurally help this product win?
> A hard filter first: Only technical users are emotionally sensitive to open-source.
> Important framing shift: OSS is not the product. OSS is the entry point.
> Open-source is powerful. But only when it is deliberate.
Finally, the random bolded bits of text.
This article is literally copy pasted directly from some LLM, and I'm fairly sure it's ChatGPT.
There's no way to win (except to human wash the article, which ironically usually involves making it less coherent/clean), so why bother trying to please people like you?
Before open source, even things like compilers and C libraries were closed source, and you needed to buy them from a vendor and were in trouble if the vendor went out of business. The original C compiler and library by Bell Labs were only licensed for $20,000 in the early 1970s. That's over $100,000 today. Imagine living in a world where it cost you $100,000 to access a c compiler. The effect of that is that only very large businesses and universities had access. Everyone else was locked out.
Now, we don't need to worry about that, we have a large library of tooling, we have operating systems, we have compilers and frameworks, all open source. That is the purpose of open source code and it has worked remarkably well.
But if you want to "benefit everyone", then look for something like universal basic income, as software licensing models aren't the tool to accomplish that.
Well until we have UBI, I'm out of open source. No new projects at least. I've done my share of open source. Excruciatingly painful experience, not doing that again in the current system. I'd have to be an idiot to do it again.
I mean generosity is good to a point, but beyond a certain point, it turns into stupidity.
If it's just a commons with no moral ideology, then let the corporations build all the open source tools and share it amongst themselves. I suppose that's what's been happening.
If you think MS is bad, wait until you need the permission of IBM or ATT to write some server code. Google is starting to do well in search? Well, the OS vendor just changed their license to require revenue sharing for that. Don't like it? Write your own OS and drivers. BIOS, too, while we are at it.
So I'm glad open source exists, and it allows people to write closed source code ontop of it whenever they want without paying taxes to people who own the tech stack you need.
[

I’ve been asked a few times about my approach to open-source in the past few weeks, so decided to write this article to structure my thoughts.
Most founders get the open-source decision backwards. They start with “open-source is great for distribution” and work backwards to justify it.
That’s how you end up with:
an OSS project nobody meaningfully contributes to,
a “community” Slack that is actually a support queue,
and a monetization strategy that competes with your own free tier.
Open-source is not a distribution hack. It is an architectural decision about your product, your business model, and your execution bar.
The wrong one is expensive to reverse.
After building Airbyte into a large open-source data infrastructure company, I’ve been asked dozens of times: Should we go open-source?
Here is the framework I use to answer that question.
“Developers love open-source.”
“Open always wins.”
“Proprietary is dead.”
None of these are useful statements. The only question that matters is this: Does open-source structurally help this product win?
Win can mean:
faster adoption,
stronger defensibility,
lower customer acquisition friction,
or better long-term monetization.
If you cannot explain how OSS compounds one of those for your specific product, you are not making a strategic choice. You are following vibes.
A hard filter first: Only technical users are emotionally sensitive to open-source.
Builders care about OSS for:
inspecting and trusting code,
self-hosting and control,
extensibility,
learning and ideology.
Non-technical buyers still care about OSS, but instrumentally:
lower vendor risk,
easier internal adoption,
reduced lock-in,
better auditability.
This distinction matters because it leads to the most important OSS test.
There are two fundamentally different OSS community shapes.
Many users
Many contributors
The product improves as the community grows
This only works when the user persona and contributor persona are the same, or at least sit in the same team.
Airbyte worked because data engineers used connectors and built connectors. Most infra and data projects follow this pattern. Now flip it.
An open-source Segment-like product would have:
PMs as users
data engineers as contributors
That breaks the loop. When contributors are serving users rather than being users, you don’t get federation. You get a stadium.
Federation OSS
Strong network effects
Contribution velocity compounds
Tends toward standards
Winner takes most
Stadium OSS
A small core team builds
The community watches, occasionally extends
No inherent product network effect
Multiple winners can coexist
Neither model is bad. Confusing them is lethal. If you expect community contributions without persona alignment, you will wait forever.
And yes, in federation-type OSS, winner takes most. Not because of ideology, but because contributors optimize for impact per hour and visibility. Nobody wants to maintain the 7th most popular orchestrator.
In practice, markets converge to one to three leaders. Rarely more, in both cases.
Open-source works best on well-understood problems.
Why?
Because the market already has:
shared vocabulary,
established mental models,
clear comparison points.
OSS required market education when it has to do category creation and community creation at the same time. While it doesn’t mean it can’t be successful, it requires some extra efforts.
One of the strongest OSS adoption drivers is data sovereignty. Open-source is self-hosted by default. That matters less because of cost and more because of speed. Procurement is slower than curiosity.
OSS lets engineers start:
without security review,
without vendor onboarding,
without legal approval.
This is why OSS is such a powerful bottom-up wedge in data, infra, and security. Sensitive data and high blast radius amplify this effect.
Important framing shift: OSS is not the product. OSS is the entry point.
Extensibility is a legitimate OSS advantage. It is also how many OSS companies destroy themselves.
Extensibility only works if:
extension points are explicit and stable,
the core stays boring,
contributors do not fork the roadmap.
Here is the uncomfortable truth: If you cannot say no to contributors, you should not run a federated OSS project.
Governance is not optional. It is part of the product.
This is where most teams fail. The question is not “what should we open-source?” The question is “what job should OSS fully solve?”
A durable pattern:
OSS maximizes time to first value (you should measure your time to your aha moment for an OSS user, this is what will drive your OSS adoption)
Paid solves coordination, scale, and risk
At Airbyte, OSS fully solves the single-user use case. One engineer moving data from A to B, fast.
Anything involving:
teams,
scale,
reliability guarantees,
governance,
or operational coordination
…does not belong in OSS.
This does two things simultaneously:
maximizes bottom-up adoption,
preserves a clean, non-hostile path to monetization.
If your OSS roadmap starts accumulating enterprise features, your conversion rate will collapse. Slowly at first. Then all at once.
Most companies build before they buy. And when engineers build, they start with open-source. Not because they hate vendors, but because OSS accelerates learning and reduces early risk.
That’s why OSS increases market size. You address both build and buy.
Now add a new variable. AI is rewriting how companies build. Faster, cheaper, and messier.
A new question founders must ask: Does my OSS product compose with AI-assisted building, or compete with it?
Individual code is increasingly commoditized. Ecosystems, connectors, and battle-tested surfaces are not.
This deserves to be explicit.
Cloud-hosting your OSS project is:
a distribution convenience,
a pricing anchor,
a control plane.
It is not differentiation. If a more mature cloud solution already exists, OSS will not magically erase that gap.
Extensibility, control, deployment flexibility, all of that are differentiators. To be clear, I’m not advocating that all OSS companies should have a self-hosted premium solution primarily. My point is that we should focus on differentiations, which ones resonate the most with which audience for which budget. This should drive your product strategy.
Open-source raises the execution bar.
You sign up for:
permanently high documentation quality,
public roadmap discipline,
backward compatibility paranoia,
community support at scale.
OSS also locks in decisions early. APIs, data models, and extension points become public contracts.
Ask yourself early: which mistakes am I willing to live with for the next ten years?
Because you will.
Before committing to open-source, you should be able to answer yes to most of these:
Is my user persona technical?
Is my contributor persona the same as my user persona?
Is the problem already well understood?
Does OSS bypass a real adoption bottleneck?
Can I clearly define the OSS wedge and the paid boundary?
Can I say no to contributors?
Does my business survive a fork?
If not, closed-source is not a failure. It is often the smarter move.
Open-source is powerful. But only when it is deliberate.
No posts