[HN Gopher] Going open-source as a VC-Backed company
___________________________________________________________________
Going open-source as a VC-Backed company
Author : lucasfcosta
Score : 141 points
Date : 2024-09-10 13:16 UTC (1 days ago)
(HTM) web link (briefer.cloud)
(TXT) w3m dump (briefer.cloud)
| ezekg wrote:
| This is a good reminder to folks that Open Source isn't a
| business model [0] -- it's a distribution model. You have to
| figure out your business model if you want to survive. Good to
| see Briefer figuring this out early on. The decision to offer
| Cloud + Open Core is a great, well-traveled path.
|
| [0]: https://cra.mr/open-source-is-not-a-business-model/
| ekidd wrote:
| Open source is business model, but it's not a VC-friendly,
| easily-scaled business model. Relatively few companies ever
| made it work, and it's only gotten harder with the rise of one-
| stop cloud vendors that host other people's software.
|
| 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.
| dragonwriter wrote:
| > Open source is business model,
|
| No, it isn't. It's more or less compatible with different
| business models, but it itself is not a business model.
| mindcrime wrote:
| > Open source is 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_
| arminiusreturns wrote:
| I hope to prove you wrong.
| satvikpendem wrote:
| You are just describing various business models that are
| compatible with open source software, but simply open
| sourcing your software is not in and of itself a business
| model, which is exactly what the article in the comment you
| are replying to says.
| skeeter2020 wrote:
| Not sure exactly what they figured out; they landed were
| multitudes have before, even this specific market and product
| has similar dual-offerings. It's a very crowded space.
| marvin-hansen wrote:
| VC backed companies love AGPL because it's basically a poison
| pill that still makes them look OSS good. The entire blog post
| can be summarized as "we ticked all the boxes on paper, now pay
| us for looking good". People, however, usually pay for good
| software instead of good virtue signaling.
| ezekg wrote:
| I actually agree with this in practice. OSS purists might argue
| that AGPL and non-compete source-available licenses are
| fundamentally different, with the former being OSI-approved,
| but in reality -- at least in business -- they're used to serve
| the same purpose: to give the author an unfair advantage. And
| that's totally fine -- I'm all for unfair advantages in
| business. But the distinction between these licenses is
| blurrier than the OSI would like to admit, yet they insist it's
| a crystal clear line. /rant
| rectang wrote:
| As an open source advocate, I'm fine with source-available
| licenses. They've been around forever!
|
| 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.
| ezekg wrote:
| > ... by insisting that "source available" is actually
| "open source". In other words, what you're trying to do
| here.
|
| 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.
| gwd wrote:
| > 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".
| ezekg wrote:
| I think my point was more that the author is the only one
| who can legally make closed-source modifications, i.e.
| their open core business model, giving them an unfair
| advantage. Also, the FUD surrounding AGPL. I guess I'm
| trying to point out that there's an obvious reason every
| open source business uses AGPL... and it's not that they
| want competitors to contribute back.
| gwd wrote:
| If they accepted contributions without a CLA, then no
| they can't make closed-source modifications (without some
| major surgery to get rid of the code not owned by them).
| If they wrote all the code in the first place, then
| that's hardly an "unfair advantage".
|
| 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.
| ezekg wrote:
| Yeah, I think you're spot on with the whole CLA thing.
| This is why I added the badly-emphasized caveat "in
| business", which ime typically use CLAs. Outside of
| startup-land, AGPL is a fine license. I just don't think
| it's used honestly in startup-land, that's all. We all
| know the real reason OSS startups use the AGPL: to push
| competitors and enterprises to purchase a MAY-issue
| commercial license through FUD; yet we still praise them
| for being Open Source. Yay. But imo, in startup-land, it
| feels like a non-compete masquerading as Open Source,
| even though I know it isn't.
|
| 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.
| candiddevmike wrote:
| Fair source is worse than the AGPL though, sure it's
| "eventually open source" but what good is 2 year old code
| for anyone? How do you add improvements/security fixes to
| the codebase without the developer saying you didn't
| clean room the implementation?
| ezekg wrote:
| I think you're coming at this from the wrong angle, but
| the 2-year delay is really only applicable to users that
| want to compete, or in cases where the startup goes under
| or in a bad direction. For most users, the freedoms under
| Fair Source align pretty closely to Open Source, e.g.
| read, fork, modify, redistribute, etc. with the non-
| compete caveat. Users can absolutely use the latest
| version -- unless they're competing, but most users
| aren't competing and don't plan on competing.
|
| 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.
| candiddevmike wrote:
| The 2-year delay applies to all of the codebase in my
| experience, not just the proprietary features. Users
| potentially have to delay security fixes for 2 years to
| avoid copying non-OSS code.
|
| 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.
| ezekg wrote:
| I think you're missing my main point: the only users who
| should need the OSS version would be those competing,
| because FSS offers the same freedoms as OSS to users who
| aren't competing. I don't see how this is a poison-pill,
| or how it's masquerading as anything malicious. I think
| it's pretty honest i.r.t. intent.
|
| Re: forking FSS. Check out what Oxide is doing with
| CockroachDB -- there's your BUSL example.
| fweimer wrote:
| Competitors likely have the resources to figure out how
| to be compliant (with or without giving back), so that's
| not really it. And as far as I understand the startup
| situation, most struggle to attract paying customers at
| all. If you are in a situation that someone is competing
| against you using your own codebase, you have already
| gotten very, very far.
|
| 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).
| wmf wrote:
| It's the free users who want open source virtue signaling. Then
| hopefully you convert some of them to paying customers because
| the software is so good.
| gwd wrote:
| > ...AGPL [is] basically a poison pill...
|
| 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?
| wmf wrote:
| There's pretty widespread agreement that the GPL doesn't
| "infect" beyond the same process, but there's no such
| understanding about AGPL. COSS companies are exploiting that
| ambiguity to say "AGPL infects everything, pay us or die, and
| if you disagree we may sue you and we may win". And 90% of
| lawyers say "don't take the chance; just pay them".
|
| 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.
| goodpoint wrote:
| AGPL is perfectly valid FOSS. There is no poison pill
| whatsoever.
| the_mitsuhiko wrote:
| In practice there is because the copyright holder will retain
| the exclusive rights (via CLA or else) to distribute the
| product under preferable and AGPL incompatible terms. This is
| not an "everybody is equal" situation.
| ezekg wrote:
| It's also surrounded by FUD which is why a lot of
| enterprises, i.e. Google, won't touch AGPL with a ten-foot
| pole.
|
| OSS startups use this to their advantage to push
| enterprises to purchase commercial licenses.
| kkielhofner wrote:
| Additionally, they've been on both sides.
|
| 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).
| madeofpalk wrote:
| > now pay us
|
| 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.
| FL410 wrote:
| This looks like cool software and something I might be interested
| in, but I hate hate hate locking SSO behind the "enterprise"
| tier. I wish this wasn't so common.
| noname120 wrote:
| Why not?
| themanmaran wrote:
| Having built and offered SSO to non-enterprise customers, there
| is a good reason people don't.
|
| 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.
| ezekg wrote:
| It's also incredibly expensive per-connection if you use
| something like WorkOS to handle SSO/SAML. The only way to
| make the financials work is to only offer it on enterprise
| tiers.
| ffo wrote:
| On the note of oss and sso that works well for b2b. Zitadel
| can be tool to get rid of the plumbing work that you
| encounter with all the permutations one can have with the
| different customer requirements.
|
| Disclaimer: I am a co-founder
| lenerdenator wrote:
| They'll throw a wrench in your "free as in freedom" at some point
| or another.
|
| 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.
| wslh wrote:
| VC business is looking for the exit, so they could exit before
| the company charges something.
| passion__desire wrote:
| Looked another way, isn't it great that we, as a society, are
| allowing such experiments to be conducted. At the same time,
| training people to build stuff who will go on to build other
| great stuff even if this particular experiment fails. Sort of
| like cambrian explosion.
| whiterknight wrote:
| Like people, VCs are also motivated by status, recognition, and
| making cool things.
|
| If they were only financially interested they would play the
| game with much less status bias.
| muratsu wrote:
| The hard part is not going open-source today but remaining open-
| source as your product evolves. When using a split model like
| this, inevitably the open-source version serves SMBs and the paid
| version serves Enterprises. Given enough time, you end up having
| two different versions of the product for two different customer
| segments and logically axe the version that doesn't make you
| money anymore.
| tinco wrote:
| It's likely not even going to be a conscious or intentional
| choice. At some point your enterprise customers are going to
| have enough bugs and feature requests to keep you busy full
| time, and your open source project might languish unless you
| make a conscious effort to dedicate a percentage of your time
| on it.
|
| 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.
| that_guy_iain wrote:
| In my opinion, this just means you've done a poor job on the
| architecture side of things. If you need a paid version that
| has extra functionality then your free version needs to be
| extendable.
|
| 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.
| WhereIsTheTruth wrote:
| Who doesn't like free manpower to kickstart your VC backed
| startup?
|
| "We only have 2 employees btw, we are so good"
| wmf wrote:
| Realistically there is no free manpower. Small COSS projects
| initially get no contributions and once the project scales it's
| more work to manage the community and merge "contributions"
| than to ignore them.
| ndiddy wrote:
| I've seen people try this strategy before. Generally what happens
| (assuming the project gains adoption) is that eventually someone
| will independently implement one of the enterprise exclusive
| features and try to get it added to the free version. Either you
| lose one of the selling points for the enterprise version or you
| reject the PR and get bad publicity and risk people forking your
| software.
| fsflover wrote:
| Does it also happen with AGPLv3?
| zeeg wrote:
| I just wanna remind folks that Open Core is not the same as Open
| Source. I didn't look at specifics, but I was triggered by this
| comment:
|
| > 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.
| unclad5968 wrote:
| Open core and open source are orthogonal. Open core is a
| description of what part is open source. Just because the
| entirety isnt open source doesn't mean the part that is somehow
| isn't.
|
| At least that's the idea OP is trying to communicate, which
| makes sense to me.
| yawnxyz wrote:
| I think the author did a great job communicating that some
| parts of software are fully open, and a few other pieces of
| code / repost are not.
|
| I like this way better than software with complicated
| licensing schemes, where you can only use certain packages on
| Wednesdays.
| danenania wrote:
| I would argue that they are not in any way exclusive of each
| other or opposed to each other.
|
| 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.
| zeeg wrote:
| Postgres is not operated by the same people as Neon or
| Amazon, thats a fundamental difference. I was also not
| suggesting commercial cannot benefit Open Source (and would
| in fact quite the opposite).
|
| 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.
| nikita wrote:
| At neon we only worry about hyperscalers particularly
| Amazon. But they already have Aurora so we just open source
| everything under Apache 2.0
|
| 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
| ezekg wrote:
| I'm not sure I personally agree with this, and I'm not 100%
| sure the developer community at-large does either...
|
| 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/2dd2f058d1
| dcae6f...
|
| [2]: https://github.com/calcom/cal.com/blob/main/packages/f
| eature...
|
| [3]:
| https://github.com/PostHog/posthog/blob/master/ee/LICENSE
|
| [4]: https://github.com/sidekiq/sidekiq/blob/main/COMM-
| LICENSE.tx...
| zeeg wrote:
| This is the problem with the definition. If the product
| is trurly open source, call it that. If its not, thats
| ok, but don't. Core has no real definition.
|
| 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.
| ezekg wrote:
| > 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.
|
| 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).
| Peer_Rich wrote:
| whats so confusing about open core?
|
| 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
| the_mitsuhiko wrote:
| Open Core locks important part of a product away behind a
| proprietary license. If you build on it you need to hope
| that the company will hang around. If it ever goes away
| you have to hope that they do the right thing a relicense
| it.
| Lutger wrote:
| Whether that part is important depends on how you use
| that product. A lot of open core models specifically
| target enterprise users with their premium features.
|
| 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.
| yakkomajuri wrote:
| Well the tricky bit is that AFAIK most of these companies
| have or at least had a full product that was indeed FOSS
| but then have a cloud offering which is open core.
|
| 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.
| Lutger wrote:
| I disagree. For an open core product the core is actually open
| source. You can fork it, change it, distribute it. It may have
| an OSI approved license. You can't do that with a source
| available product.
|
| 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.
| ezekg wrote:
| > You can fork it, change it, distribute it. It may have an
| OSI approved license. You can't do that with a source
| available product.
|
| 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.
| :)
| madeofpalk wrote:
| They're explicitly not conflating the two.
|
| 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.
| zeeg wrote:
| When you offer a subset of the product as open, and a subset
| as not open, its not open source. Pretty simple math for me.
|
| 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.
| madeofpalk wrote:
| There's two things. One is open source, the other is not. I
| don't think it's that underhanded.
| bachmeier wrote:
| Not to rain on anyone's parade, but this is little more than a
| crippled free trial of a product they're selling. They wouldn't
| be able to sell that part profitably anyway, so open source
| doesn't mean much from a business perspective.
| wmf wrote:
| Historically the "crippled" version works fine and many people
| use it. Also, attracting tons of free users has real value; for
| example it creates awareness about the paid version.
| bachmeier wrote:
| Definitely. They're doing this because it will help them sell
| more. But this is not "going open-source". They're selling
| the same not open source product as before.
| 0xbadcafebee wrote:
| Their reasons for going open source (and they're not, they're
| open core) is: 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"
|
| But none of this pans out.
|
| 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.
| ezekg wrote:
| Off-topic, but your bio sent me down a fun rabbit hole with
| ChatGPT.
| rubenfiszel wrote:
| Ola from windmill.dev, another open-source VC-backed company
| using AGPL. We actually spoke before your pivot and we now have a
| bit overlap on the dashboard builder but our audience is fairly
| separate.
|
| 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.
| jay-barronville wrote:
| You just can't win with some folks and I honestly don't think
| it's worth the effort to try. You remain proprietary, they'll
| complain. You open-source what you can with a reasonable enough
| license that protects you and allows you maintain a business
| atop your product, they'll complain. You build it with zero
| venture backing and you'll be begging for support and donations
| to keep building the product.
|
| 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.
| thayne wrote:
| > As a result, this approach often falls short of investors'
| expectations for significant returns, which makes it hard to
| raise funding and thus prevents most founders from being able to
| go full-time on their project.
|
| 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.
| paxys wrote:
| User base #1 wants free (as in freedom _and_ free beer) and open
| source software. Company wants to cater to them to generate
| goodwill.
|
| 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.
| debacle wrote:
| A rare few do. I think WordPress being the most noteworthy.
| paxys wrote:
| That's because it is owned by a non-profit foundation, and
| never took VC funding to begin with.
| ezekg wrote:
| Are you sure that most users actually want #1, and not just
| free an in beer?
| raebyddub wrote:
| I hope this isn't a trap where someone uses open source to tap
| into a community of skilled engineers for feature development,
| then shifts to a private model, and ends up with a refined
| product created at no cost with the help of talented
| contributors.
| koolhead17 wrote:
| I can bet on the product switching to open core in next few
| quarters.
| echan00 wrote:
| It doesn't matter as long as you can rationally detail how you
| have a chance at becoming a billion dollar plus company
___________________________________________________________________
(page generated 2024-09-11 23:01 UTC)