Building an Open Core Company: Interview with GitLab's CEO | Hacker News Reader

Building an Open Core Company: Interview with GitLab's CEO

about.gitlab.com

290 pointsSiecje139 comments

Hands down the best open source community with a commercial offering I've ever dealt with. The company really clearly gives a $&@"! about what people feel is right and wrong with the product components and has always heard me out - even if people disagreed with me (god forbid I might be wrong about something!).

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!

Thanks, I return your salute.

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!

Gitlab is great stuff, but as a business model for open source, I always considered open core as somewhat toxic. When your community is trying to add features in your commercial implementation, you're "competing with yourself", which in this context, is actually a bad thing. I saw it wreck havoc in the ZenOSS community years ago.

David Neary does a most excellent post on why: https://blogs.gnome.org/bolsh/2010/07/19/rotten-to-the-open-...

Spent a lot of time with Zenoss and also found it sad.

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.)

Yes, we recognize we have to walk a fine line. In https://about.gitlab.com/about/#stewardship we detail our policy regarding this. It starts with "When someone contributes a feature to CE that is already in EE we have a hard decision to make. We hope that people focus on contributing features that are neither in CE nor EE. This way both edits benefit from a new feature and GitLab Inc. don't have to make a hard decision."

Can you explain the "hard decision"?

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?

Both are options and we will make that trade-off according to the criteria mentioned. So far all our decisions were easy (low quality contribution or code copied from EE) but someday we'll have to make a hard decision.

To me the second reason is a serious conflict of interest issue and severely undermines the open source community spirit of your open core. GitLab's Inc would no longer be benevolent dictator for life, just plain old dictator.

well, overall it's better than gitlab is open source than not, and also better that they have money and dedicated developers than not. i wouldn't take away either of these things from the {product,project}

I meant that rejecting an MR is always an option. We will never do that only 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...

I've been impressed with the GitLab founder in every interaction I've had with him. He treats people well and makes an effort to connect with every dev/person interested in his product. He's building a great culture.

Thanks, I'm humbled by your comment. I hope to make it more clear that this is a team effort and I'm a spokesperson.

In the article Sid mentions that "according to research, by 2019 80 cents of every dollar spent on software will go to on premises or single tenant software."

Does anyone know which research he's quoting?

I'd love to know the source too.

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.

Well said. We're also seeing greater demand now for our on premise FOSS software than ever before in the last 7 years.

Yup, this is why at work we have our multi-tenant SaaS using a different database for each tenant. That way if they want to split to self/dedicated-cloud hosting later down the road we can move them without any hassle.

Edit: I describe our thought process here if it's useful to anyone else: https://tomschlick.com/2015/11/29/lessons-from-building-mult...

On prem is the only option for us. Developers don't want to pay (and I don't blame them as a dev) but the people who DO want to pay want everything behind the firewall still.

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.

This is the quote: "By 2019, the cloud software model will account for $1 of every $4.59 spent on software." — IDC Worldwide SaaS and Cloud Software 2015–2019 Forecast and 2014 Vendor Shares

Thank you!

Not data, but for anyone who finds this surprising: I'm going to guess the vast majority of software spending by dollars is on Microsoft, Oracle, SAP, RedHat, etc server products running in closets at traditional small and medium businesses.

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.

The interviewer asks if the community edition is a good funnel into the enterprise edition, but doesn't ask what I see as the converse; which I'd hoped for:

"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!

Good question! Certainly the open source code limits how much you can charge for the product. I think that if there was no open source edition we could sell the Enterprise Edition for more than $39 per user per year. But of course there would be no Enterprise Edition without the open source edition!

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).

Stupid question but couldn't you release it under a license that prohibits selling a hosted version of your software? It wouldn't pass the OSI test but would achieve some goals. Users could self-host if they don't want to pay you but no one can undercut you.

We're not worried about people offering a hosted version, actually we are spending a lot of many scaling GitLab.com to.meet the demand so it would help us.

Most money can be made selling to large organizations that are running it internally.

That's not a stupid question, it's a good answer :)

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.

Thanks.

> Open source is wind in your back.

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.

For sure we think we're punching above our weight. We're less than 100 people and are competing with multi-billion dollar companies likes GitHub.

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.

(vonnik's cofounder here)

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.

This seems like it would preclude people who love what you are doing, but also love to do things after work that aren't around programming.

We get referrals for other roles. But yeah: that's more or less on purpose.

> [Without telemetry] Do you have to rely on users asking for features then?

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?

Two examples:

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.

The true core of GitHub (and GitLab) is Git itself. So both are open core where it really matters. Because both GitHub's and GitLab's essential operations are all done over the Git core, neither code and code history hosted on either system are locked in.

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)

Great interview with a lot of good advice for anyone starting their own OSS-based business.

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.

Thanks for the kind words Mike and thanks for Sidekiq, we use it extensively in GitLab.

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

I was excited to read how open source philosophy is ingrained into Gitlab and how it helps them grow but the article rather skims over it.

This blog post was a writeup of Jason asking me questions because of personal interest. I would be happy to do a 1 hour skype call with you if you promise to write it up afterwards. Please email marketing at our company domain if you're interested. Please link to this comment in your email.

That's great. Thank you. But I am not much of a writer. I was just curious. Maybe somebody else can use this opportunity to write about it.

Yep, everyone can contribute and is free to take me up on that offer.

I was going to try it out after many months... and it is down :( https://twitter.com/gitlabstatus/status/755878196634087424

Sorry about that. We're close to release day and while deploying an RC we got locking transaction for column update across the DB. Edit: it is back online

Is gitlab.com just a demo? I have always found it horrible slow and unstable.

I agree it is too slow. We're working on improving it in https://gitlab.com/gitlab-com/operations/issues/42 (now down)

This release contains improvements that made very long issues load in 2 seconds instead of 6.

Maybe this is a case where ruby is just not the right tool, how does github does it?

honest questions:

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 ;)

This is not due to Ruby, both we and GitHub use that. We do offload some tasks to Go processes with GitLab workhorse to take advantage of multithreading. But therr are a few reasons GitLab.com is slow:

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.

> Isn't gitlab highly concerned with a new company starting a similar product in a more efficient language implementation and eating your lunch?

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.

Lots of companies use Jira for issues and Github/Gitlab for code. It's a painful divide. Do Gitlab and/or Github have plans to rescue such companies from that situation?

Take a look at GitLab's plan for Issue Boards (https://gitlab.com/gitlab-org/gitlab-ce/issues/17907). It's not quite Jira, more like Trello, but a great step in solving modern issue management and planning.

Any chance GitLab will add Mercurial support?

Almost no chance, if anything we would add SVN support but I think that is already too much technical complexity.

Consider using https://rhodecode.com/

Why SVN over Mercurial?

There are more people using SVN than Mercurial.

I saw somewhere else that you used Google trends to show how git was more popular than Mercurial. However you didn't consider "hg". Here is the trend for Mercurial vs SNV

https://www.google.ca/trends/explore#q=svn%2C%20hg%2C%20Merc...

Here's the open source definition:

https://opensource.org/osd-annotated

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.

I'll point out that merely being the first to claim "opensource.org" does not allow one to define what the word means for the community at large.

Four your (historical) interest, the OSI people (opensource.org) invented the term 'open source':

https://web.archive.org/web/20060924132022/http://www.openso...

'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.

Creating a phrase does not mean you get to define how the community uses it. The guy who invented gif doesn't really seem to get much say in it's pronunciation. In America, almost all people call tissues "Kleenex" regardless of brand. In the UK, I hear all vacuums are called "Hoovers" regardless. People can use a specific brand "Open source" to mean generically all software with source code available.

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.

Right. In the same way that Alan Kay's definition of "Object Oriented" doesn't match that of the programmer community at large.

Creating a phrase does not mean you get to define how the community uses it.

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.

Id agree with that. Sometimes people use it in ways even they don't agree with, but would agree that it's more accurate than just straight "closed source". Is source available "more open" than something completely closed?

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.

I'm not expressing any opinion on the question of whether GitLab is or is not an open source company, but:

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.

That is absurd. If Gitlab and Microsoft were equivalent, Windows 10 Home would be completely open-source under GPL. Advanced features like connecting to the domain, full disk encryption, and Hyper-V hosting would be "Enterprise".

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.

Isn't Gitlab EE open source ? In wich case, what is this repo : https://gitlab.com/gitlab-org/gitlab-ee/ ?

It is not. Please read the first sentence of the license: https://gitlab.com/gitlab-org/gitlab-ee/blob/master/LICENSE#...

Here is how open source is officially defined: https://opensource.org/osd-annotated

Edit:

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.

What's stopping someone from simply cloning that directory and putting it on their servers like with the Gitlab community version? How do they enforce the subscription access?

It's simply illegal to do that. A private person may do something like that (even it's illegal), but I can't think of a serious company which uses priated software.

The source is publicly viewable but neither Free Software or Open Source.

GitLab EE is closed source, but publicly viewable and the license allows for modifications, but you need to be a customer

https://gitlab.com/gitlab-org/gitlab-ee/blob/master/LICENSE "have a valid GitLab Enterprise Edition subscription for the correct number of user seats"

GitLab Enterprise Edition (EE) is closed source and we try to be clear about having an open core business model. I amended the blog post to reflect it too https://gitlab.com/gitlab-com/www-gitlab-com/commit/e333cc93...

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

I feel that the company follows an open source belief rather than a model. When you say this:

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.

I do believe that open source is more than a license. It is a way of working. That is why all our issue trackers are public, including the GitLab EE one with customer requests https://gitlab.com/gitlab-org/gitlab-ee/issues and for example our marketing team https://gitlab.com/gitlab-com/marketing/issues

We also try to open up as much as we can, including our company handbook https://about.gitlab.com/handbook/

I share the same belief. It is a powerful motivator. It attracts others into the open source community. But we must be careful when dealing with beliefs and legal matters. I can't call asimuv an open source project because I do not meet the definition. I do support open source projects and have a pipeline full of them. In the end, this is our idealism being mixed in with business. It is a tough place to be in. I'd rather support companies that have an open core rather than those that do not.

All open-source companies close-source some code, or else they struggle, because services don't scale. Red Hat's security layer is not open-source. Cloudera is an explicitly open-core company. So is my startup, Skymind.[1][2] There's no other way to do it. But there is a way to be honest about it, and I think sytse is being honest. You can't give it all away for free. If you do, you're probably not a company...

[1] https://skymind.io/ [2] http://deeplearning4j.org/

SAAS is a viable revenue model, but it takes a long time to scale. If you are looking at "lifestyle" business, you can still do open source and make make money too. Thats what we do at ERPNext

I agree with you. When I say services, I'm actually talking about the consulting work that accompanies enterprise software sales, where you end up acting as an outsourced engineering team for your clients.

Ok, we s/source/core/'d the title above since that use of "open source" is disputed. But I wish you had omitted this:

> 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.

I'm sorry but that is an utterly ridiculous comparison.

Lot's of griping in here about whether or not GitLab is really 'open source'. Typical HN vitriol. I think GitLab is doing fantastic work pushing forward open source philosophies with real world execution. They're putting a lot of their money where their mouth is. Hell, you can clone their ENTIRE corporate website. On top of that, the product they offer (yes, their free, Open Source community edition) is _fantastic_ and continues to improve with each release. I am constantly impressed with how this company operates, and am always trying to roll in more of that to my own company (their Handbook for example is fantastic.)

Thanks Nick! We really try to ensure that the open source edition of GitLab allows you to run a performant and secure 'forge' without any artificial limits. And thanks for noticing our website is licensed under Creative Commons Attribution-ShareAlike

Why is it that the top comment of every debate on HN is without fail something along the lines of "I'm shocked at the negativity here..."?

This cliche is beginning to get a little worn.

You likely know that HN doesn't sort in chronological order, so the negativity probably gets downvoted to the bottom while the complaint remains at the top.

It would be nice if we could skip this whole multi-layered meta discussion in the first place, of course.

I agree, but it's also especially shocking anyone would be negative about Gitlab.

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/).

In the interest of objectivity, I'd change the title to read "Open Core" instead of "Open Source"

Interesting, I never considered called us an open core business, but I agree it is more accurate and edited the blog post in https://gitlab.com/gitlab-com/www-gitlab-com/commit/e333cc93...

I'm considering this blog post https://gitlab.com/gitlab-com/blog-posts/issues/226 to set the record straight, what do you think?

I just published it https://about.gitlab.com/2016/07/20/gitlab-is-open-core-gith...

And this is why GitLab stands out among all others. There's the no-compromises hardcore folks (more power to them/us!), and then there's the obnoxious whatever-for-business folks who don't care about community or ethics or feedback really. GitLab is amazing in just actually listening. Look at this, they went and took the suggestion and care more about honesty and transparency than in the short-term short-sighted impact of insisting their initial wording was right… this is typical of this company that really does listen. Bravo

Thanks quadrangle for your supportive comment! After reading part of the book 'domain driven design' I'm very keen on ensuring all wording is unambiguous, and the suggestion to call it open core was spot on. I added the open core business model to https://about.gitlab.com/about/#stewardship too in https://gitlab.com/gitlab-com/www-gitlab-com/commit/f81934f7...

Ok, we've done that above.

I am baffled by this editorializing change. Can you explain the philosophy behind it?

The CEO of GitLab is fine with it (https://news.ycombinator.com/item?id=12129755) and it gets us off the but not 100% of everything is open source train to an actual discussion

wlesieutre answered this well. I also commented about it here: https://news.ycombinator.com/item?id=12130562.

Thanks for the change Daniel! It really helped the conversation here. We'll publish a blog post in minutes where we'll go on the record about being open core https://gitlab.com/gitlab-com/www-gitlab-com/commit/85ff2a84...

I'm interested to hear your reasoning around this if you get a moment. I think ts very clearly an open source product - all the installers regardless of what 'edition' you choose to deploy are available without any paywall or login via their yum / apt repos, all the code is within them and open to contribute to and inspect.

Gitlab are not an open source company. Their primary revenue generation stream is proprietary software.

Care to elaborate? Isn't their primary source of revenue gitlab(-ee) which is open source?

Open "core". There are a lot of open source companies (including mine) that have proprietary addons they sell.

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.

'lifestyle business' is very patronising. Do you think all companies that can't scale massively such as consultancies are lifestyle businesses? What about something like Deloitte or KPMG? Are they just there as part of the lifestyle of the founders?

I think the point is that pure open source tools often don't allow the founder(s)/maintainers to really grow out the company to large scale.

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...

Sure - and there's nothing wrong with that. Look at patio11 before he started starfighter. You could call it "bootstrapped business". Those companies still take a long time to build.

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.

> Sure - and there's nothing wrong with that.

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.

What?

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.

> 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).

http://www.paulgraham.com/growth.html

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?

I agree startup == growth. I don't agree that making generalizations about !startup is useful.

> 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.

The "goals" include "how" to make money though. It's defined right in the business model. Every businesses' goal is "technically" to "make money" to "survive".

To what degree and how are the business model and the focus of my points here. Eg: open core vs consulting.

> Do you think all companies that can't scale massively such as consultancies are lifestyle businesses?

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?

Wasn't aware Red Hat was a lifestyle business. That is a pretty big lifestyle with the billions of revenue.

Red hat sells updates to their software + packaging. Horton also does this. They also sell apps on top of their platform.

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.

At GitLab we considered to charge for the packaging (our Omnibus packages and the package server). We decided to go for a GitLab version that was 100% open source and easy to install and a GitLab version that was closed source, contained additional features and was equally easy to install.

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...

I agree completely. We have pretty similar business models after all ;). We've been going upstream selling a "distro" usually with other stuff bundled in.

Could you cite any other example(s)?

If not, that Red Hat is the outlier (1 company in 20 years) seems to strengthen the prior commenter's point.

MySQL AB before the Oracle acquisition. Troll Tech before Nokia. They did sell licenses for proprietary use, but what was sold was completely open source (under a viral license).

Neither of those have revenue close to RedHat.

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.

AFAIK, the enterprise edition (EE) used to be open source but is now closed [1]. There is an open source "community edition" which has many of the features of the enterprise edition, including self hosting, but lacks others [2].

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.

[1] https://en.wikipedia.org/wiki/GitLab#History

[2] https://about.gitlab.com/features/

I thought the EE was open source: https://gitlab.com/gitlab-org/gitlab-ee

From the LICENSE file [1] to your link:

    ...
    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. ...

[1] https://gitlab.com/gitlab-org/gitlab-ee/blob/master/LICENSE

you can look at the source, but it is not "open source": https://gitlab.com/gitlab-org/gitlab-ee/blob/master/LICENSE

Isn't that open source though? Sure you have to pay, but you get access to the source and you can modify it and use your modified version as long as you pay.

Isn't this the vision that Stallman had about open source or free software and copy left?

I would consider this Open Source, but not Free Software.

Free Software according to Stallman's vision includes the right to distribute your modifications. You are not allowed to do that with GitLab EE.

There is a canonical definition of open source by the OSI[1]

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

You could modify it if you wanted, but the best way is to submit a Merge Request on GitLab.com, otherwise you will need to maintain a fork of GitLab (which might be a trouble to maintain depending on the changes).

You can only modify it legally if you have an active license though, assuming I'm reading the software license correctly.

If Gitlab EE was open source, they would have seen broad adoption in a lot of free software communities because the quality is much higher than the existing infrastructure (think Gnome, KDE, Freedesktop.org, Apache, maybe even smaller projects like Document Foundation and VideoLAN). However, they made crucial functionality all these projects depend on, like LDAP support, proprietary. So we are still in this situation where most open source ecosystems are running horrible old or outdated infrastructure with random bug trackers and mediawiki on the side, or much less intuitive systems for multi-project ecosystems like Phabricator (which is what KDE is switching to).

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.

But suppose they do open source EE. How do they make money then? They can't pay employees with "thanks" from the community. Donations don't cut it. Consultancy doesn't scale; see the other discussion thread. GitLab would go under or would have to be forced to scale back development significantly. I don't think anybody really benefits from that long-term.

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.

They could still sell EE even if it's open source.

* 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.

Especially if they licensed EE under AGPL, very few companies would touch it to host private repos.

1 won't last. Some random dev out there will manually replicate it for free as a side project.

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.

Thanks for the thinking about how to make this sustainable. Some thoughts of me:

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.

Well, we can call CentOS an opensource packaged version of RHEL (binaries not only SRPMS) by Red Hat. CentOS is now (two years iirc) a Red Hat project

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

I think RedHat lost the server market to Ubuntu by not offering an open source package (server). We want GitLab users to have a great install and upgrade experience with the open source version. The tradeoff is that the open source version won't contain all the features. For more background please see about.gitlab.com/about/#stewardship

I never liked that gitlab made gitlab.com hosted private repos free. That is a perfectly good revenue stream for them, to provide private repo hosting, that they gave up on to crush the ability for their product to ever be viable in open source communities.

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.

In the first year of GitLab as a company we tried to monetize the SaaS but if didn't work.

BTW we sponsored feature incentives two times (one for Huboard integration) and it didn't work in either case

GitLab CE contains everything to run a large forge including LDAP support for logging in (LDAP group sync is EE only).

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.

Thanks, I agree with the TLDR. Note that our Enterprise Edition has always been closed source.

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.

GitLab EE is not open source as far as I can tell. GitLab CE is, but it has fewer 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.

GitLab EE is proprietary.

I'm willing to bet they contribute more open source code, more often and more transparently than anything nearly as successful and extensive.

Reply on news.ycombinator.com