>When we discuss open source business models with other founders, there are three complaints that come up again and again. These are:
- 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."
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.
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.
They might not release a separate version for OSS, but I've seen this pattern in some "OSS" companies. They allow the OSS version to lag behind in terms on bug fixes and security updates. Some things are hard to achieve without paid support. These days it's not unbelievable that they are doing it on purpose. After all, we've seen some vocal OSS companies go proprietary after gaining some traction. The lesson is that you absolutely cannot trust corporations to uphold OSS ethos once they get a reasonable amount of traction.
The lesson is that you absolutely cannot trust corporations to uphold OSS ethos
I'm absolutely with you here but I think this is a matter of least worst situations: I still think an OSS corporation trumps a non-OSS corporation regardless.
These days it's not unbelievable that they are doing it on purpose.
I think there's a bit of a leap between a company - at a management level - deciding to "go open-source" for mainly marketing/branding/image reasons & that same company actively endeavoring to make their open-source product deliberately worse.
It's still likely (& common) that profit incentive will lead to paid plans receiving more investment & QA than open-source offerings. But again, this is a least worst outcome imo. A semi-abandoned corporate OSS project isn't very different from a semi-abandoned personal individual OSS project - maybe even better as there will typically be less social reluctance to build a community fork.
Thought experiment: You sell a hosted solution and also release your software as open source.
Daily, you are bombarded with decisions for how to allocate resources. In each of those, do you lean towards the option that makes it easier to self host rather than spending those resources on other things?
This is exactly my point.
There are systemic reasons for these systems to be underresourced - there's absolutely no need for theories about deliberately crippling OSS offerings.
Open source isn't just about self hosting.
It also allows developers to look at the code that's actually running, even if they don't run it themselves.
To me looking at the code doesn't do much if I can't patch it
Considering the state of the average docs, I usually prefer code.
Right, but even if I have the source code but can't patch the version that I'm running, that's not very useful to me.
It allows you to look at some code, if that's the one that's running or not is a different story.
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.
I disagree: just because something is open source doesn’t not imply the authors have any duty to also provide packaging and distribution as well.
Distribution is an orthogonal concern. The fact that many existing things are nicely distributed is a pleasant bonus, not a necessary condition.
open source doesn’t not imply the authors have any duty to also provide packaging and distribution as well
If the authors are using open source as a selling point and marketing relay for broad audiences, I think there is a moral obligation to.
For projects with little awareness, niche, or "just a hobby, won't be big and professional", yes sure, I would never think to have any opinion, nor bothering them.
Officially, it's open source as long as "the code is released under a license in which the copyright holder grants users the rights to use, study, change, and distribute the software and its source code to anyone and for any purpose".
good points.
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
What do LLM’s have to do with code licences, and since when has the utility of code depended upon an LLM instead of, you know, its own utility?
What he is saying is that LLM’s released into the wild to train can anonymously steal from his code to improve their own utility outside of licensing boundaries.
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.
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 heard good things about self-hosting it through elest.io.
I used one of their open source work in a project: https://github.com/supabase/wrappers
It’s appreciated since SaaS on AWS wasn’t a possibility.
I know people who are running Supbase in production for Enterprise customers so that claim is just false.
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.
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 think you are missing the point.
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.
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.
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.
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”?
Fair question! A good chunk would cancel, and at a minimum, switching to free sw / paid support would drop our product-related revenue by ~70-80%.
Then again, we could make the software worse to trigger higher support hours, as complained by others in the thread about some OSS companies. Or really lean into it, going to full-blown consulting. However, switching to a consulting business has all sorts of negative externalities that can easily destroy the strengths and joys of a product culture. We actually do provide a growing side of professional services and roadmap acceleration for Graphistry & louie.ai (graph viz, graph AI, genAI, for data-intensive operational / investigative scenarios). By having our product licensing revenue the majority, we get to make sure there is stronger positive mutual alignment between us and our users, and our software and their long-term mission.
As another natural experiment, I was interviewing someone from a company in the same space a few days ago that doesn't have this discipline. While our company is younger, our tech roadmap has been literally years ahead every year, and the software they deliver has no real upgrade path.. alignment helps when you care about your craft and customers. (And for HN'ers, it's a 5X+ on valuation multiple.)
A deeper question would be to examine if your product mindshare would grow significantly if your product were open source, and if this growth would lead to a combination kf the following that would overcome the loss is subscribers: 1) Contributions from the community (bug reports, code, promotion, documentation, and feedback are all valuable contributions, but they take work to leverage, and some companies choose not to put in the work). 2) More users means more potential subscribers to the cloud and support licenses. (What percent of these new users would convert to paid support licenses or cloud hosting customers?). 3) Other new ways to garner financial support from the community? (Patronage, paid feature development, ???).
I agree with those perspectives, they're questions we talk about and analyze:
- We do in fact operate multiple OSS repos. Despite their usage, most, as with most OSS in general, do not get significant code-based contributions. Our proprietary repos are even more complicated (e.g., distributed GPU code, webgl shaders, and "boring" enterprise bits), where we'd expect even less involvement. Instead, they see other values from the OSS community like easier bug reporting and, as you say, easier for folks to see if the tool is for them. Writeups like Supabases misses this nuance in practice, focusing just on the rarer lottery ticket scenario. (Which is natural to come from a marketing / devrel person that got hired after-the-fact: selection bias in action.)
- Our customers do pay for feature development even without the OSS
Most of all, as you say, maybe marketshare can grow! But in my original point, now that's counting on lightning to strike twice, once for OSS and then again for the company. That's a very big decision when many people's lives -- and their families -- are making bets here. We're actually reexamining the economics of this question now that much more is known and we have more stability. Much trickier than the blogpost makes out!
Yeah, I don't expect a really nuanced blog post from a marketing department...
For your open source repos, how much effort is put into inviting contributions and making it easy to contribute? Growing an open source community is a lot of work, and is a skillset apart from (but not always exclusive of) software development and business development. Many projects don't try, or don't do a good job of it. Some projects (may e most famously SQLite) openly state that they have no interest in outside contributions. (Its a legitimate choice, but the consequences are obvious).
We experimented with this:
Typically we get nice small contributions from devrel teams around connectors in their software, and junior data scientists newer to coding who we encourage to do examples instead of core code
We revisit this every year or two, and are overdue, thanks!
I think a good example of this is the Django Software Foundation. They have a Django Fellow they employ who is responsible for helping guide the community and take care of the bug tracker and other tasks. They maintain a list of begginer friendly tasks. Release notes specifically call out first time contributors and credit them, no matter how small the first contribution may be. These callouts serve as both a thank you/welcome, and a message to the community reminding them that contributions are welcome. Every project is unique,.sounds like you guys are making a serious effort- keep up the good work!
If you said “our source is now available under the AGPL, if you’d like to keep using the software without reverse licensing modifications and your patents you’ll need to remain on your current plan”, how many would walk? Or similar, “our software is open source but still requires a license for commercial use” would 70-80% give you the middle finger and say okay sue us then? Just curious if there is a dual licensing strategy that could work for you.
I mean think about it, the companies you’ve sold the software to have now seen your sources. If they could take the code and do it better themselves and it was just a question of “knowing the secret sauce” then wouldn’t 70-80% of them have done so (if your claim is accurate). There’s something else happening here. They’re paying for your team to maintain the software and provide continual updates. Getting the source code is most likely an implementation detail to the purchaser. Open source doesn't mean free as in free beer. It’s a myth that you can’t charge a company for an open source product.
I think you got a pretty clear answer to that already in the parent answer. Of course, you could keep insisting that open source should work for them.
I’m not asking the same question twice. Read carefully. And the comment I responded to was edited. I’m not insisting anything. A lot of people assume open source means free as in beer and don’t even realize dual licensing is an option.
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 :)
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.
You can go for adoption / mindshare and consulting, or you can go for selling the product. There's very little in between when even the largest expected adopters can only derive little convenience from paying you.
"If the product is good enough and solves a genuine problem, you won't have difficulties monetizing." is wishful thinking. Look at Elastic, MongoDB, RHEL and HashiCorp - all with amazing adoption - having trouble attracting paying customers to pay them over someone else and subsequently having to remove the ability of others to monetize their product.
Look at Elastic, MongoDB, RHEL and HashiCorp - all with amazing adoption - having trouble attracting paying customers to pay them over someone else and subsequently having to remove the ability of others to monetize their product.
Those are still service problems. If you as the author of the project can't build a solid moat around it that entices users to use your commercial service over someone else's, that means you haven't done a good job at it, and others have.
It's a difficult balance to keep OSS users happy, while also making the best commercial offering. Not many companies do this right. I think Grafana has done a solid job of monetizing the open core model. I struggle to think of others, but I'm sure they exist.
EDIT: Another example might be Automattic. I'm not a WordPress user, but AFAIK it has a very healthy open source community, and wordpress.com is _the_ place to use it commercially. Doesn't WP run something like half of all web sites?
I struggle to think of others, but I'm sure they exist.
Do you also struggle to think of businesses who are not OSS but successful? I think the list of non-opensource companies that became big is much, much larger - to the point I think it's fair to say successful OSS companies (from the perspective of making money, at least) are the extreme exception.
That goes without saying. Building a successful company is hard enough. Doing it based on an open source product is even harder. But companies that do this right generate far more good will from their users than companies building strictly closed source products. This is a good thing for users, customers, the company and its shareholders. But for this to work, it's important that the founders believe in open source as something more than just a business strategy.
This is simply not true. There's an initial cost of getting your engineers familiar with a codebase, sure, but that's still substantially less than building and maintaining the damn thing. Someone outside the project maintainers will always have a smaller cost basis for the tradeoff of not controlling what goes into the code (a power you say they shoudn't abuse - and most of the examples I named did, i.e. Terraform Cloud integration) and not being able to say "from the makers of <thing>".
I don't think that's enough, especially if the other company is AWS.
Also, Wordpress has a lot of competitors. Pantheon and Pressable come to mind in the enterprise space, with every commodity webhoster using Plesk for a less managed but very budget experience.
Someone outside the project maintainers will always have a smaller cost basis for the tradeoff of not controlling what goes into the code
How do you figure this? Nobody will know the product, its users and their needs better than the original authors. They have a distinct advantage over any competitor who only offers a commercial wrapper around it. Not to mention that they have full control over the direction of the product, and can at anytime introduce a new feature their commercial service takes advantage of from day one. Their competitors could also fork the OSS product, but it's very likely that the OSS userbase stays with the original authors.
Again, for this to work the authors need to be both great OSS stewards, and great business leaders. Not many companies do this correctly.
I don't think that's enough, especially if the other company is AWS.
By the time AWS takes notice of your product, you should already be quite successful at your own business, in a way that they can't compete. The companies AWS stole lunch from didn't do this properly, and their only recourse was a license change.
a power you say they shoudn't abuse - and most of the examples I named did
Yes, I'm not arguing those companies don't exist. I'm saying that it's not in their best interest to do so, considering how much community backlash can hurt them. You also ignored my two examples of companies which I think do this right, and have successful businesses.
Also, Wordpress has a lot of competitors.
Sure it does. Hooray for open source. https://wordpress.com/hosting/ lists some of them. The goal for the original authors is to offer the _best_ service so that customers will want to choose them over the competition. Or maybe they can focus on a certain slice of the market, and leave others to cover the rest. The pie can be big enough for everyone. This is not unlike any other company. Competition will always exist. But again, the original authors will always have an advantage. Not knowing how to do this properly speaks more about the company than about open source. This isn't impossible, just very difficult.
wordpress has a horrible reputation in software/plugin quality, so you pay someone else to run it for you.
I think mongodb was more of a fad than a product.
The company made over a billion in revenue last year.
How much profit?
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
just sell to the civil government.
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.
This is a myth that’s exaggerated by specific anecdotes around sole-source (which is where you work with the govt and they put out a notice saying they intend to go with you). Because of there not being constraints on time there and them needing to allow others to protest this makes timelines highly random.
Most are not like this, usually the government puts out solicitations (RFI/Q/Ps). They have a set deadline by which they have to answer your questions, a set deadline for bids, and a set deadline (usually 30d) by which they have to select someone.
You can also game this by emailing people around september, which is when they are getting ready to close their budgets. They need to spend any surplus, and I’ve seen many prominent civil agencies (won’t name and shame) throw around $1-2mm on a same-day contract with vague constraints.
At least in a bunch of the defense agencies, books close for new stuff mid-August. The Aug-Oct timeframe is used to finish executing already in-flight stuff. And if you miss the 10/1 deadline, you're waiting at least until Feb (for many reasons...), assuming Congress has passed a budget.
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.
Yep, for most PWS contracts there are base personnel requirements. That being said for research the bar is pretty high, for regular industry it's pretty low:
- experience in the field (or agency-based past performance)
- clearance (usually public trust for civil, which can be as short as 1-2 week turnaround)
- citizen, US based, with data centers/software inside the US
There are stringent requirements for software the higher up you go (esp to DoD & then IC) but requirements most will meet and build towards while still making $$$. You don't need to have 20 TS/SCI engineers who have IAT L2 and IL6 infra with an ATO at the agency to start with (or even know what those words/acronyms mean), but a vertical in govt will naturally enable that over time.
If it's good it's good. There are a lot of reasons it might not be, though.
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.
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 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.
This depends on the product. Sometimes self-hosting is not just a matter of starting some Docker containers, but takes work and resources to scale and maintain properly. It might not even be a matter of the OSS version lacking features, but about the nature of the product itself.
For example, you can self-host WordPress if you want, and it's a perfectly capable product. But if you want to outsource the complexities around it, scale it easily, properly secure it, etc., it's worth considering using wordpress.com instead.
Isn't that a reflection of how bad WordPress is? That they haven't prioritised security and ease of use in the development of the product.
This model definitely leads to some perverse incentives.
No, there are maintenance issues with hosting WordPress that go beyond just the product. You need a domain and TLS cert, storage, bandwidth, a curated list of plugins, and an easy way to scale it all. None of this is core to WordPress itself. I'm not a WP user, but see all the features on https://wordpress.com/features/.
Grafana and its ecosystem of apps are another example. Sure, you technically could host and maintain it yourself, but Grafana Cloud streamlines all of that, which is worth paying for. This doesn't mean that Grafana products are intentionally limited, but that the commercial product offers value added features some users are willing to pay for.
The fact that some companies take advantage of this model doesn't mean that the model itself doesn't work. They're just not good companies to begin with, and don't understand open source.
The optimal architecture for a 1-user self-hosted project is very different than something built to serve 100k people, which is very different from a company serving 10M, and again for 5B.
Do you shard and partition the DB? Do you introduce a message bus? Do you add a caching layer? What about k8s and Terraform and Helm vs simply creating a single VM?
These are all very different levels of complexity to standup and manage. Some require entire teams to manage them.
Regardless of intentions, there’s no “one-size-fits-all” solution to architecture and infrastructure decisions.
Maybe I should have addressed this one more directly in the post.
Your users can just host their own version instead of paying you.
The main value in Supabase (the hosted service) is we do the hosting, maintenance, monitoring, compliance, security etc. which otherwise requires (expensive) in-house expertise.
This should be enough without needing to resort to deliberately leaving out features, and I think this generalizes to other products as well (sentry, plausible, the-open-source-strava-alternative, etc.)
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.
This sentence goes well with the one at the end of that paragraph:
Toxic community members who complain about bad code instead of making suggestions to improve it are not the people you want in your community anyway.
If someone finds your code and goes out of their way just to shit on it, they can get fucked. I'd be handing out blocks for that.
Not true. When I happen to having to fix stuff or have to decode insane json, I curse other developers.
The article then also contradicts itself slightly with that for hiring look at their previous public contributions.
However, I get their point for both cases. Looking at contributions gives a glimpse of that person. However with a grain of salt.
And the imposter syndrome is strong in public contributions. I get it, and agree with the article, don't worry.
I am working with a gov client at the moment so back to coding in the open again, and it is great. I am not worried that my quick one-line comment on a PR for a tiny repo is now public. Or pushed typos. It happens.
No unless you like, giving away the goose that lays the golden egg. How successful would Coca-Cola be today if they open sourced their company?
The recipe for Coca-Cola is publicly available and is not legally protected or exclusive in any way. Many people make extremely similar cola beverages. Their business value is in brand and marketing, not any exclusive method of producing the product.
You have inadvertently chosen a perfect example of why free software is better than proprietary software.
It’s called a trade secret it is not publicly open. It’s one of the best kept secrets of all time. What the hell are you talking about?
This is urban legend, just like the KFC “herbs and spices”. GC/MS is a thing. The recipe for Coke is literally published on wikipedia:
https://en.wikipedia.org/wiki/Coca-Cola_formula
The specifics of the Teller-Ulam design is one of the best kept secrets of all time. It’s impossible to keep secret the list of ingredients in a thing you literally provide for sale to any member of the general public.
Don’t eat the pasta.
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. :)
Try not to be Jeffed
AGPL?
(2022)
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.
Absolutely agree and I do with my own code, but I need to eat and haven't managed to do that from open source. So yeah, that's why we pledge to open in a set time or set revenue stream, but I am not rich enough to just work for nothing in the meanwhile. That doesn't mean that I don't open most things I do in private.
Edit: forgot 'don't'
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.
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.
Open Source is not a business model.
Open Source is a licensing and development model.
Open Source is a licensing and development model.
With traits of a religion.
All of software development has those traits. Arguably everything humans do is like that.
I've actually been thinking this a bit for one of my products.
I'm thinking: I will give it a closed source grace period, then, by that time, it should either be:
1. A dud, so close the offering, show the source.
2. Working well, in which I can open-source and rely on brand recognition to carry forward the business.
Releasing as AGPL3 at least means that I get some code contribution back, (right? Right?!)
Free software is a gift. You shouldn’t give it expecting anything back.
Life is also a gift.
Free software is a gift from anonymous folks. A gift from a friend can come with moral obligations - depending on your cultural background.
Yeah yeah. Haven't we already seen this going on again and again. Companies love OSS until they get some amount of traction in the market. And they'll jump ship to being a proprietary vendor right away after that. Can't believe people fall for this shit all the time.
Being opensource helps finding bugs in something you rely on if it does not go away fast enough. Sometimes I had success with this, although not ideal, one more option.
Even if for profit and all
Companies exist for profit. If open sourcing helps them getting to a point where they will make more profit, they will open source. If later going proprietary helps them make more profit, they will, too.
Still what they released as open source stays open source, so it's still a win. Also if contributors don't sign a CLA, then it makes it harder for the company to go proprietary. To me that's the only thing: contributors should not sign a CLA: either contributors keep their copyright, or they should not contribute for free.
For me the main question is not, is the code good enough or will competitors copy, but how can we make enough money to build a sustainable business?
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.
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).
[1] https://blog.opensource.org/the-sspl-is-not-an-open-source-l...
Are there many success stories for open source targeted at end-users? E.g. imagine if Photoshop is open source, would Adobe be financially successful?
No?
I mean Supabase was initially a glue layer on top of existing open-source tools, not sure if they could’ve kept it closed source even if they wanted (though I guess most of the licenses of the stuff they used would allow it).
This is true! Supabase db after all is "just" Postgres. In fact it's one of our product principles to adopt existing open source projects before writing our own.
You're also correct on the second bit, everything in the stack is MIT, apache2, postgres licensed so it would have been ok to run a closed fork if we'd have been that way inclined.
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.
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.
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.
It would be interesting to see examples where this scenario played out.
Any thoughts on (F)OSS models for IoT?
We’ve usually got some hardware and firmware closely bound together, with traditional model being selling hardware with proprietary firmware.
Any examples?
What FlowFuse[0] does is market Node-RED[1] as the Open Source offering, obtaining contributions for various devices from the community and incorporate those into their commerical offering.
IoT has the problem that many devices but few users per device. So who is going to make the effect to build an integration for third-party software? The FlowFuse model is to allow the community to do that while they (indirectly) upsell that work.
FlowFuse also provides the SaaS solution for commerical gains.
This seems to work fine for Temporalio.
Does it provide more value for your business than it distracts from your business? That's a difficult calculation. Personally, I love open source, but I wouldn't open source a business unless I needed to.
I think the distinguishing question is, "Is the company's software a tool used to fulfill the company's goals, or is the software itself the goal of the company?"
If your answer is the latter, then you have more problems in store than open-source viability. You aren't genuinely testing/dogfooding your product. Your product goals will trend away from real customer value and toward implementation convenience, self-compatibility, 3rd-party incompatibility, and a closed-minded product vision. The only way to keep this business model viable is to monopolize your market. But will it be you monopolizing, or will it be FAANG?
open source is not enough anymore... humanity needs "lean open source"... and stable in time.
I think many companies probably don't like to be open source because
- they like the idea of "security through obscurity". Open source means more work patching found vulnerabilities, so they rather not publish their code and instead tick check-lists for compliance and do blackbox pentests which makes them look secure.
- like to do marketing that exaggerates the innovation of their product. That's difficult to do if everyone can see the code.
What about for desktop apps? Are there good examples of this? Unless you can offer some cloud/online/support service to go with it, there'd be no reason for most to pay?
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.
No
If you are interested in learning about open-source marketing, check: https://gitroom.com/blog
Really like the pointer to the well known security. First time I actually saw anyone mention it on something popular.
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.
Just kicked off a project to explore open-sourcing what we've built (VC funded). I'm considering a different tack which I think may be interesting.
We have a lot of client libraries, already open sourced. Then we have the hosted APIs and DB which are not open. Making all the close-source stuff open, feels like a big effort, with an unclear reward and more likely that we just end up with a hard to install OS project, since it feels like the hosting expertise _is_ part of the core value prop.
What I'm excited about though is whether we could take the hosted piece out of the equation and find something that is pretty different, but has its own niche. For us this would be replacing the web UI and DB hosting of the paid product, with a CLI and simpler git based hosting for an open source version.
ie If you want hosted feature flags, we think you should use the hosted thing, but if you want gitops style feature flags (100% reliable), then use the OS version.
I like the idea that we could really focus on making the open version great in its niche, but have a super clear line about what is paid / hosted, to help us avoid the complexity of always needing to decide how to nerf the OS version.
The author is clearly a utopist, advertising and trying to promote his own oss views. However, while oss has its growing niche it's clear that it isn't for everyone. The thing to ask yourself before going oss path is what are you gaining by going oss and what are you trading for that gain. For supabase it's clearly beneficial to be oss, they are a niche database, and by going oss they can benefit a lot from integrations, not to mention they are basically ripping off the evil firebase. So by going oss they are perceived as heroes. On top of that who would use another closed firebase that isn't from google? They can't compete on pricing, nor the scale. I think supabase were even advertised as open source firbase at some point.
However if you are not ripping off some popular commercial tool and making it open source, and making open source as your main differentiator, in that case there is very little to gain by going oss. You might as well get most of authors advertised "oss benefits" by just having great developer experience and docs, while giving very little in return.
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.
In this case the ends drive the means. "Should I open source my company" is a decision like "should we write our code in C++?"
Without starting a flame war there are good and bad reasons to choose an implementation language and they should be driven by your business needs, whatever they are.
The same is true for how you plan to license your code and what business model you build around it.
Well, Microsoft invented the "sale of proprietary software as a license to end-users" model. Red Hat, on the other hand, offers value-added services on top of open-source software. It's easy to compare their relative market valuations.
I understand you can give 1000's of reasons why it's fine. But it's still IMHO a sad reality that a giant cooperation cannot play it fair by being a corporate sponsor of the open source projects that they more or less wish to directly use as a service...
I get that legally this is fine but ... Common... adapting FOSS for your own use cases in your basement or little company is still very different then a giant cooperation outcompeting you before you ever had a change...
There might be room for a license to make FOSS software more like BSL if used by a company above a certain revenue threshold or w/e... Perhaps legally that's impossible, otherwise I have no idea why such a template does not exist yet.
I'm not sure if an MIT license is sustainable long term. I see most open source companies adapt AGPL, open core or source available licenses.
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.
Pro tip: Name your company "Open___" then don't open source it.
On the topic of open sourcing your core business, founders often worry that a competitor is going to take their source code, fork it, and directly compete with them. But, is there an actual example of this happening for real and the fork winning out and killing the incumbent in the market? I mean there’s a fork of Signal that doesn’t require a phone number (which is Signal’s heinous transgression if you poll HN) and we’re all still using Signal. And all you have to do to prevent bigcorp taking your stuff is slap the [A]GPL on it for “free users” (while still allowing others to purchase the source code under a more permissive license should they require it).
OSS is a thing you buy, not a thing you sell.
`And not one of them were ever required to solve a LeetCode problem over Zoom.`
I can see some motivated developers benefit from this. But now those devs are working on someone's "open sourced" company for free thus growing someone's company in exchange for employability elsewhere. I can't shake of the feeling of borderline exploitation when I see the phrases 'my company" and "open source" next to each other.
We are building some educational video games and considering starting a company to help sustain the effort. If possible, it would be great to publish the source code and game assets as free/open software and free cultural works. However, I’m not sure about a business model to fund continuous research and development. Is anyone here working on or aware of any open source game studios with sustainable funding/revenue? Any other advice or consideration about licensing and business models? Thanks in advance :-)
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.
Once your project reaches significant scale, you might find yourself in a situation like Elastic, or Mongo, where large cloud providers are offering your product with a superior distribution model.
Secondly, and more constructively, you should prepare for this eventuality by finding areas where you can outcompete anyone. Most cloud providers are notoriously bad at Developer Experience for example, so take advantage of that and make DX one of your core competencies. 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. Make sure you're not blindsided by something like this by planning for it from the beginning. You have enough time and focus on your side to construct a winning strategy.
Consider Google Firebase, which runs on Google Cloud and can access services from Google Cloud[1], but has a separate frontend, focused on DX rather then features, and imagine Amazon Supabase.
i think the biggest moat OSS companies have is production-grade infrastructure hosting.
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.
I would suggest (and I've run zero companies and I'm just going by what I read on here) that if you want to open source your project, from the start pick a license so that big cloud companies can't commercialise your product for free.
People seem to get really salty when companies change their license further down the line to prevent this.
Those licenses aren’t open source.
People get salty because those license changes are from open source to source available (like the BSL).
Some of us (myself included) even consider licenses like the AGPL to be nonfree.
Free software can be used for any purpose, including competing with the original authors. If you can’t do whatever you want with the software, it’s not free software.
If you want to open source your software but you want to put restrictions on what people can do with it, then, well, you don’t want to open source your software (and IMO the free software community would be better off without your free software cosplay).
But as a commercial consumer, I still value source available offerings quite a lot. I can debug my own issues with them, I can see how well they're built and I know thousands of eyes are looking at them.
Depending on the software, I agree it's not as good for me as free software, but it's not worthless.
It’s not worthless, but I try to avoid supporting proprietary software companies.
Being selfish isn’t a good look, especially when starting out as free software (Docker Desktop, I’m looking at you).
I even strongly dislike actual free software releases with companies that have proprietary stuff alongside (so-called open core). It means that the people doing it don’t give a shit about software freedoms, otherwise they’d never consider releasing nonfree software. Mattermost is in this category (and further demonstrates their disdain for software freedoms by shipping nonconsensual spyware in their foss stuff and closing PRs that remove it).
It’s really shady to position yourself as an open source company and then release any proprietary software.
Do you carry this philosophy through to your professional life? As in, do you only work for companies that produce open source software? If so it's an admirable stance, and I hope you're successful.
I imagine it's tricky (or at least unstable) to earn ones living working only for entirely open source companies, but maybe there are more opportunities out there than I'd realized.
It’s not strictly absolute (I still use and even occasionally buy proprietary software) but yes, generally speaking, I either only work for companies that release free software, or strongly advocate for my clients to build and release only free software. I’ve convinced (or been part of the process that convinced) several projects to release free software that otherwise would not, including some famous ones that have been on the frontpage of HN recently.
I am personally responsible for at least 3-4 startups never making/releasing anything but open source stuff. I advocate for the basic idea of software freedom in all contexts.
Usually “business guys” try to interfere, but it’s almost always from the misguided idea that the code is somehow valuable. People get this weird idea that their source is worth money (it never is). Most companies are valuable because of their ability to execute, not their code (which is rarely reusable outside their org anyway, and even if it is, not in their market).
Think about it: if your code were valuable, how is it that a few people were able to make it from scratch in a few months? It’s obviously your staff who are valuable, not the code (which someone else could also make from scratch for low cost if they needed to, just like you did).
It’s the same misguided emotion that makes people think startup ideas are inherently valuable. It’s the ability to execute, not your so-called “intellectual property” that is where the value is.
That's quite thought provoking!
I don't agree with you on that code isn't valuable – it varies by product complexity, essentiality of the software as part of the business, etc. – but in of itself is the distillation of solved problems, which generally takes years (not months) to work out.
Still, I appreciate you taking the time to break it down, and it's something I'll think about.
I can’t speak for everyone, but I’m at a point in my career where I can be a bit more picky about the jobs I take.
I’m currently looking for a new SWE position and I prefer places that have active open source projects.
I’d take less pay to work at somewhere that maintains and releases free software.
Are you free to work for me... For free? :-)
They clearly meant free as in press, not costless.
I think they were conflating both notions. But alas...
I'm confused how someone would generally consider the AGPL to be non-free, but still perceive the GPL as a free license.
In either case you don't have to pay for the software, can modify it however you'd like, and run it wherever you want. You just have to share the modified source code.
If anything, the AGPL is the modern incarnation of the ideals of the GPL. If SaaS business had been a big thing in 1989 I'm sure the original GPL would have contained wording similar to the AGPL. It's just that back then nobody though of people hosting software as a threat to the free flow of software improvements.
Not clear.
Stallman already carved out exceptions for "appliances" that had computer chips, like microwaves. Stalllman wanted is own general purpose computer to be libre, not freedom to control other people computers (Cloud).
So, I think yours is a reasonable position. I hear it and integrate it into my thinking.
I have two thoughts on what you bring up, the first is a story I remember about Stallman being really frustrated with firmware on a printer (not drivers on a “general computing” device). I think reading this story[0] should be reasonably self-explanatory and not require additional exposition or warrant in this HN thread.
My other thought is that increasingly, our “general computing” applications are moving to web apps / cloud apps, and not stored on our devices. So while you may be correct about RMS, and maybe he wouldn’t have cared today about the concerns AGPL addresses, I personally wonder that he would, and think its at least reasonable for many people to generalize his FSF philosophy to cover general computing experiences that aren’t hosted locally but are still part of the primary computing interface that we use to interact with our current general computing devices.
0: https://www.fsf.org/blogs/community/201cthe-printer-story201...
This entirely
Free software theoretically is against EULAs and about empowerment of end users.
AGPL is an EULA that is additionally really badly written, especially compared to clarity of GPLv2-only.
The AGPL is the GPLv3 with only the addition/modification of section 13. Outside of section 13, there are only 5 words changed in the rest of the terms of the license and those 5 changes are the introduction of the word 'Affero' between 'GNU' and 'General Public License'.
Section 13 only states that someone/something interacting over a network is considered a user (and that you can combine GPLv3 and AGPLv3 works). That is the only change compared to GPLv3. It does not otherwise change what rights the user has or what is considered a corresponding source (i.e. what the licensed work contaminates). Those are word for word identical between the GPLv3 and the AGPLv3.
If you have an issue with what rights/restrictions the AGPLv3 provides a user of the software, that issue is with the GPLv3, not the AGPLv3.
I'm not sure why the downvotes.
Yes, the AGPL was essentially intended to plug the SaaS (maybe it was still being called application service providers at the time) loophole seen by some whereby delivering a network service wasn't considered distribution--and therefore didn't trigger copyleft provisions--with the GPL (either v2 or v3).
A lot of work went into GPLv3 and a lot of legal niceties were added as well as the watered-down TiVoization language but really isn't a lot of practical difference between GPLv2 and v3.
As a private person and startup founder the things I value about open source from a practical perspective are
- being able to just read the source to figure out what's going on
- being able to fix bugs
- being able to add features I need
- being able to upstream those changes so others can profit and help maintain them
- being able to self-host the software
Open Source ticks all those boxes, whether it's on the "laissez-faire" end of the spectrum (BSD) or the "Stallman" side of the spectrum (AGPL). (though the more "Stallman" a license is the fewer situations where I can use it). But the BSL also ticks all those boxes. I get it's not as ideologically pure, but it still meets most of the ideals of the original open source/libre software movements.
BSL doesn't necessarily allow you to self host. Without additional grants, it doesn't allow production usage until the license converts.
If I make a paid twitter clone using a BSL-licensed database under the hood, I'm allowed to self-host the database for this purpose, in both production and dev environments.
What the BSL prevents me from doing is offering paid hosting for others, or offering a product that competes with it (e.g. if postgres would be BSL, supabase couldn't use postgres under the hood since the products kind of compete with each other).
You can't use BSL software in production without an additional usage grant:
https://mariadb.com/bsl-faq-adopting/
In practice are there any BSL adopters that don't give a usage grant for production use? All those I've encountered only forbid stuff like hosting to compete with the original software creator, not actually using it in production.
It may not be common, but I did find these (fairly popular projects) which don't appear to allow production usage: https://github.com/fingerprintjs/fingerprintjs/blob/master/L... https://github.com/exaloop/codon/blob/develop/LICENSE
Here are some others: https://github.com/search?q=%22Business+Source+License%22+%2...
You are right for the pure BSL. I was misremembering because e.g. Hashicorp just give a blanket Additional Use Grant for production use that doesn't compete with the licensed product [1]. MariaDB is a lot less generous, e.g. restricting you to less than three production servers for MaxScale.
So the ability to self-host BSL code depends a lot on the chosen Additional Use Grant. I don't mind Hashicorp's, but the one publicly offered by MariaDB is pretty restricting.
1: https://www.hashicorp.com/bsl
To me AGPL is still very open, but it sure limits stuff. Gotta be even more careful with it in an enterprise setting than GPL. Can deploy it internally, but must be internally and it’s a constant risk.
I haven’t found a reason to deploy one yet. One use case I have seen is to have some sort of commercial/AGPL double distribution, perhaps with the AGPL release lagging behind.
Sorry, so I must have misunderstood AGPL then? Assuming a well written software, your configuration values can still be secret, right? As long as you give all your users the source code you got and the changes you made to the code (not the configuration), you should be ok? It is crazy to expect someone to ask for things like your database password or your exact configuration like sync intervals.
No you are right. I just meant that if you deploy a GPL service internally and the service somehow makes its way outside the organization, you don’t have to distribute the source code or anything.
But with AGPL, you now have to. Ensuring compliance is costlier.
Why is compliance costlier? There are companies that don't comply with GPLv2 for months and there is no cost as far as I can tell
previously on HN, https://news.ycombinator.com/item?id=31713525
Compliance is costlier if you actually spend resources trying to comply. What you are referring to is the cost of non-compliance.
Maybe the joke swoshed by me. :)
That's like saying a free society can only be free when individuals are free to do anything they want including harming/limiting freedoms of other individuals. Well, no, most free society limits your freedom to harm other people or bans you from limiting other people's freedom. The AGPL prohibits you from limiting other people's freedom.
Which definition of free do you use?
You may have valid criticism against AGPL but non-free isn't one. It's free according to the free software definitions and the open source definition. It's recognized as free by the two organisms providing relevant definition (OSI and GNU) and by all the relevant actors, including Linux distributions and even big proprietary companies (including GitHub).
I think you are misunderstanding the meaning of "for any purpose". It only applies to what you do with it when you run it. It does not mean you can do anything you want with the source code. It is very important to understand this aspect correctly when developing software or for a free software / open source enthusiast.
AGPL is absolutely free software as long as the GPL is considered free software and should not be put into comparison with licenses like the BSL.
The only real limitation on the AGPL compared to the GPL is section 13 which states that you need to make the sources for said AGPL program available to any user who interacts with it. Otherwise the license is practically identical. Otherwise the license is essentially identical to the GPL.
If you diff the licenses, you'll see that other than section 13 and s/GPL/AGPL/g, the actual license terms are identical (if you diff sections 0-12, only the addition of the word Affero to the first line of section 0 will come up). The preamble and afterwords are different but they aren't actually part of the license (only the sections between the lines `TERMS AND CONDITIONS` and `END OF TERMS AND CONDITIONS`). As for the differences in those sections, the preamble provides context for why the license exists compared to the GPL and the afterwords provide a recommendation as to how to provide source access.
So in effect the AGPL is identical to the GPL with the addition of requiring that you make sources available to any user "interacting with it remotely over a computer network". Contrary to popular belief this doesn't mean you need to provide sources for everything that touches it over a network, just that anybody/anything that interacts with it over a network be granted access to the AGPL source (and corresponding sources). The requirement for what is considered part of corresponding sources is exactly identical.
That requirement:
TLDR: The only practical change in the licenses for a piece of hosted software is that under the GPL the user is the server operator/host and under the AGPL the user is the actual user/client. Whether a given piece of software gets "contaminated" by a AGPL work is no different than if said AGPL work was licensed under the GPL instead.
I get your philosophical point point and I'm not enough up on various licenses to debate the AGPL.
I'm coming more from a "build a company and feed your family" point of view but everyone has to balance their own priorities/ethical positions.
I guess at least if the license is set at the outset people can choose to engage or not, rather than having what they may percieve as a "rug pull".
I was with you up until this point.
I honestly don't get why more people don't just use the AGPL.
Mastodon et al prove it works.
I would hesitate to characterize a service running on grants and donations as a good model for your typical startup to imitate.
Why not? It is one of the most sustainable models if you want to maintain quality and avoid enshittification.
The VC-oriented financial model (that is, your typical startup) is fundamentally incompatible with Mastodon's non-profit financial model. As a result, very different choices around licensing, funding, and business structure are good fits.
Each tool has its use and serves its specific purpose. What works for Mastodon might not work for others trying to advance different goals.
Nobody should take VC money unless they absolutely have no other option.
The primary goal of a startup is to make money through acquisition or IPO, and the primary goal of business more generally is to make money selling a good or service. Grants and donations don't really fit into that, and isn't the topic of this whether or not to open source the code of a commercial venture?
For my money, dual licensed AGPL is the way to go. All source is available under the AGPL, but also available via a paid commercial non-open source license.
The only real drawback is ensuring any outside contributions can be utilized this way, such as with a CLA.
That's what I ended up doing recently [1]. I'm doubtful I would even know if someone did end up breaking the license agreement though.
[1]: https://pl.aiwright.dev/about/license/
That's the thing. You can dual license however you want. But if no one from the outside actually contributes what have you accomplished really? (Other than being able to say you're open source.) Of course, a great many open source projects in general are one person or one organization.
It's a legal mess that doesn't work if your application isn't a website, and even then it's a problematic thing.
Honestly, for considerable portion of its use, it works mainly because nobody looks too closely or trieso actually enforce it.
The other considerable portion was/is bait&switch schemes involving dual licensing and having developers sign copyright transfer forms to parent org, which benefits from selling commercial license when someone runs afoul of compliance.
Well, Mongo decided it doesn't really work. At least not for them, anyway. This is one of the most notorious case of relicensing from Open Source to source available cases, so it might be interesting for you to look into the reasons (it happened around 2018).
In the end, the AGPL is huge but not a silver bullet.
I think a lot of people get salty when a company changes their license to a source available license but still try to call it open source and free ride on the goodwill that open source software engenders.
Don't call a license open source if it isn't and reasonable people will be fine with it.
I did say pick a license from the start. I'm not criticising people for having different philosophical positions on licensing.
I was addressing the point about the "saltiness" when licenses change. I wholeheartedly agree that making a thoughtful choice the company can live with from the start is the best policy.
I agree that when a big cloud company tries to emulate you, you are already winning on a normal company. But maybe not for a venture-backed/big-exit-strategy startup. And probably, those early investors are the ones recommending against fully open-source business models.
And the main one:
It's really hard to make any money by giving your product away for free...
If you open source your product, your business product becomes hosting / maintenance / consultancy.
Has it ever worked, i.e. Is there any company which could pay market rate salary without any extra funding or being subsidized by other parts of company? Docker, terraform, elasticsearch, many DBs etc tried it but it never generated good revenue to pay developers outside of VC funding. See their revenue after they begin removing free stuff[1].
Even supabase is an awesome product but they needed $116M of external funding[2] to support their development which looks like unsustainable model for open source.
[1]: https://prismic-io.s3.amazonaws.com/sacra/fc6f34f9-d598-4b53...
[2]: https://www.crunchbase.com/organization/supabase
Yes, I work for XWiki [1] which works exactly like this. It's been running since 2005. Don't expect FAANG salaries, the company is small and doesn't have investors, but the salaries are decent and the working conditions are great.
To my knowledge we don't have any competitor that takes XWiki and provides support and/or consultancy. I don't think it would be possible to freeride on our product because it would require expertise they would only have if they contributed to the project and it also requires brand recognition. We are of course the reference, people trust us because we are the main developers.
Many features have also been sponsored by customers so we do receive money to develop big parts of the product itself.
[1] https://www.xwiki.com/
Looking at the pricing page[1], it looks like open source is missing many features like LDAP and extensions. Is that correct?
[1]: https://xwiki.com/en/pricing/
Everything we do is open source, including the LDAP feature ("custom" consultancy aside, where the highly specific parts are often not public). Most extensions are free, some are paid (including the convenient LDAP app), but all are open source, including the paid ones. XWiki is not open core.
In particular, the core code for dealing with LDAP is there [1], open source and gratis, and the paid app that provides a nice UI for it is... paid but also open source under LGPL and the code is here: [2].
You can actually clone the code, strip the license management, compile it and install it on your own instance, but people usually just pay and they also get support.
It's pretty much like OSMAnd Plus, which is paid on the Google Store, but the actual source code is still free software.
So yes, we actually sell free software (and free ≠ gratis has its full meaning with us), and it turns out convenience makes it so that it works out.
Usually organizations big enough to want to use LDAP can usually fork off a few bucks and will be glad to support us.
Of course it would be nicer if it were free and it's always a delicate balance to decide what should be a paid app / feature, but at least it's always open source , with all the relevant rights to users it implies: the right to take the code, adapt it and/or go find someone else if they are not happy with us.
As someone convinced that free software is the right way to do software, I think this is a sane way to fund free software, and good to take.
It's also way easier to handle than donation for an organization that would like to send us money, it's easy to justify.
[1] https://github.com/xwiki-contrib/ldap/
[2] https://github.com/xwikisas/application-activedirectory/
Ionic seems to be doing OK.
Ionic has raised $25M from external funding.[1]
[1]: https://www.crunchbase.com/organization/ionic/company_financ...
Yes that's what you sell but if you also have development costs and your freeriding competitor doesn't, how often do the finances of it work out?
It may be difficult to freeride, you still need to know in depth how the product exactly works if you want to provide consultancy and support.
Freeriding would break on the first tricky support ticket or the first feature you'd need in the product that isn't there yet. You get to know the product well enough if you start contributing and interacting with the main contributors, at which point you stop freeriding and you become a partner instead.
The other way to do this would be to get an agreement from the main developers so you can be supported on your consulting and support activities, in which case you also become a partner.
I tend to think both outcomes as beneficial to the main devs, who can always stop collaborating if it turns out they are not.
Now, if your product is something for which nobody needs support or consultancy, you risk having the MongoDB-Amazon issue.
...So, that is the problem isn't it?
Basically, well-written software and documentation are meant to reduce the amount of support and consulting needed by users. Assuming your point is true, then for a company that sells support and consultants, enriching documentation, etc. would be an action in direct conflict with its own interests, wouldn't it?
The MongoDB people are very passionate and have built a great software, documentation and user community... to the point where they no longer need to sell their own support. Therefore, it is my understanding that Amazon has decided to use their "support".
(If you're saying that it doesn't matter to the users if the company lives or dies when there is already functioning software and community, that may be true)
Yep, it is a risk, but it's also not applicable in every case. Now, I'm not an expert and I'm not sure what are the exact boxes to check to avoid the issue but we for sure don't have it. It is definitely something to carefully consider when creating an open source business. I guess Amazon wants to provide nice developer tools and improve its cloud offer to attract people to its cloud solutions, but our product is not for such developers. Amazon is not interested in providing support and consultancy for XWiki (we know this for a fact since they use XWiki and sponsored important features). It does not scale that well, unlike providing MongoDB.
One could think this, but it's not actually the case. I guess we already have enough support work that's not related to a lack of documentation such that we don't need to increase it artificially. We are actually incentivized to reduce our support work. Companies will usually need to be reassured by a support contract in any case.
We are big users of the documentation ourselves and we have every incentive to write good documentation because of this. Lack of documentation actually increases our cost of operation, because all of a sudden, if you need to know something, you need to find out the relevant developers, who might have left (but probably not because people usually stay), and wait for their reply, or wait for someone to look into the relevant code.
There's also no policy of keeping any documentation secret. On the contrary, we are encouraged to publicly document what we do. So when we document, we do it publicly, except for internal processes.
Our documentation is far from perfect, but it's because of a lack of time or diligence, not because we are incentivized to keep documentation secret.
What's more:
- a good documentation is a good look for someone who seeks to adopt our product
- the same values that push us to do it the open source way pushes us to also publicly document things.
- when documentation is lacking or help is needed, you can always reach us on our public chat and our public forum, and the product team is in reality usually quite responsive. And so if the documentation is good, there are fewer questions to answer. Of course, there are limits, questions that look like support questions will be invited to talk to our support team. Unless someone else in the community does answer the questions for free.
Open sourcing your code doesn't necessarily mean that you're giving your product away for free.
The value in a lot of businesses (most?) is in the distribution and my core argument in the post is that being open source actually gives you an edge here, especially in markets where your competitors are unwilling to take this approach.
Business value only matters if you can capture it.
Probably poor word choice from me but when I reference superior distribution I'm assuming 'value-capture'.
I thought you were saying you'd have greater distribution if you give stuff away free, but in that case it's much more difficult to capture value from it. Everyone wants free stuff.
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/
What is the financial backing that affords you the ability to offer your product for free? Everyone still has bills to pay AFAIK
Two prior successful startup exits.
I also do consulting and advisory work in adjacent spaces so this is pretty much my lifelong dream - spend my other time just doing open source projects I think are interesting.
You could just pick a better license like the GPL or AGPL. Cloud companies eating other open-source products up is purely the inability of those products to choose licenses that actually protect their work.