There is some tricky big assumption being made here around sustainable profitability that misses our lived reality, especially given challenges like US developer salaries. Paraphrasing, OSS companies need lightning to hit twice, first for the OSS and then again for the company.
In our case, the Graphistry team loves and breathes OSS every day. We helped start what became the massively popular Apache Arrow and Nvidia RAPIDS projects, release our Python & JS clients as OSS, and PyGraphistry[AI] is a graph Swiss army knife, including tools like GFQL the only embeddable & dataframe-native & GPU-accelerated implementation of the Cypher graph query language..
... But we sustainably grow primarily by selling cloud/on-prem self-hosting licenses to enterprises, govs, and data companies to our GPU graph viz server. Thankfully, after years of grinding, that business is growing well. As a natural experiment, our alternate SaaS hosting revenue does support a tiny team... but not the majority of our team. Most of our innovation cycles would disappear without our self-hosting license revenue.
There's some cross of winning lottery ticket, SaaS market profile, and technical defensibility getting missed in the article that I can't put my finger on. Our launches of Louie.AI + GFQL are changing the OSS viability story in our particular case (I'd love to chat w successful founders here!), so I'm not saying it can't work, but our experience to get to this point makes me worried for new founders reading the article.
Thoughtful post, thanks. However, this tripped me up: "our GPU graph viz server" -- I couldn't understand how you a) scale graphviz[1] on a GPU and b) make money hosting graphviz. Quick read of your web site cleared that up :)
Are the companies that buy your on prem solution buying the source code or the support? In other words if you said to them “hey the source is open now” would they say “oh cool we’ll be canceling our contract”?
> - People might criticize my messy/bad/unfinished code
As someone who has created and maintained open source projects (most recently Willow[0]) for two decades I get a kick out of this.
Of course when interacting with users and feedback I keep it polite but in my head I'm thinking "You like to talk. I actually DID this. Shut up or submit a PR".
That is covered further down in the "Late stage" paragraph.
Basically, you are already winning if the big ones try to emulate you, though some advanced planning to mitigate this is needed. But it should not be the focus nor worry at the start, if I interpret the article correctly.
This is a really good in depth article but misses one thing so many projects miss: just sell to the civil government.
USG has so many programs (eg NSF grants) for tech and the disjointedness of civil agencies, IC, and state govts means they end up procuring a dramatically large landscape of software. The regulatory and compliance bar to entry is not nearly as high as you think especially if you are teaming your first few contracts. It is solid, guaranteed revenue to fund your project for usually 3-5 year commitments, and usually massively profitable.
I wish more open source companies took advantage of this, because usually fully private sector companies will end up baking open source libraries into their project and sell it at gigantic markups, pocketing everything.
eg: https://x.com/ssankar/status/1749202248700420587?s=20
When I was in govt I saw so much software that was basically open source maps + open source db for $12m. To give another frame of reference, I’ve seen OCR on PDFs carry a $2mm price tag, and a tool like weights & biases carry $30mm (all $ per annum).
There are even other incentives here beyond deploying software; for example prioritizing fixing certain bugs or security flaws in your software — eg IC would have paid big $$ for safetensors.
I’ll even highlight four ways Supabase could do this:
- Cybercom (direct)
- DOS (direct or teaming)
- VA (thru a PWS)
- direct to govcon software powerhouses
And three ways to do this:
- cold email GS 14s/15s or equivalent
- hire an ex-GS15
- find a solicitation that fits on SAM.gov then use GovPro.ai (white glove) or rogue (diy) to put together a response
From what I've seen, governments and startups typically don't go well together. By the time the government bureaucracy has finally approved the contract, most startups would already have been out of money.
Just started doing government research contracts. If this is in anyway similar, I'd be wary. The contracts can be lucrative, but there is just a ton of red tape where you need to have people experienced in dealing with it. It isn't for everybody and it does take a lot of time and negotiation.
While I agree that government is an overlooked market, I would not start with the federal government. Massive bureaucracy aside, they are the largest, slowest and most difficult government entity to deal with. And there are literally tens of thousands of other government entities in the USA alone - schools, towns, counties, states, water and fire districts, libraries, etc.
If you want to get into the public sector, think small and wide, not all-in on the biggest one.
The business model of supabase is to market themselves as an open source company but in practice, no one in their right mind will try to self host for production. (you know, some subtle missing documentation or some subtle bugs or some subtle missing important features). So they get the praise for being open source but in fact, it is never practical. It is just marketing scheme.
There are actual benefits to a product like Supabase being opensource, some are:
1- Peace of mind. You might not choose to host it now, but you have one more way out, if you don't like their service (of course they also should provide access to your raw data)
2- Quality of code. If you have ever dealt with really bad code that works apparently well, you know how important it is to have code that you can proudly release to public.
3- Possibility of contribution. This is something I dismissed until it happened to me, in multiple occasions: you have a problem (missing feature, bug, performance problem, etc), you request it, or even contribute it. For most closed source projects, you're lucky if there is a transparent channel to request features.
One advantage of using open source products, even if you only use the commercial version, is that they place a limit on how “evil” the company can become: at some threshold, people might decide to put in the effort to fork it (like MariaDB).
My company has had people straight up tell us that they are comfortable using our managed service for that reason.
> some subtle missing documentation or some subtle bugs or some subtle missing important features
Unless you're implying that Supabase are for some reason deliberately releasing separate defective software to the open source community... to... convince users that using their commercial services is a good reliable option??? I can't really figure out how or why any business would go to the effort of doing this. It seems patently easier to be a legit open source company.
Assuming you're not implying the above & I've just misinterpreted... everything else in your comment paints Supabase in an eminently positive light.
I'm with you on this one. «Proper» open source software are installable with distributions package manager with workable defaults, albeit opinionated but crafted with minimum care for a targeted usage.
Maybe it's not viable for commercial purpose, but status quo hurt open source software hard by a strong erosion of what to expect of it, without clear long term benefits for companies choosing such a scheme.
The open source part, especially it being Postgres, makes it possible for me to move away if I choose to do so, while picking and choosing the parts I want to keep. This ability was crucial for me, I would not have used Supabase otherwise.
If you look at Firebase for example, there are countless stories of how difficult it is to move away.
Even if I won't self host Supabase, I can just take my schema, take my data, and put it elsewhere fairly easily as all the postgres extensions and everything is open source. I have the ability to move away from Supabase completely, and people have done this successfully before (see https://news.ycombinator.com/item?id=36004925).
Some people do actually self host btw, and supabase is adding more options like hosting on Fly.io.
Besides this there are other advantages:
- I run Supabase locally for testing (using their docker
images and CLI)
- We run Supabase in GH actions for automated testing and migrations
- I connect directly to the db, and use postgres tools for various things, backups, snapshots, db admin tasks.
- There are community clients for many different languages
Sure, it's also marketing, as these are all great benefits that really had a big impact on my decision to build on Supabase. Open source is more than just self hosting.
So let's entertain that this is in fact the case: it makes no sense in practice to self host for production. Even if that is the case, you're still better off building on top of an Open Source product because you're in a much stronger position in being able to fork than hoping that the company you rely on will stay around and not charge you to death.
A lot of products we all use underwent complex business changes, but the Open Source ones still are here for us to use. MySQL had a tumultuous past and yet there is a very active version of it hanging around under a new business.
The marketing angle is for the company to leverage, but the open source nature of it is for the user.
I think this is the case with most open-source projects that have both a cloud and self-hosted opening, they provide a much better experience for their hosted solution and don't spend a lot of effort into making their self-hosted version as usable as it could be.
I don't agree this is just a marketing scheme but in any case it's still a much better situation for consumers than companies with closed-source products.
Realistically, it feels like the actual utility of an open-source project is based on:
1. it being educational: so everyone can look into its source & learn from its design pattern, etc, or build upon or borrow parts (eg to be modified) and to be used in their own projects - but the practicality of it will really depend on how decoupled and well-designed the system is
2. in favour of competition (so more possible start-ups / big corps can clone their systems/services) and as consumers we will obviously benefit from that
3. llm can access & train on its source code
I think point 3 is most interesting. And I’m also super curious how true point 2 is and to what extend
Point 1 is really cool too - esp when it is done wonderfully (Linux, React for example) but it really depends on so many levels
You clearly don’t get the difference between business models and raising interest. It’s interesting that a service I would use has open code because, you know, transparency is important. That lazy or incompetent users can’t get complicated software running doesn’t mean a scheme is in place, either.
I love Supabase, commercial open source in general, and agree with lots of this post.
However this comment feels off:
> In software ideas are cheap. Value is almost always created in execution of ideas.
I've heard this phrase around things like "I have this cool idea for a startup - will you sign my NDA before I tell you about it?"
However, when you're open sourcing your software, you're not just providing an idea, but a significant portion of execution of that idea too.
Sure, code isn't the full execution - that expands to sales / marketing / support / etc.
However, the article is a little glib towards the value of the code, suggesting it's worthless without sales / marketing /etc. I don't think that's true.
"suggesting it's worthless without sales / marketing /etc. I don't think that's true."
Code is not worthless but it almost is without sales/marketing/talking to customers. If I could split the value, it would be 90% sales/marketing/customer validation and 10% code. I run a low 7 figure bootstrapped SAAS (not open source) and I can tell you that code is mostly shit anyway and keeps evolving.
I think code is worthless once it has been created. This is because the cost of copying is zero. You can't copy a house for zero but software yes.
The process of creating the code and solving all those little unseen problems is for what developers are paid.
Hence selling software is so profitable. If you don't sell software, you won't make money with it. Software is not like a physical object in a our shared reality.
Mongo and Elastic have changed there licenses to the "service-side public license" (SSPL) which is a particular own flavor of AGPL. The OSI has stated that this isn't an open source license. [1]
Barring a discussion about whether or not a license is "open source", what matters is that these businesses asserted that commonly used licenses - (A)GPL, Apache, MIT,... - are leaving ample room for competitors to setup their own managed / hosted services and compete with them through scale (e.g. Amazon's Open Search offering undercutting ElasticSearch).
I think the question is meant to mean "Should my company open the source of its software?"
But for me, answering the question as asked provides the path to answering the question as reworded. To me, the question as asked is about the nature of the software the company uses, not sells.
I personally will always choose an open source product over the alternative, even if I happily pay for support or just donate to support the project. Unfettered access to the source is fundamental to me, even for software I never intend to alter.
I know this seems to many like an extremist position. But I don't like the idea that I am not allowed to tear down my microwave or doorknob or transmission. I might never be able to put them back together in working order. Or I might be able to find a gear with a missing tooth and execute a $2 repair instead of a $90 replacement. Or I might invent a new frakenstein microwave with a tranmission.
Extending the featureset of a web server or understanding why my plugin is crashing the host app, etc. are important to me. I think they are important to society. So I hold on to my open source extremism. If you show me the hottest new tiny web server that can do HTTPS/4 with built-in AI in just 5Kb, I will be intrigued, but if it isn't open source, I'll stick with my current stack.
With this mindset, the software I produce is open source. And sometimes people pay me for it.
> If after 6 years, Google tries to steal your lunch, you should have a brand, a team, and a community, that have spent the last few years preparing for a David versus Goliath-type fight.
From my experience, for procurement people all of that (brand, community, team, DX) will matter close to 0 in comparison to compliance, etc, if you are going head-to-head with an existing supplier like Google.
Great point! I should probably add that to the article. In our case (Supabase) we have indeed spent the last few years working on compliance (SOC2, HIPAA, GDPR etc.) in order to meet these requirements so your comment here is on point.
We have been thinking about this for our product; we are definitely (and have this openly on our site) going to open source all under MIT or Apache (whatever we like by that time), but for now, but either of those, not AGPL or open-core or something like that), we find/found (not my first rodeo) it completely impossible to make money with that type of arrangement as a product (consultancy sure). Supabase had bucketloads of VC money, as do almost all 'big' open source projects. If you are bootstrapped, this is not going to pay the bills for quite a while especially on an ambitious / hard project. People only can work for free for so long and with closed code, a small team in constant contact etc you can move a lot faster by cutting the overhead needed for a successful OSS project.
It would be interesting to hear a story like this from a project of similar size that has $0 funding, has been founded in the last 5 years, has a fulltime team >1 and exists for 3+ years and still would recommend this approach. How are they making ends meet? Things like Redis simply don't happen anymore. At least; I haven't seen any. Hell, even trivial projects, like langchain, get in 10s of millions of VC and those would be my candidates for actually being able to do it as a few-man-band while getting in money via different sources.
One can release all code under free software licenses without being or trying to be “a successful OSS project” and its associated overhead.
All of my software is released as public domain (free software) and none of it is a successful open source project or community. Free software is first and foremost an ideology, and a practice or feature second.
Sourcehut is AGPL, maybe not as used as something like Redis but has managed to employ >1, is profitable (according to last report 2022) and has been around for 3+ years.
Open sourcing your company doesn't make sense, in my view, unless you're targeting developers or you're building a product that no one would realistically self host anyway, with Supabase being a prime example of both. For just the latter, Plausible Analytics is one, where one could self host (I in fact do, via Coolify.io) but you'd lose out on updates unless you build your own CI/CD system to pull and merge updates from their releases.
Probably not. Release your code publicly so people can read and contribute. Require paid licenses for commercial use over X numbers of seats where X is pretty generous and keep it free at the lowest tier. Those are hard things to claw back later without people completely losing their shit. Then the really hard part is to instill a culture inside your business that they paying customers are funding all the development and don't just obsess about the enterprise use case at the expense of all else. Keep showing the free tier people that you're listening to them. And that's what you'll fail at.
I love this topic, and I love Supabase. But I'd love to see a take on this from a purely business perspective, because so many companies lately have started out like this (Red Hat, Mongo, Elastic, Hashicorp, etc) and then walked it back after they became a success / went public.
Supabase is just getting started... in 10 years, what do you think are the chances they'll follow the exact path of those other companies which have been around much longer? To be honest, I think that's actually the only path to a sustainable company. Start open source so you can get a good name and free contributions from the community, and then when you've got a foothold on the market, change your license so you can stop other companies from exploiting your work (and the work of your contributors) at your expense.
I feel like the third point (competitors) is a major concern that was just brushed aside. The 'just out-innovate them' approach might work if your startup is well funded with a very capable and nimble development team. But what if you are a fledgling startup with very limited resources. You have a very small team that struggles to do a fraction of the features on your 'TO DO' list. You don't have millions of VC dollars that enables your team to keep the wolves at bay.
It wouldn't even take a tech giant like FAANG to outdo your project after forking your source. A medium-sized company could throw a dozen programmers on the project and their fork would surge ahead of the original with respect to features, support, and distribution. They could out-market you as well.
He writes:
"But my code is bad: This is just ego. The person who spends the most time thinking about you is you, and the person who spends the most time stressing over your bad code is you as well."
In most places in life this is valid, but in the developer community I disagree. Developers love talking shit about each others code.
Still yearly ritual here to bash the "Clean code" book.
IMO, no. Maybe with a sufficiently restrictive license. If your core product is good enough and you permissively license it, odds are someone else with more money is just going to repackage it and sell it without throwing any money your way.
On the other hand if your product isn't good enough then the decision doesn't matter since it won't take off either way. :)
The list of main complaints against OSS they present here is (conveniently?) missing the biggest one, in my opinion:
Your users can just host their own version instead of paying you.
It seems like many OSS companies mitigate this by leaving out features from the OSS version or making the deployment more difficult than it should be. I’m not complaining, I think it’s fair, but this is the reality.
It’s funny how they don’t address this one, but instead they list “oh no my code isn’t pretty” as a valid complaint against going OSS. Who cares.
I'd say that open-source works best for companies when they don't open the main thing. Meta building React in the open is a good example. The community gets a well-maintained library. Meta gets free testing, code contributions and potential hiring pipeline. When trying to compete with Meta, React gives you virtually no advantage. There's no incentive to leave important features out of the public codebase. Both Meta and the community benefit.
Would it make sense for Meta to open the codebase for facebook.com? Aside from studying/scrutinising the code, the only other thing you'd be able to do with it is to change the logo and try to compete with Facebook.
In this example, it's still probably not enough to disrupt them thanks to the social graph and infrastructure complexity. But you could imagine moments where even Meta gets nervous when anyone can start competing with feature parity from day one.
Over the long-term, it's more likely that Meta would want to keep some features private. It's also less likely that they would get lots of quality contributions back. If you're running a fb.com clone in production, you're likely trying to compete with them on some level. This leads to a weird relationship with the community and limited value for both sides.
One aspect I don't see mentioned is that it's not just about open sourcing your codebase. Many companies make the mistake of using open source as a marketing tool to attract users, and as a funnel into their commercial plans. They prioritize working on what makes them money, instead of being good maintainers of their open source product. They don't know how to build and nurture their open source community, and treat open source users as second-class compared to their commercial users.
Don't do this. The OSS product needs to be as featureful as your commercial product. It's fine to offer some commercial value added features and services that would only be useful for enterprise customers, but these shouldn't be core features of the product. You can have priority support for your paying customers, but don't leave OSS users with "community support" only. At the end of the day, the company does need to make money to survive, but treat all your users with the same respect. If the product is good enough and solves a genuine problem, you won't have difficulties monetizing.
From a Firebase perspective they might think that they never should have documented their concepts and APIs in the first place... :)
So a bit of the right words to the matching user base and with good points. Just that you always need to draw your own conclusion from your unique position.
Kudos for the the nicely adapted Jurassic Park scene.
[+] [-] lmeyerov|2 years ago|reply
In our case, the Graphistry team loves and breathes OSS every day. We helped start what became the massively popular Apache Arrow and Nvidia RAPIDS projects, release our Python & JS clients as OSS, and PyGraphistry[AI] is a graph Swiss army knife, including tools like GFQL the only embeddable & dataframe-native & GPU-accelerated implementation of the Cypher graph query language..
... But we sustainably grow primarily by selling cloud/on-prem self-hosting licenses to enterprises, govs, and data companies to our GPU graph viz server. Thankfully, after years of grinding, that business is growing well. As a natural experiment, our alternate SaaS hosting revenue does support a tiny team... but not the majority of our team. Most of our innovation cycles would disappear without our self-hosting license revenue.
There's some cross of winning lottery ticket, SaaS market profile, and technical defensibility getting missed in the article that I can't put my finger on. Our launches of Louie.AI + GFQL are changing the OSS viability story in our particular case (I'd love to chat w successful founders here!), so I'm not saying it can't work, but our experience to get to this point makes me worried for new founders reading the article.
[+] [-] dboreham|2 years ago|reply
[1] https://graphviz.org/
[+] [-] dcow|2 years ago|reply
[+] [-] gadders|2 years ago|reply
- People might criticize my messy/bad/unfinished code
- Hackers will find and exploit security holes
- Competitors will steal my Intellectual Property
I think they are missing a 4th item which is "Amazon/AWS will commercialise and sell a service based on my code and not pay me anything."
[+] [-] kkielhofner|2 years ago|reply
As someone who has created and maintained open source projects (most recently Willow[0]) for two decades I get a kick out of this.
Of course when interacting with users and feedback I keep it polite but in my head I'm thinking "You like to talk. I actually DID this. Shut up or submit a PR".
Surprise surprise they almost never do.
Keep actually producing and shake the haters off!
[0] - https://heywillow.io/
[+] [-] flurdy|2 years ago|reply
[+] [-] cuuupid|2 years ago|reply
USG has so many programs (eg NSF grants) for tech and the disjointedness of civil agencies, IC, and state govts means they end up procuring a dramatically large landscape of software. The regulatory and compliance bar to entry is not nearly as high as you think especially if you are teaming your first few contracts. It is solid, guaranteed revenue to fund your project for usually 3-5 year commitments, and usually massively profitable.
I wish more open source companies took advantage of this, because usually fully private sector companies will end up baking open source libraries into their project and sell it at gigantic markups, pocketing everything. eg: https://x.com/ssankar/status/1749202248700420587?s=20
When I was in govt I saw so much software that was basically open source maps + open source db for $12m. To give another frame of reference, I’ve seen OCR on PDFs carry a $2mm price tag, and a tool like weights & biases carry $30mm (all $ per annum).
There are even other incentives here beyond deploying software; for example prioritizing fixing certain bugs or security flaws in your software — eg IC would have paid big $$ for safetensors.
I’ll even highlight four ways Supabase could do this: - Cybercom (direct) - DOS (direct or teaming) - VA (thru a PWS) - direct to govcon software powerhouses
And three ways to do this: - cold email GS 14s/15s or equivalent - hire an ex-GS15 - find a solicitation that fits on SAM.gov then use GovPro.ai (white glove) or rogue (diy) to put together a response
[+] [-] huijzer|2 years ago|reply
From what I've seen, governments and startups typically don't go well together. By the time the government bureaucracy has finally approved the contract, most startups would already have been out of money.
[+] [-] 7thaccount|2 years ago|reply
[+] [-] codingdave|2 years ago|reply
If you want to get into the public sector, think small and wide, not all-in on the biggest one.
[+] [-] thomastjeffery|2 years ago|reply
The most lucrative sector of government (in the world) is the US Department of Defense.
Not only are they incredibly bureaucratic and schedule-sensitive, they are obsessed with secrets.
[+] [-] android521|2 years ago|reply
[+] [-] aljgz|2 years ago|reply
[+] [-] paulgb|2 years ago|reply
My company has had people straight up tell us that they are comfortable using our managed service for that reason.
[+] [-] lucideer|2 years ago|reply
Unless you're implying that Supabase are for some reason deliberately releasing separate defective software to the open source community... to... convince users that using their commercial services is a good reliable option??? I can't really figure out how or why any business would go to the effort of doing this. It seems patently easier to be a legit open source company.
Assuming you're not implying the above & I've just misinterpreted... everything else in your comment paints Supabase in an eminently positive light.
[+] [-] tuyiown|2 years ago|reply
Maybe it's not viable for commercial purpose, but status quo hurt open source software hard by a strong erosion of what to expect of it, without clear long term benefits for companies choosing such a scheme.
[+] [-] k__|2 years ago|reply
It also allows developers to look at the code that's actually running, even if they don't run it themselves.
[+] [-] codeptualize|2 years ago|reply
The open source part, especially it being Postgres, makes it possible for me to move away if I choose to do so, while picking and choosing the parts I want to keep. This ability was crucial for me, I would not have used Supabase otherwise.
If you look at Firebase for example, there are countless stories of how difficult it is to move away.
Even if I won't self host Supabase, I can just take my schema, take my data, and put it elsewhere fairly easily as all the postgres extensions and everything is open source. I have the ability to move away from Supabase completely, and people have done this successfully before (see https://news.ycombinator.com/item?id=36004925).
Some people do actually self host btw, and supabase is adding more options like hosting on Fly.io.
Besides this there are other advantages:
- I run Supabase locally for testing (using their docker images and CLI)
- We run Supabase in GH actions for automated testing and migrations
- I connect directly to the db, and use postgres tools for various things, backups, snapshots, db admin tasks.
- There are community clients for many different languages
Sure, it's also marketing, as these are all great benefits that really had a big impact on my decision to build on Supabase. Open source is more than just self hosting.
[+] [-] portaouflop|2 years ago|reply
[+] [-] the_mitsuhiko|2 years ago|reply
A lot of products we all use underwent complex business changes, but the Open Source ones still are here for us to use. MySQL had a tumultuous past and yet there is a very active version of it hanging around under a new business.
The marketing angle is for the company to leverage, but the open source nature of it is for the user.
[+] [-] speedgoose|2 years ago|reply
It’s appreciated since SaaS on AWS wasn’t a possibility.
[+] [-] XCSme|2 years ago|reply
[+] [-] yadascript|2 years ago|reply
[+] [-] archibaldJ|2 years ago|reply
Realistically, it feels like the actual utility of an open-source project is based on:
1. it being educational: so everyone can look into its source & learn from its design pattern, etc, or build upon or borrow parts (eg to be modified) and to be used in their own projects - but the practicality of it will really depend on how decoupled and well-designed the system is
2. in favour of competition (so more possible start-ups / big corps can clone their systems/services) and as consumers we will obviously benefit from that
3. llm can access & train on its source code
I think point 3 is most interesting. And I’m also super curious how true point 2 is and to what extend
Point 1 is really cool too - esp when it is done wonderfully (Linux, React for example) but it really depends on so many levels
[+] [-] suslik|2 years ago|reply
[+] [-] kordlessagain|2 years ago|reply
[+] [-] rizky05|2 years ago|reply
[deleted]
[+] [-] martypitt|2 years ago|reply
However this comment feels off:
> In software ideas are cheap. Value is almost always created in execution of ideas.
I've heard this phrase around things like "I have this cool idea for a startup - will you sign my NDA before I tell you about it?"
However, when you're open sourcing your software, you're not just providing an idea, but a significant portion of execution of that idea too.
Sure, code isn't the full execution - that expands to sales / marketing / support / etc.
However, the article is a little glib towards the value of the code, suggesting it's worthless without sales / marketing /etc. I don't think that's true.
[+] [-] codegeek|2 years ago|reply
Code is not worthless but it almost is without sales/marketing/talking to customers. If I could split the value, it would be 90% sales/marketing/customer validation and 10% code. I run a low 7 figure bootstrapped SAAS (not open source) and I can tell you that code is mostly shit anyway and keeps evolving.
[+] [-] Towaway69|2 years ago|reply
The process of creating the code and solving all those little unseen problems is for what developers are paid.
Hence selling software is so profitable. If you don't sell software, you won't make money with it. Software is not like a physical object in a our shared reality.
[+] [-] zurfer|2 years ago|reply
The quoted and beloved open source projects are not good businesses: PostgreSQL, Python, Bitcoin, React
Mongo and Elastic are great, but exceptions. There are more successful closed source database companies than open source ones.
Open source companies are hard. However, they are super valuable for users.
[+] [-] CaptArmchair|2 years ago|reply
Barring a discussion about whether or not a license is "open source", what matters is that these businesses asserted that commonly used licenses - (A)GPL, Apache, MIT,... - are leaving ample room for competitors to setup their own managed / hosted services and compete with them through scale (e.g. Amazon's Open Search offering undercutting ElasticSearch).
[1] https://blog.opensource.org/the-sspl-is-not-an-open-source-l...
[+] [-] freeopinion|2 years ago|reply
But for me, answering the question as asked provides the path to answering the question as reworded. To me, the question as asked is about the nature of the software the company uses, not sells.
I personally will always choose an open source product over the alternative, even if I happily pay for support or just donate to support the project. Unfettered access to the source is fundamental to me, even for software I never intend to alter.
I know this seems to many like an extremist position. But I don't like the idea that I am not allowed to tear down my microwave or doorknob or transmission. I might never be able to put them back together in working order. Or I might be able to find a gear with a missing tooth and execute a $2 repair instead of a $90 replacement. Or I might invent a new frakenstein microwave with a tranmission.
Extending the featureset of a web server or understanding why my plugin is crashing the host app, etc. are important to me. I think they are important to society. So I hold on to my open source extremism. If you show me the hottest new tiny web server that can do HTTPS/4 with built-in AI in just 5Kb, I will be intrigued, but if it isn't open source, I'll stick with my current stack.
With this mindset, the software I produce is open source. And sometimes people pay me for it.
[+] [-] hobofan|2 years ago|reply
From my experience, for procurement people all of that (brand, community, team, DX) will matter close to 0 in comparison to compliance, etc, if you are going head-to-head with an existing supplier like Google.
[+] [-] awalias|2 years ago|reply
[+] [-] anonzzzies|2 years ago|reply
It would be interesting to hear a story like this from a project of similar size that has $0 funding, has been founded in the last 5 years, has a fulltime team >1 and exists for 3+ years and still would recommend this approach. How are they making ends meet? Things like Redis simply don't happen anymore. At least; I haven't seen any. Hell, even trivial projects, like langchain, get in 10s of millions of VC and those would be my candidates for actually being able to do it as a few-man-band while getting in money via different sources.
[+] [-] sneak|2 years ago|reply
All of my software is released as public domain (free software) and none of it is a successful open source project or community. Free software is first and foremost an ideology, and a practice or feature second.
[+] [-] myaccountonhn|2 years ago|reply
[+] [-] satvikpendem|2 years ago|reply
[+] [-] lamontcg|2 years ago|reply
[+] [-] mindwok|2 years ago|reply
[+] [-] brabel|2 years ago|reply
[+] [-] didgetmaster|2 years ago|reply
It wouldn't even take a tech giant like FAANG to outdo your project after forking your source. A medium-sized company could throw a dozen programmers on the project and their fork would surge ahead of the original with respect to features, support, and distribution. They could out-market you as well.
[+] [-] wouldbecouldbe|2 years ago|reply
In most places in life this is valid, but in the developer community I disagree. Developers love talking shit about each others code.
Still yearly ritual here to bash the "Clean code" book.
[+] [-] kevingadd|2 years ago|reply
On the other hand if your product isn't good enough then the decision doesn't matter since it won't take off either way. :)
[+] [-] dudeinjapan|2 years ago|reply
[+] [-] brap|2 years ago|reply
Your users can just host their own version instead of paying you.
It seems like many OSS companies mitigate this by leaving out features from the OSS version or making the deployment more difficult than it should be. I’m not complaining, I think it’s fair, but this is the reality.
It’s funny how they don’t address this one, but instead they list “oh no my code isn’t pretty” as a valid complaint against going OSS. Who cares.
[+] [-] astro-|2 years ago|reply
Would it make sense for Meta to open the codebase for facebook.com? Aside from studying/scrutinising the code, the only other thing you'd be able to do with it is to change the logo and try to compete with Facebook.
In this example, it's still probably not enough to disrupt them thanks to the social graph and infrastructure complexity. But you could imagine moments where even Meta gets nervous when anyone can start competing with feature parity from day one.
Over the long-term, it's more likely that Meta would want to keep some features private. It's also less likely that they would get lots of quality contributions back. If you're running a fb.com clone in production, you're likely trying to compete with them on some level. This leads to a weird relationship with the community and limited value for both sides.
[+] [-] imiric|2 years ago|reply
Don't do this. The OSS product needs to be as featureful as your commercial product. It's fine to offer some commercial value added features and services that would only be useful for enterprise customers, but these shouldn't be core features of the product. You can have priority support for your paying customers, but don't leave OSS users with "community support" only. At the end of the day, the company does need to make money to survive, but treat all your users with the same respect. If the product is good enough and solves a genuine problem, you won't have difficulties monetizing.
[+] [-] hoc|2 years ago|reply
So a bit of the right words to the matching user base and with good points. Just that you always need to draw your own conclusion from your unique position.
Kudos for the the nicely adapted Jurassic Park scene.