I truly have grown to love GitLab and the team that develops and supports it, it's probably the fastest moving OSS project I've ever seen, and every release is clearly getting better (although there are some UI changes recently that bug me, but that might just be me).
Thank you yet again everyone involved with gitlab and it's varying components (especially gitlab-CI) both internally within the company and those contributing either code or conversations from around the world.
Gitlab has enabled us @infoxchange to move faster than ever before, with a low TCO and a responsive support team.
I salute you!
It is great to know that GitLab is contributing to your not-for-profit with its 'technology for social justice' mission.
We also heard from other people that the navigation redesign is not ideal. I think the big picture change is welcome but some things are taking too many clicks. But we would love more feedback with examples. The thinking behind our navigation redesign is detailed in https://about.gitlab.com/2016/06/06/navigation-redesign/ Please comment on that blog post (or create an issue) with what we can improve.
Thanks for your kind words, we'll keep shipping!
David Neary does a most excellent post on why:
Is it that you have to choose between two implementations for the same or overlapping features, meaning someone's work gets thrown out?
Or do you mean that you have to decide whether to reject the freely offered CE pull request because it undermines the value-add of EE?
As stated on https://about.gitlab.com/about/#stewardship we will consider multiple factors.
I just updated these factors to make sure everything that comes to mind is listed there in https://gitlab.com/gitlab-com/www-gitlab-com/commit/8e22bb93...
That said I thonk open core us possible and one of a few good business models that can work with open source.
I hope and believe Gitlab can and will do much better as Gitlabs commercial offerings are way more reasonably priced IIRC.
(Another brilliant example would be sandstorm who openly admit that all enterprise features are in there, explain where the one big if switch is, says it is not illegal but expect you to not do it if you can afford to pay for it. Again IIRC.)
Does anyone know which research he's quoting?
But this matches what I am seeing right now as well as predicting for the future.
SaaS is a powerful distribution model but IaaS has gotten so good that it's in many ways easier to run many small things than one big thing. And when you run many small things huge benefits arise:
* security and isolation. Single tenant by default.
* control. Upgrade when it's convenient for your company, not your provider.
* Cost efficiency. Freemium SaaS requires burning VC cash. Open source + self serve demo doesn't
* customization. Set your own feature flags or add your own patches to fit the software to your business
Everything is cyclical. I think "install this software on your [cloud] computer" is going to be a big trend again.
Edit: I describe our thought process here if it's useful to anyone else: https://tomschlick.com/2015/11/29/lessons-from-building-mult...
Hybrid cloud is sort of being looked at but the rest of the world is still happy being on prem. Certain workloads have to be behind the firewall.
That being said, docker and the like is making this easier.
Outside the tech world, it's a good bet that any given business has a Windows Server variant with Exchange onsite (little battery UPS likely, fancy fire suppression or HVAC pretty unlikely) and Office licenses on every desktop. If there's virtualization it's VMWare. If they allow telecommuting at all it's probably Citrix.
The view of the tech world from SV, and from an IT contractor with a staff of ~45 acting as the IT department for ~500ish local firms in a sleepy Midwestern city, are very different.
"Does making the source available restrict pricing options, or completely lose would-be users - or would self-hosters never be customers anyway?"
This has been bugging me and holding me off a project that I'd like to be open-source; I just can't help wondering what stops someone from thinking "well I'm just going to host your source code, and undercut you". I'm all for a competitive market - but not if I do all the work and we only compete on how to price it!
People have started hosting business based on GitLab CE and we encourage that. Most find out what we found out in 2013, it is much easier to generate revenue with software licenses than with SaaS products due to the different audiences (large vs. small organization).
I suppose I wouldn't expect to be able to (afford to) defend it, but I imagine being in breach of a licence would be deterrent enough for anyone looking to operate at anything but trivial (that is ignorable; not a threat) scale.
Most money can be made selling to large organizations that are running it internally.
So true. Open source lets small engineering teams punch above their weight. Thousands of extra eye balls on the code for QA make it so much better. And the project-user feedback loop is fast.
Some other benefits of our open core model:
1. Remote only is the default way of working, allowing us to hire great people around the world.
2. Our open core model attracts great people, it is rare to have no recruiting problem for engineering.
3. Our technical interview is adding a feature to GitLab, ensuring we test exactly the skills we need when you join.
We don't have a careers page on purpose. Right now the best hires either come from very strong referrals or fall in to our lap via the oss community. People who ask us about hiring: we just tell them to join the oss community.
It saves us a lot of time.
How does telemetry affect that? I can see that you would maybe prioritize work on improving different features depending on what gets used most or what crashes most, but how should telemetry help you decide what features to include?
1. You might find that some parts are more heavily used than you thought (for example the wiki) and you prioritize making them better.
2. You find that many people use CI and not many use CD so you add features to make the transition easier.
Where GitHub has slightly more lock-in and is less open than GitLab is its Issues system; One can only extract the data (via API) for import into an alternative system, whereas with GitLab you could run your own copy of the open source code (but you'd still have to do the data export-import as far as I can tell).
(copied my comment from a duplicate thread)
Making EE "open source" (not "Open Source") is a brave move but I think anyone who's done this work before knows that having the source available for viewing doesn't really matter much to actual customers with money - a packaged solution with long-term support and legal compliance are their main concerns.
We decided to package GitLab Community Edition to make it very quick to install. So our open source users get the same easy installation and the same security updates and our Enterprise Edition customers.
We find that large enterprises are interested in some of the features https://about.gitlab.com/features/#compare and not in any of the other things. Maybe the best example is a user if China with more than 6000 developers that decided to copy the code of some features over to the Community Edition. This is illegal if you don't have a subscription but I think it shows that the features do matter. Our policy is to put features that are more useful if you have more than 100 users in the Enterprise Edition https://about.gitlab.com/about/#stewardship
This release contains improvements that made very long issues load in 2 seconds instead of 6.
Is performance not that important for gitlab cause your revenue comes from self-hosted, where performance might be less of an issue because of lower load?
Isn't gitlab highly concerned with a new company starting a similar product in a more efficient language implementation and eating your lunch?
apologize if these questions sound a bit harsh, gitlab is doing great work and lots of users enjoy your product, I guess these is one of the perks for exposing yourself too much to the community ;)
1. I didn't prioritize growing our infrastructure team after raising our A round, for a long time it was one person running GitLab.com. In the last couple of months I realized my error and now we're about 8 people and hiring.
2. We're shipping a lot of new features every month and we where not monitoring for performance regressions. We have better monitoring in place now.
3. GitLab.com runs on one file server. This release adds the capability to add multiple ones. We are also testing Ceph to make it completely distributed.
4. Some problems only occur at scale. GitLab.com is running GitLab Enterprise Edition with more than 500k accounts created. This causes problems that don't occur at 10k users.
5. Our monitoring infrastructure has been coarse. We're now using Prometheus to improve this.
I'm nobody but my two cents is that this falls under the category of things we shouldn't worry about because there isn't much we can do about it. I am sure Gitlab is concerned but I would say it doesn't matter because this is a problem you can probably throw hardware at (repo A going down will likely not affect most repo B users). I imagine of course gitlab.com would want to make the most of the hardware it has and I'd love to read about the cost of porting gitlab to a "more efficient" language implementation but I hope they're more concerned about delivering value to users than worrying about how to fend off competition.
This might be unpopular here but I hope Gitlab does all it can to keep their cost low even if it means slightly lower salaries.
Consider using https://rhodecode.com/
Gitlab EE, which is how Gitlab makes its money, comes nowhere close to meeting that. It's pretty much straight up corporate dishonesty to pretend to be an open source company when you're following a proprietary software model to make money.
You're no more an "Open Source Company" than Apple or Microsoft, who also have some open source projects separate from their main revenue streams.
When I think about our company I do think of it as an open source company. 80% of the work and features are shipped in GitLab Community Edition and the majority of our users are using the open source edition.
If I google 'open source companies' the first hit is http://thevarguy.com/open-source-application-software-compan... I think a number of these have an open core business model.
The first ten blue links also point to http://www.zdnet.com/article/why-microsoft-is-turning-into-a... I don't think about Microsoft as being open source, but I think you can be a open source company and still ship propietary code.
If you want to know more about how try to balance the open source code with the need for a business model and our promises please see https://about.gitlab.com/about/#stewardship
When I think about our company I do think of it as an open source company.
It confirms that some of us might share the same feeling.
We also try to open up as much as we can, including our company handbook https://about.gitlab.com/handbook/
Conversely, for Gitlab to be as closed as Microsoft, their entire product would be closed, except for the source code they use to color labels in issues, or perhaps they'd hand out the spec to their flavor of Markdown.
Here is how open source is officially defined: https://opensource.org/osd-annotated
I did not downvote you. Your point is valid because it reflects a common view in the community. Asking questions should not be punished. Please consider this before downvoting the comment above.
https://gitlab.com/gitlab-org/gitlab-ee/blob/master/LICENSE "have a valid GitLab Enterprise Edition subscription for the correct number of
> It's pretty much straight up corporate dishonesty
That's uncharitable and on the wrong side of the HN guideline against name-calling. Please err on the other side instead. In addition to making the community more civil, it will make your arguments stronger; as for example your last sentence was the stronger argument here.
A more charitable comment would also not have spoken of "the" definition of open-source, a notoriously protean term.
Opensource.org isn't just some random website by a random dude. It was setup by (among others) the very same guy that invented the phrase "open source". It should rightfully be considered the canonical definition of open source.
In my experience there is also a group of people that simply don't care about exact definitions or legal implications. They have this overly simplistic view that having access to the source code is all there is to it to be "open source". That's probably the group of people you refer to when you say "the community at large". I have no idea how big group is, or whether it is big at all. But I do think they are wrong.
I've noticed that some (not all) of the people in this group use the term "open source" for marketing purposes. Sadly, it is a term that attracts uninformed eyeballs.
'Free software' was considered to be too scary for businesses and the rest is history. So, in other words, yes they have a say in this. The made the label with the associated definition.
Languages evolve and while opensource.org may have originated the term, common use dictates that the definition of "open source" isn't as strict as the original definition.
I don't disagree, but it's also up to the tech community to keep terms clean/accurate. Even if you don't follow the OSI definition, I think 'open source' clearly points to a set of licenses for most in the developer community.
When the term became popular, lot of companies tried to piggyback on the success of the name, trying to dilute it.
The latest Unreal for instance. It's not closed source, because you can in fact see the source, and it wouldnt be fair to compare it to other engines/games that are just a pure black box. But yet, the licensing is restrictive. So its not truly "open source" but Ive heard some people call it open source meaning "not closed" when in reality it is somewhere in between - "source available".
In those cases, the definition is not really as important as people seem to make it out to be. I'm speaking casually and colloquially here.
And I would say that Gitlab CE is open source. And consequently, Gitlab EE is MOSTLY open source. From my understanding, its essentially gitlab CE with some closed source plugins. I dont really care where they make their money. I interact with Gitlab CE primarily, and it is the core product. Calling them an open source company is not like calling Microsoft an open source company "because microsoft has some random open source products".
My entire point being that getting bent out of shape over minor semantics is weird. Not 100% of gitlab is open source, and they make most of their money off that closed source bit, but I would venture to say that most of their users (by volume, not by revenue) deal with the open source part only.
This cliche is beginning to get a little worn.
Take it from an adamant free software user, contributor and advocate: "Free software purism" is counter-productive and it's honestly disgusting anyone would wag their finger at Gitlab, possibly the most open source example of a real world company out there (yeah, I'd even put them above Red Hat). They have been a model to follow, an extremely inspiring one at that.
Maybe I'm wrong and it's exclusively HN's top paragons of virtue raising their eyebrows? Those that have evolved beyond mortal needs such as money to spend on food and rent, and would be ready to pledge their own possessions to Gitlab Inc (or at the very least, donate to the EFF: https://supporters.eff.org/donate/).
It would be nice if we could skip this whole multi-layered meta discussion in the first place, of course.
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.
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.
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...
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?
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'" vs. "businesses that don't" is not a very useful classification, no matter what you call them.
 Whatever that means; this has become one of those terms that means whatever the reader/author wants it ti mean.
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.
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).
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.
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.
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?
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.
Free Software according to Stallman's vision includes the right to distribute your modifications. You are not allowed to do that with GitLab EE.
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.
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
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.
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.
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.