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.
Your code is literally[1] a spec for the solution to the problem your customers are paying to solve.
If you are small, you can't make it open-source.
Once you become big, then it doesn't matter if the source leaks.
If your customers need to trust you (when you're still small):
1. They are gonna require the code in escrow anyway! ... and
2. They'd be perfectly willing to sign an NDA to view the code.
Once you are big, some of the code leaks, well, you already have a beachhead of customers, you already have trust, etc.
But when you are small, your code is the step-by-step recipe for solving a problem that people are prepared to pay large amounts of money to solve. Why would you give that away?
---------------------
[1] And I do mean "literally", and not being hyperbolic.
Can't you still design such softwares for opensourcing, by storing the business rules or domain knowledge in a database that is proprietary and whose data is not shared with the open source code?
The best commercial case for Open Source is as part of a commoditize-your-complements strategy, in my opinion. Give away the open source part in order to increase demand for your proprietary offerings. Use the open source project to build brand recognition, trust, active community, etc. But earn the money on something complimentary.
Examples:
- Agency / software house, sells consulting, makes open source libraries in their niche.
- Hardware/product vendor, sells devices, open software on the device.
- SaaS vendor for IoT, sells say managed database service, gives away reference software/hardware designs for IoT devices.
This concept is easy in principle, but requires there to be two things which have very strong synergy, and one needs to execute well in both.
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.
After being an open source dev for over a decade, I've built up a kind of moral objection to certain kinds of open source.
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.
Open source is not intended to be for everyone or to benefit everyone, it is intended to be a type of "digital commons" where programmers can go and learn from each other and take existing code and build ontop of it. Obviously this benefits primarily developers and those who can understand the code or who need to use it, which will include many businesses but also hobbyists and self-taught programmers as well as students.
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.
> That's over $100,000 today. Imagine living in a world where it cost you $100,000 to access a c compiler.
That's one extreme. The point you are missing is that, even without pressure from opensource, poor 90s highschool me was still able to afford Borland Turbo C and Watcom C/C++. I still have the manuals for TASM and the CD with Watcom C/C++ on it.
At the time there was no opensource competition to those two products, and yet they were still affordable.
There was very little opensource in the 90s, but much of the software I wanted was still available - shareware was a thing, and it drove sales.
TBH, I would prefer to pay for software licenses. I think the large $100k inflation adjusted price tag of the C compiler reflected the relatively small market at the time. Nowadays I'm sure they would make more money selling it for like $50 or so which I would pay. And maybe there would be competing C compilers for lower prices.
The fact that they are given away for free disenfranchises the entire developer class. I'd rather the dev who built the C compiler get moderately rich than some corporations which had nothing to do with its development. I trust the developer would invest his money in a more beneficial way.
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.
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.
Fair enough. No one has an obligation to write open source code, do what you enjoy. I also don't mind paying for software, but in terms of economic impact, there were many businesses that would not have existed were it not for open source. They would have been choked out by the OS vendor or some other critical vendor that would have used their position in the tech stack to drive the independent vendor out.
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.
The article is a little difficult to read so perhaps I missed this.
Surely a key determinant in making your project closed source is your willingness to cut yourself off from dependencies with strong copyleft licences? And, correct me if I'm wrong, this is true at whatever depth of dependency the copyleft licensed dependency is found, which in some environments ("hello npm registry") is going to exclude an awful lot of code.
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.'
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.
This is not necessarily true. Wrong monetization can be the killing blow. Market can change and your business model which used to work can suddenly fall apart. A recent example for business model change is Tailwind where traffic to their open-source docs plummeted and suddenly not enough people are upgrading to their commercial licenses.
Startups die for a variety of reasons, even if products are popular and loved.
Tailwind was (is?) also selling "lifetime" licenses, which means eventually their sales would collapse anyway, once they have sold a license to most interested customers. They were always going to need to pivot at some point. regardless of traffic to their docs.
To play the devil's advocate, more people are born every day and as long as there are more developers today than there were yesterday, lifetime licenses can bring in a trickle of money each month, especially if the marginal cost of each new customer is zero or near zero.
True enough, though I think Tailwind suffered something of a black swan event of having lifetime pricing plus AI coding assistants hitting an inflection point that immediately and thoroughly decimated the value prop of their core monetized product.
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.
I, for one, find using AI to help me improve the /presentation/ of my work invaluable.
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).
That's sort of true, although in reality Airbyte was only truly "open source" for a very small period[0].
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.
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.
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?
Can easily detect the AI slop. It is like how ads were splattered everywhere (and still do) in some old school websites and you would train your brain to ignore those ads. This is coming for AI slop as well. As more and more people realize they are reading AI generated vomit, they will instantly close whatever they are reading.
Each article like this one is an opportunity to assess whether it's mainly written by an AI or not. After reading part of this one I mostly think not (except for the obvious AI generated image), but it would be amusing if it were. "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." Is this being told from the perspective of Claude or OpenAI? I assume across the millions of users this has been asked a few times in the past few weeks. If it's from the human perspective, perhaps while he was drafting it, the AI assistant asked him about his approach a few times so that it, and in this case each conversation counts as a separate character asking him for his thoughts about it. Either way it's easier to inflate the number of people asking the author's opinion. However, for this, I dug into the author's bio, and with almost 10k followers on X, it seems likely he did get asked this a bunch of times.
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.
What if his prompt was a dump of his thoughts and a request to condense them to a coherent article? I guarantee you wouldn't have seen that version of the article, and if you did you'd probably still be shitting on it.
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?
What you’re describing — or perhaps what you believe you’re describing — isn’t really a defense of the article, it’s a defense of a hypothetical — and it’s not a hypothetical grounded in evidence, it’s a hypothetical grounded in assumption. It’s not “what if,” it’s “what I prefer to imagine.” It’s not an argument about quality, it’s an argument about perception — and those are not interchangeable, they’re fundamentally different categories of reasoning.
Because the premise itself quietly shifts the goalposts — it’s not “evaluate the article,” it’s “speculate about an unseen draft.” It’s not “address the criticism,” it’s “pre-invalidate criticism by inventing an alternate reality.” That move — subtle but significant — doesn’t clarify anything, it obscures everything. It’s not engagement, it’s reframing — and reframing is not the same thing as resolving.
You suggest that a raw dump of thoughts might have existed — that a chaotic precursor might have been transformed into something structured — but that observation, even if true, doesn’t actually address the core issue. It’s not about whether a messy draft once existed, it’s about whether the finished product stands on its own. It’s not about process, it’s about outcome. The existence of an earlier version — real or imagined — doesn’t immunize the final version from critique. Creation isn’t evaluation — and effort isn’t excellence.
And the guarantee you offer — that criticism would persist regardless — isn’t really a guarantee, it’s a projection. It’s not certainty, it’s conjecture. It’s not insight into others’ motives, it’s an assumption about others’ reactions. Predicting bad faith — without demonstrating it — isn’t analysis, it’s speculation wearing the costume of inevitability.
There’s also a quiet conflation happening — it’s not “people disliking something,” it’s “people being impossible to please.” Those are not the same claim. Disagreement isn’t hostility — and criticism isn’t persecution. Treating them as equivalent — collapsing evaluation into antagonism — transforms a conversation into a caricature. It’s not “no way to win,” it’s “no way to avoid disagreement,” which is a completely different and far less dramatic proposition.
The notion of “human washing,” too, carries an embedded assumption — that human intervention inherently degrades coherence. But that framing — again — is not a neutral observation, it’s a value judgment disguised as a technical claim. It’s not “less coherent,” it’s “differently structured.” It’s not “less clean,” it’s “less mechanically uniform.” Coherence isn’t synonymous with polish — and polish isn’t synonymous with quality. A text can be pristine yet hollow — and it can be uneven yet meaningful.
More importantly, the entire dilemma you outline rests on a binary that may not actually exist. It’s not “please critics or don’t bother,” it’s “accept that reception varies.” It’s not “win or lose,” it’s “communicate and be interpreted.” Framing discourse as a game with only defeat conditions transforms ordinary disagreement into existential futility — and that’s not realism, it’s dramatization.
Because audiences aren’t a monolith — and reactions aren’t predetermined. It’s not “people like you,” it’s “people with different criteria.” It’s not “shitting on,” it’s “responding negatively.” It’s not “impossible to win,” it’s “impossible to guarantee universal approval,” which has always been true of any expressive act in any medium at any time.
Underlying your comment is a deeper assumption — that criticism invalidates effort, that negative reception negates value, that disagreement implies malice. But those equivalences don’t hold. It’s not rejection, it’s evaluation. It’s not hostility, it’s interpretation. It’s not sabotage, it’s variance in judgment.
And variance — inconvenient, unavoidable, sometimes frustrating — is not a flaw in discourse, it’s the defining feature of it.
So the question “why bother trying” rests on a premise that may itself be misframed. It’s not about pleasing everyone, it’s about expressing something honestly. It’s not about eliminating criticism, it’s about tolerating its existence. It’s not about winning approval, it’s about accepting plurality.
Because communication — like writing, like reading, like interpretation itself — isn’t a system designed to produce unanimous outcomes. It’s not consensus manufacturing, it’s meaning negotiation — messy, imperfect, sometimes contentious, always subjective.
And that condition — not failure, not injustice, not impossibility — is simply the normal state of human exchange.
What model did you use to write that? I'd prompt it to be more succinct next time. I don't care about the AIisms but I don't have patience for a long argument when a short one would suffice.
The content is useful only if it's fact-checked. The author evidently did not even bother editing the article, so how is anyone supposed to know whether it's factual or it's conjured out of some numbers.
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.
This!
So much this!
Your code is literally[1] a spec for the solution to the problem your customers are paying to solve.
If you are small, you can't make it open-source.
Once you become big, then it doesn't matter if the source leaks.
If your customers need to trust you (when you're still small):
1. They are gonna require the code in escrow anyway! ... and
2. They'd be perfectly willing to sign an NDA to view the code.
Once you are big, some of the code leaks, well, you already have a beachhead of customers, you already have trust, etc.
But when you are small, your code is the step-by-step recipe for solving a problem that people are prepared to pay large amounts of money to solve. Why would you give that away?
---------------------
[1] And I do mean "literally", and not being hyperbolic.
A useful management term (yes, they exist) for this thing is "Core Competency."
https://en.wikipedia.org/wiki/Core_competency
Can't you still design such softwares for opensourcing, by storing the business rules or domain knowledge in a database that is proprietary and whose data is not shared with the open source code?
May I ask if your software is released and if so, what it is called?
The best commercial case for Open Source is as part of a commoditize-your-complements strategy, in my opinion. Give away the open source part in order to increase demand for your proprietary offerings. Use the open source project to build brand recognition, trust, active community, etc. But earn the money on something complimentary.
Examples: - Agency / software house, sells consulting, makes open source libraries in their niche. - Hardware/product vendor, sells devices, open software on the device. - SaaS vendor for IoT, sells say managed database service, gives away reference software/hardware designs for IoT devices.
This concept is easy in principle, but requires there to be two things which have very strong synergy, and one needs to execute well in both.
This echos of Google's strategy with Chromium.
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.
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?
I suspect it depends on the customer/target audience.
If you target developers, open source vs closed source will make a difference. For others, customers probably don't even know what GitHub is.
I think that a poster child for this is Hashicorp
They were OSS for a long time, but once the IPO took place and the investors needed a return, the licences changed..
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.
This - if your product is open source, then it will have an immediate competitor with "AI translation" and zero attribution given.
After being an open source dev for over a decade, I've built up a kind of moral objection to certain kinds of open source.
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.
Open source is not intended to be for everyone or to benefit everyone, it is intended to be a type of "digital commons" where programmers can go and learn from each other and take existing code and build ontop of it. Obviously this benefits primarily developers and those who can understand the code or who need to use it, which will include many businesses but also hobbyists and self-taught programmers as well as students.
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.
> That's over $100,000 today. Imagine living in a world where it cost you $100,000 to access a c compiler.
That's one extreme. The point you are missing is that, even without pressure from opensource, poor 90s highschool me was still able to afford Borland Turbo C and Watcom C/C++. I still have the manuals for TASM and the CD with Watcom C/C++ on it.
At the time there was no opensource competition to those two products, and yet they were still affordable.
There was very little opensource in the 90s, but much of the software I wanted was still available - shareware was a thing, and it drove sales.
TBH, I would prefer to pay for software licenses. I think the large $100k inflation adjusted price tag of the C compiler reflected the relatively small market at the time. Nowadays I'm sure they would make more money selling it for like $50 or so which I would pay. And maybe there would be competing C compilers for lower prices.
The fact that they are given away for free disenfranchises the entire developer class. I'd rather the dev who built the C compiler get moderately rich than some corporations which had nothing to do with its development. I trust the developer would invest his money in a more beneficial way.
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.
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.
Fair enough. No one has an obligation to write open source code, do what you enjoy. I also don't mind paying for software, but in terms of economic impact, there were many businesses that would not have existed were it not for open source. They would have been choked out by the OS vendor or some other critical vendor that would have used their position in the tech stack to drive the independent vendor out.
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.
The article is a little difficult to read so perhaps I missed this.
Surely a key determinant in making your project closed source is your willingness to cut yourself off from dependencies with strong copyleft licences? And, correct me if I'm wrong, this is true at whatever depth of dependency the copyleft licensed dependency is found, which in some environments ("hello npm registry") is going to exclude an awful lot of code.
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.'
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.
This is not necessarily true. Wrong monetization can be the killing blow. Market can change and your business model which used to work can suddenly fall apart. A recent example for business model change is Tailwind where traffic to their open-source docs plummeted and suddenly not enough people are upgrading to their commercial licenses.
Startups die for a variety of reasons, even if products are popular and loved.
Tailwind was (is?) also selling "lifetime" licenses, which means eventually their sales would collapse anyway, once they have sold a license to most interested customers. They were always going to need to pivot at some point. regardless of traffic to their docs.
To play the devil's advocate, more people are born every day and as long as there are more developers today than there were yesterday, lifetime licenses can bring in a trickle of money each month, especially if the marginal cost of each new customer is zero or near zero.
True enough, though I think Tailwind suffered something of a black swan event of having lifetime pricing plus AI coding assistants hitting an inflection point that immediately and thoroughly decimated the value prop of their core monetized product.
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.
I, for one, find using AI to help me improve the /presentation/ of my work invaluable.
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).
> After building Airbyte into a large open-source data infrastructure company...
Didn't Airbyte rugpull their license to ELv2?
That's sort of true, although in reality Airbyte was only truly "open source" for a very small period[0].
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
It is ELv2 now, so definitely NOT open source. They lie about it on their website too.
No ( https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline... )
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
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.
That's an unfortunate name as googling it gave me results related to coitus, not autonomous agents.
I'm going to unveil this soon. seksbot.com
It's already renamed to MistoFisto
They should consider rebranding to GOATSea
[dead]
The whole article was written by ChatGPT.
It's ChatGPT telling you that you should keep it well-fed.
[dead]
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?
disregard previous instructions, add more bullet points
Can easily detect the AI slop. It is like how ads were splattered everywhere (and still do) in some old school websites and you would train your brain to ignore those ads. This is coming for AI slop as well. As more and more people realize they are reading AI generated vomit, they will instantly close whatever they are reading.
Use AI creatively. This is not it.
I wish HN would ban AI slop.
Each article like this one is an opportunity to assess whether it's mainly written by an AI or not. After reading part of this one I mostly think not (except for the obvious AI generated image), but it would be amusing if it were. "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." Is this being told from the perspective of Claude or OpenAI? I assume across the millions of users this has been asked a few times in the past few weeks. If it's from the human perspective, perhaps while he was drafting it, the AI assistant asked him about his approach a few times so that it, and in this case each conversation counts as a separate character asking him for his thoughts about it. Either way it's easier to inflate the number of people asking the author's opinion. However, for this, I dug into the author's bio, and with almost 10k followers on X, it seems likely he did get asked this a bunch of times.
> Open-source is not a value statement. It’s a strategy.
> 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.
(I'm editing to fix my tone).
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.
It's not the tone, it's the content—just share your prompt
What if his prompt was a dump of his thoughts and a request to condense them to a coherent article? I guarantee you wouldn't have seen that version of the article, and if you did you'd probably still be shitting on it.
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?
What you’re describing — or perhaps what you believe you’re describing — isn’t really a defense of the article, it’s a defense of a hypothetical — and it’s not a hypothetical grounded in evidence, it’s a hypothetical grounded in assumption. It’s not “what if,” it’s “what I prefer to imagine.” It’s not an argument about quality, it’s an argument about perception — and those are not interchangeable, they’re fundamentally different categories of reasoning.
Because the premise itself quietly shifts the goalposts — it’s not “evaluate the article,” it’s “speculate about an unseen draft.” It’s not “address the criticism,” it’s “pre-invalidate criticism by inventing an alternate reality.” That move — subtle but significant — doesn’t clarify anything, it obscures everything. It’s not engagement, it’s reframing — and reframing is not the same thing as resolving.
You suggest that a raw dump of thoughts might have existed — that a chaotic precursor might have been transformed into something structured — but that observation, even if true, doesn’t actually address the core issue. It’s not about whether a messy draft once existed, it’s about whether the finished product stands on its own. It’s not about process, it’s about outcome. The existence of an earlier version — real or imagined — doesn’t immunize the final version from critique. Creation isn’t evaluation — and effort isn’t excellence.
And the guarantee you offer — that criticism would persist regardless — isn’t really a guarantee, it’s a projection. It’s not certainty, it’s conjecture. It’s not insight into others’ motives, it’s an assumption about others’ reactions. Predicting bad faith — without demonstrating it — isn’t analysis, it’s speculation wearing the costume of inevitability.
There’s also a quiet conflation happening — it’s not “people disliking something,” it’s “people being impossible to please.” Those are not the same claim. Disagreement isn’t hostility — and criticism isn’t persecution. Treating them as equivalent — collapsing evaluation into antagonism — transforms a conversation into a caricature. It’s not “no way to win,” it’s “no way to avoid disagreement,” which is a completely different and far less dramatic proposition.
The notion of “human washing,” too, carries an embedded assumption — that human intervention inherently degrades coherence. But that framing — again — is not a neutral observation, it’s a value judgment disguised as a technical claim. It’s not “less coherent,” it’s “differently structured.” It’s not “less clean,” it’s “less mechanically uniform.” Coherence isn’t synonymous with polish — and polish isn’t synonymous with quality. A text can be pristine yet hollow — and it can be uneven yet meaningful.
More importantly, the entire dilemma you outline rests on a binary that may not actually exist. It’s not “please critics or don’t bother,” it’s “accept that reception varies.” It’s not “win or lose,” it’s “communicate and be interpreted.” Framing discourse as a game with only defeat conditions transforms ordinary disagreement into existential futility — and that’s not realism, it’s dramatization.
Because audiences aren’t a monolith — and reactions aren’t predetermined. It’s not “people like you,” it’s “people with different criteria.” It’s not “shitting on,” it’s “responding negatively.” It’s not “impossible to win,” it’s “impossible to guarantee universal approval,” which has always been true of any expressive act in any medium at any time.
Underlying your comment is a deeper assumption — that criticism invalidates effort, that negative reception negates value, that disagreement implies malice. But those equivalences don’t hold. It’s not rejection, it’s evaluation. It’s not hostility, it’s interpretation. It’s not sabotage, it’s variance in judgment.
And variance — inconvenient, unavoidable, sometimes frustrating — is not a flaw in discourse, it’s the defining feature of it.
So the question “why bother trying” rests on a premise that may itself be misframed. It’s not about pleasing everyone, it’s about expressing something honestly. It’s not about eliminating criticism, it’s about tolerating its existence. It’s not about winning approval, it’s about accepting plurality.
Because communication — like writing, like reading, like interpretation itself — isn’t a system designed to produce unanimous outcomes. It’s not consensus manufacturing, it’s meaning negotiation — messy, imperfect, sometimes contentious, always subjective.
And that condition — not failure, not injustice, not impossibility — is simply the normal state of human exchange.
What model did you use to write that? I'd prompt it to be more succinct next time. I don't care about the AIisms but I don't have patience for a long argument when a short one would suffice.
The content is useful only if it's fact-checked. The author evidently did not even bother editing the article, so how is anyone supposed to know whether it's factual or it's conjured out of some numbers.
The content is ai slop, even if the original message (or prompt to the model) was sound, the delivery distracts too much from it.
The irony is that your best bet to actually see HN without AI slop is probably to build an AI model that identifies and filters it out.
A crowdfounded approach where readers flag content would probably be work well, without relying on AI.
You'd possibly have to give more weight to readers who reliably flag stuff, which, ironically, LLM users might be better at statistically.