Open core companies are not incentivized to make their projects good
plural.shThere are different types of features you can monetize with open core. The article talks about monetizing features that allow you to run it as a SaaS and the problems with that. At GitLab we opted to make those open: "The open source codebase will have all the features that are essential to running a large 'forge' with public and private repositories" https://about.gitlab.com/company/stewardship/#promises Instead we monetize features that managers and executives care more about https://about.gitlab.com/company/pricing/#buyer-based-open-c... This prevents the perverse incentives mentioned in the article.
There a lots of features in gitlab that are closed source that I, as small, one man shop, would like to have. I do think gitlab does a much better job of balancing proprietary versus open source features than most open core products, but the incentive still seems to be there to keep useful features back.
One example is global cross-repo search. When looking for substrings on KDE or GNOME's Gitlab, I often want to use the global search bar, but there is no free full-text search across all repositories hosted there, and I have to rely on code search tools external from the code hosting site's UI, like KDE's https://lxr.kde.org/.
GitLab team member here.
You can make suggestions to move features between tiers, i.e. moving a paid feature to the free tier, by opening an issue following https://about.gitlab.com/company/pricing/#changing-tiers-and...
While I appreciate one can do this, it doesn't mean it will happen, and doesn't really answer the OPs question head on.
Which is, does GitLab intentionally evaluate certain features to be behind the paywall to boost sales?
Why wouldn't they? I guess I don't see why the question needs to be asked. There are more interesting questions to be asked about how GitLab makes such decisions.
If there's a feature that is mostly only valuable to pointy-haired bosses, then of course there will be people who want that feature to be available for free. But such a feature should be behind the paywall. It will end up funding features outside of the paywall, so the free users have a reason to be happy about it being behind the paywall.
Of course there will be lots of things in the middle, and people will disagree on every aspect of the evaluation. And people will argue that something should be free because it's good for the community when in fact they want it to be free because they don't want to pay for it. Such is the nature of the balancing act that GitLab signed up for, and I respect them for it.
It's a relatively new spin on the ancient balancing act of value creation vs value capture. TANSTAAFL
I think we're coming at it the same way, but I'm being more terse in my question line.
I am interested in how they arrive in those decisions and do revenue generation features / fixes get weighted differently than non, or are those types of tasks separate from their revenue potential or retention?
I think I'm just leaning on the OP for this context, but I should have added it.
The problem is, some think that these (and other) approaches are killing open source.
> If we normalize projects baiting developers with an open source license to gain traction and switching to a non-open source license to monopolize the returns on that traction, then the logical next step for investors will be skipping that first step entirely.
> And that, for the industry, is nothing but a dead end.
- redmonk.com/sogrady, https://archive.is/GN2Bd
You can absolutely use GitLab to the highest levels of productivity and effectiveness without paying a cent. It just tends to require more input and effort and results in tool sprawl if you want to recreate the GitLab EE experience for free. It's possible for many of the important features, and where it's not possible, it's usually not critical.
GitLab is, imo, one of the best examples of how to do paid open source. Especially because they've gone about it without the relicensing switch that many companies have attempted in order to "protect their business/product."
> If we normalize projects baiting developers with an open source license to gain traction […], then the logical next step for investors will be skipping that [bait] step entirely.
But where would traction come from, then? Switching to a proprietary license works well because they're baiting devs, if investors skip that step there's not as much to monopolise. Or am I misreading that paragraph?
Are you then incentivized to work on managerial features rather than core product features? The disincentive comes from the fact that profits aren’t tied to the quality of the product.
As someone building something that's intended to be released as open-core, I disagree with this article. I've worked at and with B2B companies my entire life and specifically in that domain, there's a lot of "process-things" that are steamlined using a SaaS rather than by self-hosting. It's "much" easier to get a budget for a SaaS for $5 per user rather than have devops involved with setting up infra for a new service (and move around a hundred other priorities for them), and they'd happily say <non-trivial money> to have someone else send an invoice at end of the month for a service even if they can technically host it themselves with 90% of the core features.
Of course, there's other 'grey-pattern' techniques that open-core systems use (eg. the notorious https://sso.tax) that can also help build companies around but it's important to note that a small 10-100 person company has very different "app visibility/reporting/analytics" needs than a 1000 person corporate with multi-level hierarchies, and it's very much possible to build out a profitable company that builds a community with the 10-100 person startup via open source offerings that work perfectly for their use-cases while charging the companies that want something that "just works" for them for a lot of the advanced non-core stuff (and services).
I haven't investigated how true this is, but I've long suspected the reason that PostgreSQL remains relatively difficult to install, configure, replicate, and cluster is that most of the development is done by companies who sell paid solutions that make it easy to install, configure, replicate, and/or cluster.
Postgres is super easy to run with these days -- it works great in a container.
Clustering and replication isn't the easiest but that's mostly because it just hasn't been a focus of the postgres machine -- they're making changes that are a bit more fundamental and in my opinion pressing.
Most startups just need to scale a postgres server vertically, not horizontally.
Some of those solutions are themselves open source. Perhaps I am being too generous, but I tend to think in this case it is more that there are many possible approaches to these things and the postgres community simply does not want to bless any one solution just yet.
Either I'm the guy setting up all the vulnerable Postgres installs or I'm just some kind of unknown Postgres savant.
Cany anybody help me out and mention some setup details a blissful idiot like myself might be neglecting in their postgres cluster-ups?
How do you handle replication and failover?
The cluster of 3+ servers must remain consistent, available, and not lose committed transactions when a minority of servers (including the former master) fails.
I’ve had good experiences with logical replication and pg_auto_failover. The cool thing is that the libpq-based clients do some of the work during failovers. You’ll need three nodes though.
What about a commercial source but fully source-available product?
I'm currently building an app I hope will appeal to the HN crowd, and I was planning on making the full source available to all customers - this would be billed as a feature of the product.
I can't count the number of times I was happily using a closed source product only to find a bug or missing feature that I really wished I could just make a small tweak to add/fix. I didn't need the app to be open source or anything, I just wanted to be able to see what was running and make a small change myself. For many of these situations I would happily commit the patch back to the commercial product, just so that my experience would be nicer.
I want to be able to charge for and sell my app, but I would like all my users to be able to see exactly what's running under the hood, and be able to tweak and modify it for their own personal use. (I also plan on including an extensive public extension API. Extensions can also be open source of course.)
To me this seems like a fairly good sweet spot, as I really do need to charge to be able to support the development. I could even see committing to always keeping the source available to users, or to open source it if I ever stop commercial development of the product. I hope this appeals to folks here, because I can't see a better model that will support a single developer as I go.
It's one thing to be able to see what's going on under the hood. It's another being able to change what's going on under the hood. And it's a third thing not having that change you just made get stomped on, or interfere with the next great release of the product.
Even potentially more difficult is getting your change accepted by the software vendor to where it's now incorporated in to the production product.
I mean, this is nothing new, this happens with open source projects all the time, but it can be a difference in scope depending on the level that your company actually relies on some product for their operations.
What about making the basic product free but charging a fee for modifications?
I've played a few video games with this model: the source being available is a help to modders and the like, while still maintaining the game's commercial status. The best example I can think of is Barotrauma, where just a couple months ago there was a release that subtly broke networking on Macs. Quick code change fixed it so that my Apple-locked friends could play until the company got around to fixing it. Minecraft falls into the sorta-defacto version of this, where they distribute the necessary mappings to decompile the game for modding purposes.
Personally I think it should be the default distribution model for software. If I'm relying on a piece of software, especially one I paid for, doubly-especially if it's running on my machine, I should have the right to modify it and probably to distribute my modifications.
Which is like the Unreal Engine Model. Unfortunately this "Share Source" model hasn't caught on and lacks a widely accepted license.
I hope I am wrong and do wish you to succeed. But Not Strictly Open Source doesn't appeal much to HN crowd.
> But Not Strictly Open Source doesn't appeal much to HN crowd
I don't think this is true. "Open Source" But Not Really is what gets criticized here, such as Elasticsearch's new license.
Things that want to benefit from calling themselves open source while restricting user freedoms.
Source available on the other hand is exactly what it claims to be. It's more open than strictly closed source and less free than fully open source.
That is how things are in the Delphi world.
I'm not sure the part about support contracts being healthier is correct. Doesn't selling support incentivise creating a product that's difficult to use or has reliability issues? I don't know if that happens in practice (and it is the model I would choose myself!) but there's definitely room for perverse incentives there too.
A model that could align incentives better is putting the IP in a trust with the development company as a trust management corporation, with developers, managers, &c, functioning as trustees. Users buy in to the trust -- their license will be a kind of share -- and thus users are beneficiaries.
In order to make any use of the project, users also have to be trustees. This model allows restrictions on what they use it for, what they disclose, &c, because users must agree to certain terms as part of becoming trustees.
Because the development company is a trustee, their incentives are different from those of software companies that own IP: trustees have a fiduciary duty to act in the interests of beneficiaries (even though trust management companies can have their own shares and shareholders, they nevertheless have a fiduciary duty to the beneficiaries).
One of the benefits of open source is that it's possible to arrange for succession if a company stalls out. No one is breaking the law by continuing to develop on the basis of the old IP. Organizing the software as a trust with users as beneficiaries makes it relatively easy to manage succession, as well, since the beneficiaries are the ultimate owners of the property contained in the trust and have a power to appoint new trustees as well as remove old ones.
I got halfway through this before reading the line "Docker, Elastic, and MongoDB are great examples of succeeding with the hosted open-core SaaS" and realizing I have a fundamentally different idea of the meaning of "open-core" and perhaps also "success" from the author. I'm not sure I can agree with anything else stated in the article either...
would love if you could elaborate your definition for open core (and success) as curious to hear an alternative perspective :-)
There can be 100% user-facing feature parity with differences on:
+ SLA and support models (including updates, delivery, integration, etc)
+ Hosted vs. self-hosted
+ Procurement models
+ Compliance models
+ Legal, licensing, IP models
The last 3 may be most applicable in the enterprise part of the market, but can be critical there. Enterprise also often has 'features' which are driven by admin, ops, security, procurement and compliance teams. These 'features' may make sense to limit to the SaaS, partially to keep the FOSS clean, and don't conflict with a mission of user-facing feature equivalence between FOSS and SaaS.
> One may suggest: “If things are running perfectly, won’t customers reduce their required engagement or remove the support plan?” Generally, no. The cost of keeping experts around is usually far lower than a SaaS bill and new features will always need to be built.
I don't understand this assertion. One of the main perverse incentives affecting open core software quality is that the more help people need with the software, the more they'll value support. This article about open core incentives regarding software quality just handwaves this away.
The other demotivator is that having your (OSS) open core be good means that if you make any user-hostile business-motivated demands, somebody will simply fork you and take over your business.
The best defense against the latter is the GPL. Make your competition share all of their work while you don't have to. And ask yourself: if your strategy is going to be to leverage an OSS application to sell proprietary accessories, why be bitchy about copyleft? It's the best of both worlds - open enough that you're contributing to the commons, and restrictive enough that you (as the copyright holder) can still play games with licensing keys and obfuscation to accomplish business objectives. If the community forks your GPL core and publicly builds on it better than you do behind closed doors, it means that you've been outcompeted fair and square.
Make your competition share all of their work while you don't have to.
Can't your competitor then just release their contributions as AGPL? Of course, you're free not to accept their contributions, but under the AGPL you can no longer merge their contributions back into your commercial product without having to share all of your work too.
(Yes, usual caveats about the scope of "the work" apply. But that applies just as much to your competitors as to you)
Under the GPL, contributions have to use the same license: GPL.
Not true. GPLv3 provides one exception, and that is that in conjunction the the provision in AGPLv3, you may combine code licensed under each, and the combination is subject to the terms of AGPLv3.
(Whether this has any significance to context that the other commenter's question was in response to is a different matter.)
"However, open-source companies need to accept that the majority of their big deals and logos come from support contracts, not cloud spending"
A big attraction of open core is you can start fixing things that matter for you as the company on your schedule vs. asking your vendor and hoping they get to it one day.
It depends on the business model: freemium towards enterprise are, otherwise not so much.
Also, commercial open source != free. You can't use Docker Desktop commercially without a license and it's not 100% OSS. Many companies use open source-washing as a way to lure customers into yet another proprietary system that dresses itself up as FOSS.
Furthermore, most commercial open source community versions are crippleware hiding useful features behind closed-source, paid-subscription-only offers. And, the CE versions are usually out-of-date and are slow to receive security updates. SugarCRM comes to mind.
Funny, two of the three products (Elastic, and MongoDB) mentioned as successful open core aren't even open core anymore, but use a non-open source license. Does that mean they were so successful they didn't need to have an open source product anymore? I don't see it as anything to celebrate.
Chief example: Neo4j
I'm sure there are more counter examples but I've always liked drawio
they are incentivized to make them somewhat complex
Let's make something so complex no one really knows how to use it and then we can sell support on top of that
...and difficult to fork, by doing frequent changes.
And difficult to package and distribute in Linux distros.
That's not an Open Core problem, that's a b2b problem.
Good enough means b2b. Consumer-facing stuff generally has a much better UI/UX than b2b stuff, because consumers care.
Sso tax comes to mind here
lol unicorns