[HN Gopher] Open core companies are not incentivized to make the...
___________________________________________________________________
Open core companies are not incentivized to make their projects
good
Author : atopia
Score : 93 points
Date : 2022-10-20 14:06 UTC (8 hours ago)
(HTM) web link (www.plural.sh)
(TXT) w3m dump (www.plural.sh)
| busterarm wrote:
| Chief example: Neo4j
| [deleted]
| tinglymintyfrsh wrote:
| 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.
| pessimizer wrote:
| > 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.
| tremon wrote:
| _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)
| mperham wrote:
| Under the GPL, contributions have to use the same license:
| GPL.
| TazeTSchnitzel wrote:
| 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.
| hwestiii wrote:
| lol unicorns
| gz5 wrote:
| 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.
| madmax108 wrote:
| 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).
| ikiris wrote:
| Sso tax comes to mind here
| ny711 wrote:
| "However, open-source companies need to accept that the majority
| of their big deals and logos come from support contracts, not
| cloud spending"
| aposm wrote:
| 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...
| sweaver wrote:
| would love if you could elaborate your definition for open core
| (and success) as curious to hear an alternative perspective :-)
| solidsnack9000 wrote:
| 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.
| pugio wrote:
| 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.
| OkayPhysicist wrote:
| 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.
| whartung wrote:
| 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.
| galaxyLogic wrote:
| What about making the basic product free but charging a fee
| for modifications?
| ksec wrote:
| 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.
| pythonaut_16 wrote:
| > 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.
| piersj225 wrote:
| I'm sure there are more counter examples but I've always liked
| drawio
| manv1 wrote:
| 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.
| mastax wrote:
| 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.
| aliqot wrote:
| 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?
| CodesInChaos wrote:
| 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.
| com wrote:
| 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.
| ensignavenger wrote:
| 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.
| hardwaresofton wrote:
| 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.
| sytse wrote:
| There 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.
| ensignavenger wrote:
| 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.
| nyanpasu64 wrote:
| 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/.
| dnsmichi wrote:
| 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...
| no_wizard wrote:
| 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?
| sfink wrote:
| 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
| no_wizard wrote:
| 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.
| idontpost wrote:
| ignoramous wrote:
| 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
| andrewstuart2 wrote:
| 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."
| kotlin2 wrote:
| 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.
| xchip wrote:
| they are incentivized to make them somewhat complex
| ny711 wrote:
| Let's make something so complex no one really knows how to use
| it and then we can sell support on top of that
| novok wrote:
| 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.
| ensignavenger wrote:
| 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.
___________________________________________________________________
(page generated 2022-10-20 23:01 UTC)