Care to elaborate? Isn't their primary source of revenue gitlab(-ee) which is open source?
Open source companies can't scale on consulting revenue.
It's fine for a lifestyle business but not a business you're trying to scale.
The other way to do is via the hosted service route (which might not work depending on the vertical you're in..)
There's all sorts of trade offs to running an open source company or even just open sourcing code.
Eg: the bigger companies do it for hiring purposes. Devs do it to get hired or learn something.
The companies themselves have to survive somehow, and the incentives will vary depending on the vertical and goals of the company.
They can continue to have a good lifestyle from the revenue they get for their open source tools and associated consulting but actually it's very hard to create enough surplus revenue to grow the business. Consulting on open source projects is very person/salary heavy.
I think it's a fair point to make...
To be fair - most of these businesses still rely on hiring lots of personnel.
A software company by definition scales better than a consulting company. If the goal indeed is to scale with SAAS like margins then you are going to need a different model than consulting.
That being said, we work with a lot of consulting companies (I even used to run one) called systems integrators. They make good money for their families and are pretty well off. Many of them are also subsidaries of very large conglomerates (Samsung SDS, LG CNS, SK C&C in korea for example)
Those kinds of businesses don't need VC and shouldn't take it. I didn't mean it to be patronizing per se it's just different goals.
Yes there is: you are forcing a false dichotomy on the business world. "Businesses that 'scale'[1]" vs. "businesses that don't" is not a very useful classification, no matter what you call them.
[1] Whatever that means; this has become one of those terms that means whatever the reader/author wants it ti mean.
Some business scale, some don't. Consulting services are around the extreme of "non-scaling" business (the most extreme being specialized consulting), while licensing software is at the "scaling" extreme. There are lots and lots of thing in between.
That's my point. "Scaling" is, well, a scale. It isn't a binary (scale || !scale).
Anyways - FWIW I'm definitely biased. I'm a cofounder of a venture backed YC startup.
Scale here typically means: software you can infinitely copy vs people who get tired.
Personnel cost more than software. Does that make sense?
> Personnel cost more than software. Does that make sense?
Yeah, but that's orthogonal. Needing more people makes scaling harder and more expensive, but doesn't fundamentally change the nature of the business or its goals.
To what degree and how are the business model and the focus of my points here. Eg: open core vs consulting.
This is the term I've always heard for it. It's not insulting. Deloitte or KPMG aren't really... scale. They're huge, but that's not the same as scale. In 2015 Facebook made around the same amount of revenue as them, with like 5% of the employees. And they still have a ton of room to double their userbase, expand into new markets.... What would it take for one of those firms to double their revenue? If they had twice as many customers, could they handle it overnight?
My point is: their model isn't just consulting.
Cloudera is open core for their hadoop distro.
Mesosphere tried closed source with DC/OS and it didn't quite work for them, but they also don't sell consulting.
Docker as a business is also trying to monetize via NON consulting ways.
These companies' goals are all to scale bigger though.
Something to keep in mind though - red hat is a rounding error compared to say: microsoft. A lot of open source investors are looking for an open core model now.
As I described there's different ways to go about it. We chose open core for ourselves though.
Apart from RedHat few companies have been able to make the packaging work as a business model from a financial perspective. Hortonworks shows it is hard to make money with packaging alone http://www.infoworld.com/article/2854359/hadoop/why-hortonwo...
If not, that Red Hat is the outlier (1 company in 20 years) seems to strengthen the prior commenter's point.
Futhermore, the irony of RedHat being the exception that proves the rule that there's far less money in open source, is that its revenue is minuscule when compared to closed-source tech giants.
While I find it unfortunate that GitLab doesn't have it's enterprise edition open sourced, I think they have enough goodwill in the community so that I'm not that angry about it. I would really be interested in hearing from the GitLab folk whether they think making their enterprise edition open source would really hurt their income and if they have any plans on eventually releasing their enterprise edition as open source (again).
TLDR; GitLab has an open core business model.
...
This software and associated documentation files (the "Software") may only be
used if you (and any entity that you represent) have agreed to, and are in
compliance with, the GitLab Subscription Terms of Service, available at
https://about.gitlab.com/terms/#subscription (the “EE Terms”), and otherwise
have a valid GitLab Enterprise Edition subscription for the correct number of
user seats. ...
Isn't this the vision that Stallman had about open source or free software and copy left?
Free Software according to Stallman's vision includes the right to distribute your modifications. You are not allowed to do that with GitLab EE.
This is generally called source available or public source, like the Unreal Engine, rather than open source, which implies you can actually do something with that source code.
[1] https://en.wikipedia.org/wiki/The_Open_Source_Definition
I wouldn't call that goodwill. Some people might be able to personally use the community edition, but no open source project of scale could fathom it with how much groupware functionality is locked behind the proprietary version.
Large free software communities have a choice of course. They can use an alternative (but which one? they are all inferior to GitLab as far as I can see), or they can fork GitLab CE and add the features they need themselves. But let's not kid ourselves that open sourcing GitLab EE is good for the community in the long term.
* Put up a few apt/yum repositories with the EE omnibus packages and charge for access and support.
* Offer private off-prem SaSS.
* Offer on-prem managed hosting for a premium.
* For a hefty premium let companies sponsor features. (i.e Company A needs feature X so they pay you to add it to EE).
The literal software isn't the thing you sell, you sell the ease of use and maintenance.
2 & 3 will pay for some ops people who will have no time for anything but ops work.
4 will pay for 4 devs working on features tops. It suffers from the tragedy of the commons that all sponsor-ware does. Company A will only pay GitLab if they are too desperate to wait for someone else to do it and they think it will be a huge discount compared to doing it themselves and keeping it internal.
1. RedHat does this business model well but it means not having packages for the open source version. Otherwise people will just start a mirror. We want to have great packages for the open source version.
2. We offer this with GitHost.io but it is not very profitable.
3. We try to make sure all management is automated for all our versions.
4. We still offer paying for features at https://about.gitlab.com/development/ There is little interest since if you wait the feature will likely be made at some point anyway. A bit of a bystander effect I think. Also, it is a lot of work to give correct quotes and many didn't get an order because of purchasing processes. Many companies have preferred vendors for software development.
We want the open source version to be easy to use and easy to maintain. So it is not possible for us to charge for that.
I love GitLab, and I hope that some day there will be only one version. as Red Hat saw the light supporting CentOS, maybe GitLab could be able someday to see that enterprises will still pay with only one version
None of these communities have the time or resources to reinvent all the missing bits of EE in CE.
Probably the best answer though is feature incentives. Users (both individual and business) offer money for features to be added (and this can also apply to bug fixes). This is by far the largest untapped market for free software development out there today, and it honestly might be cultural more than anything why this isn't a more popular approach to monetization.
BTW we sponsored feature incentives two times (one for Huboard integration) and it didn't work in either case
We're very interested in having software communities switch to GitLab. If you are part of such an organization and there are features that are missing please email me at sid@ company domain.
A while ago the VLC people mentioned on HN that they wanted the branded homepage and we decided to open source it the same day.
Making the Enterprise Edition open source would really hurt our income and we have no plans to do so. Our idea is that we want to provide great packaging for the open source edition so that people don't need support. So the only thing we can charge for is features.
It's a freemium model. Unlike RedHat, GitLab actually sells software (that you can't trivially get some other way) and not just support/integration services.