Going open-source as a VC-Backed company(briefer.cloud) |
Going open-source as a VC-Backed company(briefer.cloud) |
But open source has absolutely worked as a business model. This is actually easier to see if you look at companies like IBM. Back around 2000, IBM used to charge $40,000/year per CPU for software that was often mediocre. But as one very smart IBM marketing guy told me, the software was basically an excuse to sell IBM Global Services for consulting and customization. At heart, they were making a service play. And IBM of the early 00s loved Linux, for two rather weird reasons:
1. It allowed them to freely collaborate with other companies like RedHat based on nothing more than a handshake.
2. Even more surprisingly, it allowed collaboration within IBM, between different groups that usually had complex politics.
I as understand it, IBM was not, generally speaking, selling Linux. Linux was just one more way to sell Global Services.
And of course, RedHat themselves were a service company in those days, at least from what I heard from some of their clients.
But service companies are hard, they're sales intensive, and they're not valued nearly as highly as pure software plays with the same revenue. And if you want to be big, you'll eventually need to serve big enterprises. And of course, AWS will happily eat any low-customization revenue you might otherwise be able to snag.
So open source + consulting might be a business model, but it relies heavily on running a successful consulting or services business.
A much more common way to use open source in business is the "stone soup" model. I've helped my employers open source tons of stuff over the years. It was almost all useful tools, not their main products, so it didn't help competitors directly. The upside is that other companies may occasionally contribute something. This is usually pretty modest unless you put in extra effort promoting your software, but it happens. Sometimes, the biggest advantage is that open sourcing a tool is a great way to draw a boundary that says, "This is a generic tool that focuses on one thing. It does not contain business logic." For certain kinds of tools, this can be a fantastic discipline.
But definitely don't think that you can release your core product as open source, and then just run a standard product-based business.
No, it isn't. It’s more or less compatible with different business models, but it itself is not a business model.
It isn't. It's a development model, which (mostly likely) has profound implications FOR your business model, but it's not a business model in and of itself.
It boggles the imagination that people are still confused about this in 2024. sigh
VCs are in business to do exactly one thing: make all of the possible money, forever. If that means making it "source available" and charging out the ass once you reach a certain point, they'll do it.
If they were only financially interested they would play the game with much less status bias.
User base #2 wants fully featured, fully supported, easy to use software, and doesn't care about the source code. Company wants to cater to them to make money.
Ultimately when the VC money runs out both these aims are going to be in direct conflict with each other, and you are going to have to pick a side. Companies pretty much always start by focusing on 1 (OSS contributors, enthusiasts, indie devs) and switch to 2 (corporate customers) over time. I have lost faith that any such project can walk this line successfully and stay true to group 1.
This is IMO, a major problem with VC. VC doesn't care about funding companies that are moderately profitable. They only care about companies with extreme growth that can lead to an extremely lucrative exit. Which means that viable business models that might work well with Open Source may not be attractive to VCs.
Congrats, you made what I believe is the best move a software company can do in our space. You will hear a lot of naysayers, and sure the software we build is not as permissive as Apache 2.0 and MIT. Those are all true and valid points. It's also true that VCs have perverse incentives and as a naturally skeptic myself, I understand not wanting to touch it.
Let me bring a little bit of counter-points to those:
- AGPL or Commercial Open-Source Software would probably just not exist at all if there was no path to commercialization at all. So the dichotomy between making it true MIT or AGPL is a false one, it's the choice between proprietary/no software and AGPL and I think we can all agree the latter is better. Software Engineers need to eat and there is a pool of talented engineers for whom glory is not fully sufficient and also need their work to be a reasonable financial paths. This enables more SWE to compete to build more software and make the software landscape more competitive for the benefit of the end-users.
- Taking VC money is not signing a pact with the devil that strips away your entire freedom, especially at @lucasfcosta stage and ours. The real issue is with being fully dependent on that money by having bad financial health and needing to raise in X months. COSS company like ours can stay lean and profitable, taking just the right amount of money from VC to kickstart a long-term journey to become a behemoth of a software company through having advantages over all the proprietary alternatives. Windmill for instance is profitable, and no investors has ever pressured us to go faster or monetize more. 99% of our users are using the free/open-source version but the 1% that is not is made of medium and large enterprises that hugely appreciate running their infra on open-source software that they can easily audit and contribute to. It would have been SO MUCH harder to convince them without being open-source given our size. Another fact that helps is pricing but that is also related to our open-source nature. It's harder to over-price your large customers because at a certain point they can say screw it, they will just build in-house to go above the proprietary features. All that to say that companies do have incentives but also are made of humans which have their own values and goals, and have some agenda to set their own path, especially early on. It's all about balance and I would argue taking a bit of VC money at the seed-stage at a good valuation and then not much more is the optimal path right now.
1. "If Briefer disappears tomorrow, people can still use the software"
2. "it helps us build a strong community"
3. "by going open-source we commoditize our competitors' core functionality"
With 1), GitHub is littered with abandoned company projects that nobody forked. If people were paying for your product because they wanted managed hosting and support, they're not going to try to keep using it forked (if they even can) if there is a competitor who provides a managed hosting product. So nobody's going to keep using your product after your company dies just because it's open source.
With 2), companies almost always end up completely ignoring the "community" and just doing whatever they want. The real "community" is often just people on StackOverflow, Reddit or somewhere else, trying in vain to get someone to help them solve a problem the company won't, and usually has nothing to do with code. Even if the product is open source and a user wants to do the hard work of fixing a problem in code and submitting a PR, the company can just balk and reject it (which many companies do). So just because it's open source doesn't mean there will be support for a real community.
With 3), nothing is commoditized, because you're open-core. Like with all "open source companies", the really good features will be locked up behind a paywall. So being open source doesn't really give an advantage over competitors either.
The only good reasons to go open source are 1) there's still people out there who will get excited about the idea of open source, and use the product just for that fact alone, because they haven't been burned by an "open source company" yet, and 2) open source is a great way to attract engineering talent.
SSO is a two party system, which means even if you have everything configured perfectly, your customer can still mess up their Okta setup. And no amount of docs will stop them from doing that.
And when they mess it up, they'll blame your auth for not working. And if it's an enterprise customer that's fine. Just spend a day debugging for them. But if it's a free tier user, it creates pure headache with no upside.
"We only have 2 employees btw, we are so good"
> Some people call our strategy "open-core" and that's technically right. Still, I'd rather say that we have two pieces of software: one that is open-source and another that is not. I think that's more honest because we're not trying to hide the fact that we're selling a non-open-source version of our software.
I'm not morally opposed to open core software - and any version of more open source is valuable open source to me - but I think its important we do not conflate the two, just as we need to not conflate other approaches like source available.
Ironically as some companies have already started noticing, when you stop being able to market your product as open source the start of the funnel will start to dry up. The start of the funnel is often not monitored, and the sales might even continue going up as your successful open source users go to enterprise. By the time you realise the funnel has dried up it might already be too late to turn back as competitors have filled the void you left.
Your free version should in theory just be a freemium version of your product. And your freemium version of your product should lead to paying customers and be a major way of generating leads and customers. If it's not doing that then it should be a case of do you need to stop adding so many features to the free version or is it that a free version just isn't used by enough people to even matter?
If no one is using it, then really stop building it you're just wasting your time just so you can virtue signal that it's open-source. Really, the only people who will be mad will be the ones not helping you out.
My first hand experience is that there are two likely outcomes: (1) You limit the utility of the open version to create a buying trigger and your open source users dwindle away as the open product doesn't meet their needs. Or, (2) your community has sufficient momentum to build the feature itself and your sales team starts losing deals to your open source offering.
This model also creates harmful intra-organization conflict between those who argue for short-term revenue (probably their continued employment depends on that) vs. those who argue for the largest open source user base. It also creates conflict with your users as you intentionally offer a worse product to your largest user group (open source users).
I appreciate that folks like y’all take the risk to build dope products and still do your part to open-source what you can. In an ideal world, everything would be open-source (by purist standards) with ultra-permissive licenses, but that’s, unfortunately, not the world we currently live in.
What ticks me off is freeloading on the goodwill generated by open source, for instance, by calling your license "Apache License Version 2 with the Commons Clause" or by insisting that "source available" is actually "open source". In other words, what you're trying to do here. That goodwill doesn't belong to you. Don't try to steal it, and don't be surprised when those who are invested in open source push back hard when you do.
If they are looking to invest in a company when they do technical due diligence and bring in a source code auditing company like Synopsis Black Duck any AGPL you're using is so problematic for them it can be a deal breaker. At a minimum it's such a major sticking point it can be one of the most significant things to hold up a transaction as you try to explain why it isn't as problematic as they think.
Having been through that process a couple of times I won't touch AGPL because it's such a PIA - your poison pill.
On the flip side, if they have or are investing in you and and you've made some aspect of your solution open source under AGPL they know any competitor using it is going to have challenges getting VC investment (see point above).
I died laughing at his comment later in the article. I still don’t know what his product is but to have such a broken misconception of free and open source, I really don’t want to know what he’s trying to sell.
Bill Gates from the 1990's called, he wants his FUD back.
To be more specific: What arguments can be used to show that the AGPL is a "poison pill" in the SaaS space, which couldn't have been used by Microsoft back in the 90's and early 2000's to show that GPL was a "poison pill" in the distributed software space?
Microsoft was consistently and openly opposed to open source back in the day. Now we have startups that are simultaneously claiming to be open source while using FUD to advance an essentially non-commercial interpretation of open source. It's not the same situation.
I mean they summarised that are the very beginning of their post. They're not being shy about this. The entire post is about them making money.
> But I'll be honest with you: Briefer is a VC-backed company, and it must make money.
An open source project can be built upon and extended by anyone, and that includes its creators.
We don’t say that an open source project is diminished because some third party productizes it and makes money. PostgreSQL is not diminished by neon or rds.
No, we continue to judge the project on its own merits. If it continues to offer value, to be compelling, well-supported, and stack up well against alternatives, then we keep using it. We don’t think “it doesn’t have all the features of rds, so screw postgres”.
If the commercial side of the project takes away from the oss side and the oss project goes downhill as a result, then that certainly is a frustrating and disappointing outcome. But when both sides are thriving, it’s a fantastic win-win.
The maintainers get to focus their full attention and passion on the project. The community gets better and better software. And people who are willing to pay for advanced or niche use cases get their problems solved too.
Summing up, the problem is not with the whole model of open core, but with specific projects and companies that get it wrong.
There’s no fundamental reason why the oss side and the product side have to be at odds. It’s just freemium, and there are countless successful and beloved freemium products out there who figured out how to get the balance right.
In general I was not commenting if they're opposed, but suggesting an Open Core project is Open Source is not truthful. "Core" is a meaningless term, and if we suggest any Open Core project is Open Source, I can easily academically argue that the majority of businesses are Open Core, thus Open Source, and we'd all agree that's not true.
This project is Open Core, and thats fine, but Open Core is not inherently Open Source, and if we're going to care about that term in some contexts (e.g. with Fair Source) we need to care about it in all contexts.
At least that's the idea OP is trying to communicate, which makes sense to me.
I like this way better than software with complicated licensing schemes, where you can only use certain packages on Wednesdays.
Furthermore, you can't even talk about the open core as a part of the closed source product, because the open core application is invariably a whole in and of itself. You could theoretically fork it, improve on it and it could have a life on its own as a 'fully' open source product. You can even make it incompatible with the closed version.
Small correction: under popular source-available licenses like the FSL, BUSL, and ELv2, you can fork, modify, and redistribute. These licenses are usually just concerned with cloud competition, which is none of those things. You can still fork, modify, and redistribute your changes, with no copy-left strings.
Still not Open Source like AGPL, but just wanted to clarify. :)
They say they have a closed source hosted offering, and an open source self-hosted offering.
It's fair to call the overall approach something like 'open core' or 'source available', but when you offer the open core under a license like AGPL, it think it's pretty hard to claim that isn't open source.
This is not a comment on "which" OSI license they used for the open part, but I will not support people calling Open Core broadly Open Source, as its not.
Disclaimer: I am a co-founder
There's a big difference between 'you can look at the source but not use this product in the way it is intended if you make money by doing so' (production use), and 'you can use the source in any way you like, also for production, but not to compete with us'. I've always understood 'source-available' to mean the former because it used to be like that, and the latter to be a slightly restrictive version of open source. Historically, the latter variant also emerged out of competition with the big clouds (mostly AWS), from projects that used to be truly open source, whereas a lot of what I think are source-available licenses come from vendors that were fully closed before or would be if there was no demand to see the source (for example, for security purposes).
Users are free to use the version under AGPL, there is no poison pill.
OSS startups use this to their advantage to push enterprises to purchase commercial licenses.
I never said that. I said the lines are blurry when it comes to how the AGPL is used in business
The AGPL isn't used to uphold OSS values, it's used as a defense against competition.
It's only a defense against competitors who want to use it and not give back -- just like the original GPL. If you prefer the BSD ethos, that's fine, but just say "I disagree with the copyleft philosophy", not "AGPL doesn't uphold OSS values".
I believe the usual AGPL idea is that it generates sufficient FUD for regular customers so that they don't want to run the free (AGPL) version in production. Instead, they feel compelled to cut a separate, commercial licensing deal. A project/product is likely to follow thus model if the nominally AGPLed project has a contributor licensing agreement that involves an asymmetric copyright grant (i.e., contributions are under a very permissive license, but you only get the aggregate of all contributions under the AGPL).
Let's take a few examples, which I've shared elsewhere in similar discussions:
- GitLab: Open Source or Open Core? Most would say open source, but (I assume) you would argue open core [0].
- Plausible: Open Source or Open Core? They say open source, but it's actually open core [1].
- Cal.com: Open Source or Open Core? They say open source, but once again, open core [2].
- Posthog: Open Source or Open Core? They say open source, but actually open core [3].
- Sidekiq: Open Source or Open Core? Open... core [4].
Yet, every dev I know would consider these projects Open Source... and yet also Open Core. So there's a disconnect somewhere.
Under this mindset, very few open source startups are actually open source, yet everybody says they are?
I'm not trying to argue either way; I'm trying to point out a real disconnect.
Is everybody just open-washing? Why's that allowed?
[0]: https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/LICENS...
[1]: https://github.com/plausible/analytics/blob/2dd2f058d1dcae6f...
[2]: https://github.com/calcom/cal.com/blob/main/packages/feature...
[3]: https://github.com/PostHog/posthog/blob/master/ee/LICENSE
[4]: https://github.com/sidekiq/sidekiq/blob/main/COMM-LICENSE.tx...
I definitely would never call GitLab Open Source. I can't comment as much on the others. Sidekiq is actually how I think the world should work: its open source, and then they sell Sidekiq Pro. One is Open Source, one isnt. The issue is most people don't operate that way.
GitLab Community Edition is Open Source, GitLab is not. Cal.com isn't open source, but is the Cal product? I'm not sure. Given I started Sentry I can at least use it as an analogy. Early days Sentry was open source, but getsentry.com was not (which was our billing infra). No one would have called Sentry Open Core, because no part of "Sentry" was closed source. That's not true for most Open Core.
I guess this is where I get hung up on this topic. To me, there's no real distinction between Sidekiq's open-source core and proprietary features vs GitLab's. One has their proprietary code closed-source, while the other has it source-available in a monorepo. Functionally though, I don't see the real distinction. If Sidekiq can call itself Open Source by you, then why can't GitLab? They're both doing the same thing in the end, if you really reduce it down to its core (pun intended?).
I think we had a similar discussion before Fair Source launched i.r.t. ELv2 sharing some similarities here. I argued ELv2's license keys are yet another way of accomplishing the same thing, just differently: separating proprietary code from the core (ignoring the non-compete for the sake of this conversation).
its open source for the masses and commercial for the very few enterprise with paid addons
https://en.wikipedia.org/wiki/Open-core_model
definitely the best of both—sustainability and freemium OSS for hobbyists and small companies
Provided that the open source product is a close-enough subset of the open core cloud offering I think it's fine to take the easy route of just calling yourself open source although it's certainly a gray area.
Being open is extremely important to us to build trust and we had this since day 1. VCs are fine with it because monetization is all cloud
Likewise, the risk only applies to the premium feature set. If those are that crucial to your operation, you would assess that risk more or less in the same way that you assess a proprietary product - because that is what it is.
For example, if all the security features are essential to your work and you pay for the ultimate version, then Gitlab is more or less a closed source product for you. However, if you are a big company and use self-hosted free version of gitlab to have a cheap inner source hosting for all employees, then it is exactly as if you use an open source product.
There are more nuances of course in a real assessment, but basically the open part is open source and the closed part is proprietary. Very simple.
The only way to accept contributions and then make closed-source modifications is with a CLA; in which case it's the CLA, not the AGPL that you're really complaining about.
ETA: OK, so what if a company start out being AGPL, never accepts any contributions, and then when they become established, stop publishing new code as AGPL and takes everything proprietary? Isn't that just "open-washing", taking advantage of all the community good-will and hype around open source?
I don't think so; consider four possible scenarios:
1. They keep everything proprietary from the beginning.
1a. They become established, making decent money, serving some customer needs. Everything is still proprietary
1b. They fail. Good luck talking their VCs at that point into open-sourcing their code (or even getting it into any kind of shape that anyone could use). All their customers are stuck without any options but to stop using the software.
2. They start by making things AGPL.
2a. They become established, making decent money; eventually they take the product closed-source, doing one final release. Their customers continue to be served, but everything is now proprietary.
2b. They fail. The code is already AGPL, so nothing any of their owners or creditors can do to claw it back. Large companies that have come to depend on their software can take their code and continue to use it and develop it on their own if they want. If there's enough of the right kind of people, a community can form around the releases and the project can live on in a pure open-source form.
2a is better than 1a, because at least there was a time when things were AGPL; the AGPL code can still be forked off and maintained if there's a big enough community.
2b is way better than 1b. In fact, 2b can hopefully make 2a more likely, since it's lower risk for people to build their infrastructure on a start-up.
I'd rather OSS startups be more honest and use something like Fair Source. Bonus is that everything would eventually be OSS, unlike the typical Open Core model.
The difference is that all users also eventually get the proprietary features, unlike an Open Core project under AGPL + commercial terms. I do think Fair Source is a better model than Open Core, at least in most cases, because of this alone. So I guess, would you rather: 1) never have the proprietary features, or 2) have 2-year old proprietary features? I know what I'd prefer, and from a simple continuity perspective, I know which is preferred by users.
Like I said, I'm not saying AGPL is bad. I just don't like how it's used in startup-land and I think there are better, more honest, options now.
Fair source is a poison pill masquerading as OSS-friendly, just like BSL and friends. It's not useful in practice, and I don't think there are any examples of folks successfully using/forking BSL/fair-source code that is now OSS. That's by design.
Re: forking FSS. Check out what Oxide is doing with CockroachDB -- there's your BUSL example.