6 ms·
Mapbox releases Mapbox GL JS v2 under a proprietary license whereas v1 (presumably) was under an "open core" business model. (Mapbox v1 and v2 are graphics card
by abetusk 6y ago
Mapbox releases Mapbox GL JS v2 under a proprietary license whereas v1 (presumably) was under an "open core" business model. (Mapbox v1 and v2 are graphics card enhanced mapping libraries?).
The author of the article's thesis is that this is "an end of an era" of Open Core business models (putting core technology under a free/libre licensing and charging for extra proprietary features).
I'm very curious as to what other people here on HN have to say about it. Gitlab, a prominent company that follows an Open Core model, is a YCombinator alum, no?
- Lutger 6y agoYes, and valued at over 6 billion so they seem to do ok
- selfhoster11 6y agoI feel like Gitlab will try to pull an Atlassian in the future. They already said they are changing focus to their cloud-based offering over the on-prem version.
- claytonjy 6y agoI worry you're right, and while I think it's bad for what it signals about business model viability, I'm not sure it's bad for how I use GitLab. Do the couple dozen devs at my company really need an internally-hosted version, or should we just pay for the cloud offering and supply our own runners? Seems easy to frame as a wash.
- leipert 6y agoWorking at GitLab, but I want to focus on this part of your comment in general: > Do the couple dozen devs at my company really need an internally-hosted version? From personal experience and knowledge through friends: Everyone writes code. Universities, Governments, Governmental agencies, political parties, etc. A lot of them do not want to host in the cloud, especially in Germany, considering that the cloud (depending on the provider you are looking at) means hosting outside of Germany with all that entails privacy and regulation wise.
- claytonjy 6y agoThat's a great point. I'm in the US, so this isn't an issue for us in the same way, though I've heard fears of "we can't put code in the cloud, what if it gets out!". My response is "what's your threat model?". For a small company, our only security advantage is being a small target; there's no way we're competing with the Gitlab.com team on security.
- hansvm 6y ago> our only security advantage is being a small target 1. If a 3-letter agency requests access to your on-prem data you'll know about the request and know which data is compromised. 2. You now have to trust your hosting provider. This is almost the same as being a small target, but not quite because you need to worry about all of their employees AND all of your own. There are 1k+ employees to attempt to compromise at Gitlab, and you have no control over or contracts with any of them. 3. Expanding on 2, given the disconnect between Gitlab and your own organization you open yourself up to new kinds of attacks like social engineering an account takeover, or expanding an email breach to a source code breach. I don't think any of that matters for most people, but your attack surface area is increased with current cloud tech.
- gmueckl 6y agoIt comes down to whether your company can accept the risks inherent in hosting essential data at a third party site that necessarily provides a bigher attack surface than anything hosted behind the company firewall, but is also monitored by a (dedicated) security team.
- selfhoster11 6y agoOn-prem is your trump card in case Gitlab cloud decides to leave you out in the cold. Without on-prem, you're cut out of your source code service and will have to do a potentially hasty migration to an entirely new platform (which brings its own issues inherent in any migration project).
- john_cogs 6y agoI work at GitLab. Our Open Core business model is part of our 3 year strategy [1] and something I consider one of our key strengths. As a member of the Community Relations team, I may be a bit biased. :) We acknowledge the risk of "Fork and Commoditize" [2] on our list of biggest risks but believe that risk is reduced because we're application software instead of infrastructure software. 1 - https://about.gitlab.com/company/strategy/#2-build-on-our-open-core-strength https://about.gitlab.com/company/strategy/#2-build-on-our-op... 2 - https://about.gitlab.com/handbook/leadership/biggest-risks/#fork-and-commoditize https://about.gitlab.com/handbook/leadership/biggest-risks/#....
- joejoebags 6y agoHi John--thanks for sharing these links. I do wonder if there is a fundamental difference between applications and infrastructure. Maybe it's the fact that applications tend to involve a greater share of non-engineering users (and therefore a greater reliance on someone else to host and manage the service)? Food for thought. GitLab is a great company, and I've read a lot of your strategy documents; it's a wonder you publish so much in the open, and I'm grateful for it.
- john_cogs 6y agoThanks! That is great to hear. We detail the differences between infrastructure and applications in link #2 in my previous comment. If you have any suggestions on how we can improve that section, I'd encourage you to create a MR to update the page. Just click the "Edit in Web IDE" link at the bottom to get started. :)
- alexchamberlain 6y ago* Probability is reduced; the impact is the same.
- PaulDavisThe1st 6y ago> believe that risk is reduced because we're application software instead of infrastructure software. Why do you believe this? My project uses self-hosted gitlab (ancient version) and I frankly have a very hard time seeing it as anything other than infrastructure. Maybe we just don't push our use of gitlab a lot (to be fair, we don't push it at all).