Introducing paid subscriptions on GitLab.com | Hacker News Reader

Introducing paid subscriptions on GitLab.com

about.gitlab.com

147 pointsrazer678 comments

I was already starting to resign having to restrict my CI jobs to skip certain long-running but less-important tasks. But:

> The CI usage cap only applies to private projects on GitLab.com. As part of our commitment to the open source community, our goal is to continue to offer unlimited minutes on public projects.

Awesome :)

Paid subscriptions are a really good reason to start using gitlab because it promises that they'll be around in the long run.

I mean, I get what you're trying to say but in no way does a paid subscription "promise" they'll be around any longer than if they were free. Sometimes transitioning from free to paid can backfire and actually shorten the lifespan of a product.

I don't think that's true. Companies that persist in giving away their product have only one route to safety: an exit. A company that charges for its product has an immediate extension of its runway, corporate credibility and both of those add up to being around longer than if they're free.

Transitioning from free to paid can backfire if you depend on the free users for some critical way and gitlab is leaving all that untouched.

They're charging for extras such as support and CI minutes, both of which are features that usually will be of use to corporate customers.

All in all I see this as a positive move for gitlab in the long run, lack of revenue streams was something that bothered me and made me wonder about their long term viability. For me at least those worries are now gone.

They've been selling GitLab Enterprise Edition for quite a while. Were you concerned that this wasn't enough of a revenue stream?

https://about.gitlab.com/gitlab-ee/

Recurring > one time revenue.

EDIT: My knowledge of their pricing is inaccurate. I thought EE was one-time on-prem charge.

GLE is also recurring ($199 / user / year).

But more is better.

Given how fast their free tier was growing, yes.

They're in no holds barred exponential growth territory and I don't know the ratio of corporate customers:free customers but I suspect that the free tier is growing faster. So they really need more sources of income, and preferably b2b ones.

Companies like gitlab become mission critical for the customers that depend on them (one reason why github (not gitlab) is now in the 'too big to fail' category, if they were to go under there would have to be a rescue operation of sorts).

Gitlab has a narrow base and broadening that base is really good.

GitLab as a company has had paying customers for a long time. If you take a look at our web site (https://about.gitlab.com/) you can see some amazing companies who license GitLab EE including IBM, NASA, Nasdaq, Sony and Uber to name just a few.

GitLab.com has become increasingly popular over time and we want to continue to not only provide a great self-hosted product, but also an amazing hosted (SaaS) solution.

There is a difference between having paying customers and being a profitable business. Now, you have access to the gitlab books and I don't but from where I'm sitting the more revenue streams you have the better I feel (because I really like gitlab...), on the off chance that you weren't profitable yet.

Not always. Often a revenue stream costs more time (money) than you get from it.

Note that the above is tricky. There are revenue streams that lose money by the books, but are worth having because they help something else. An example is a store sells milk at (or below) cost because people come for the cheap milk and buy lots of other things.

Yes, there is probably a contrived counter example for every action a company does that allows you to construe that action as a net negative. But on the whole companies are quite smart at allocating their resources, especially scrappy start-ups and given that bit of data you can make the (safe) assumption that they thought this through to make sure that it would not be a negative. For instance, by first asking their customers whether or not they would pay for such a product.

I feel like that's an edge case. Presumably given the stated growth of Gitlab they weren't going to get unlimited resources from Digital Ocean forever so they have to do something to cover the costs and, presumably, attempt to become a business that attempts to make a profit.

This is a common meme, but unless you are privy to the company's internal financials, you really can't say whether a paid subscription model is more sustainable than others. Just ask newspapers and magazines.

There are many products and services I've paid for that are no longer provided.

Sometimes companies even cancel profitable services that are a distraction from their core business.

Having run a couple of companies both with and without an income stream judging by that experience I strongly believe that companies with an income stream are generally speaking more solid than those without. Yes, of course there are odd ducks but as a general rule it is a pretty good one.

And given that this is their core business I don't see them canceling it any time soon.

But is adding this subscription a sign that their previous subscription and other revenue efforts are insufficient, and therefore they are flailing for a viable business model and going under in N months unless this really takes off?

Or is it a sign that they are being conservative and responsible and taking the long view on their finances?

You simply cannot tell from the simple fact that they are adding a subscription option.

Edit: If Google or Facebook added a paid subscription model, would you say: "Paid subscriptions are a really good reason to start using [google/facebook] because it promises that they'll be around in the long run."? Would you interpret that to mean they were likely to be better off in a couple of months?

Profitability is the critical factor, not revenue. The Pets.com CEO /bragged/ about $45 million in revenue - with a loss of $150 million...

No, but you can tell that if this gains adoption that they will be better off than they were last week.

> Edit: If Google or Facebook added a paid subscription model, would you say:

They both do, they sell the ads and users data

Just ask newspapers and magazines.

They never made the majority of their money from subscribers. They made it from ads. And ad revenue has been under heavy assault of late, while publishing has been moving increasingly to the internet and away from the dead tree version. Your example does not really support your statement.

It absolutely supports the statement: where does the majority of gitlab's money come from?

Their strategy page (https://about.gitlab.com/strategy/) suggests that these subscriptions, at least for some time, will be a small part of the revenue (enterprise customers being the larger revenue source).

So with these subscriptions being a supplemental revenue source, it's pretty apt.

Have an upvote for supporting your POV, but I am not convinced that detail makes it apt.

Publications made money primarily from ads. A subscriber base was valuable for being able to prove audience size. Then ad costs were tied to that. Having enterprise customers plus individual customers is fundamentally a different model.

No, but I can tell that a company with a subscription model is more sustainable than the same company without.

With the self hosted CE offering so good, I see no reason to use the SaaS version.

See, that's exactly the reason why I'm happy about this. I figure many people reason exactly like you do and that makes their base possibly thinner than it looks from the outside. So if they can extract more value from the customers they have that's a really good thing.

When I compare gitlab and github I think gitlab is the better open source ecosystem citizen because they give back at least as much as they take but github has the momentum and is better at extracting value (so more solid) at the expense of not being such a good open source ecosystem citizen.

Tough choice just got a little easier.

I don't think this holds as a general rule. A counterexample is App.net.

A b2c social network is not to be compared with a b2b service like gitlab. Totally different monetization possibilities.

I'd argue this is their own fault for failing to establish a business model and expectation of payment. Once you give things away for free for a long period of time and then begin to charge later the blowback is severe. Howerver, if you set expectations upfront, people are less likely to revolt. Note, I am not one of these people because I appreciate and respect paying companies for products that I use and love. I think this stems from my founder's mentality more than anything though.

They have a paid tier, just not for this part of their service.

I have been a huge supporter of gitlab the last few years and have brought it into a few companies. The latest company we opted for their githost.io offering where you get your own instance to avoid the performance issues that they have had with gitlab.com Unfortunately this has really painful with random unannounced outages and the inability to get insight to what is going on when all of a sudden your disk is filling up. Today I woke up to a bunch of messages from developers on my team wondering why it was offline. Only option was to submit a support ticket and hope that I would get a response some time today. It was acknowledged about 2 hours later, but we are still seeing instability. Looking at my ticket history I see that I have filed various tickets every 2-3months for the instance not being available. Not having access to your company git repositories or the CI flow for a day is really unacceptable, and they need to do a lot to show me that throwing money at them will solve it.

Sorry to hear about your issues with GitHost - feel free to share any ticket IDs and we can look into it further on our side.

Tickets from the last year excluding application bugs, that resulted in downtime. I did not get any notification of outages on these. Everything has been resolved and I am very happy with the product when it is working. I get that some of these are due to companies you rely on for your infrastructure.

#26561 Server Not Responding (No reponse for over a day)

#24895 500 on Application Settings (17 hour for response 24 for fix)

#29731 Sever Not Responding (disk full with no warning [actually at 67% but that hangs backups]) Solution expand block storage which failed several times.

#41739 Repositories Unavailable (Githost infrastructure failure moving storage to block storage)

#45163 DNS failure (DYN Attack)

#22524 Expired SSL Certificate

#72593 Server Not Responding (Data Center Outage)

That are a lot of issues, I sorry that you've had all those problems with GitHost.io.

GitHost.io is a service we've offered because GitLab.com was not usable for everyone. One of the problems was the latency of GitLab.com. We're making good progress in fixing that.

Are there other things that keep you on GitHost.io? We've heard that people want LDAP sync and we're planning to bring this to GitLab.com. Is there anything else we should focus on?

Not to be snarky but our instance is still non-responsive.

Sorry about that. We'll have a support engineer reach out now and I'll work with our VP of Eng to look into our SLA for all GitHost customers.

Personally, I think there's a lot of Wizard of Oz going on with gitlab. Put up a decent front so far but utterly incoherent/incompetent behind the scenes.

I don't agree, their product is awesome and they don't seem any more or less incoherent/incompetent than any other startup/small company.

Hi. An off topic.

In page https://about.gitlab.com/products/#comparison it says "Community and support forums only" which is applicable only to "Community Edition". It may better be titled as "Community and support forums" and show the tick mark below every Edition. This could of course save you some time (and money).

Thanks! We fixed it in https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/...

On the page it shows the plan has "All Enterprise Starter features" but there's no obvious link to what the "Enterprise Starter features" are. Had to dig around the site to find it [1].

1: https://about.gitlab.com/products/

Yes, "enterprise starter" is definitely not getting enough exposure. The name is actually so confusing that I wasn't sure if it's some paid trial or an actual product. I once contacted the licensing team asking about that.

This section specifically has the comparisons: https://about.gitlab.com/products/#compare-options

Add we'll add a link to that from the page in https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/...

Update: It is live

Plans don't seem to have a monthly payment instead of annual: https://customers.gitlab.com/subscriptions/new?plan_id=2c92a...

P.S. Why do I need to enter my login again after signing in via Gitlab API?

P.P.S. Group pricing seems unfair. I will be paying 4x for 4 users with the same amount of CI minutes split across 4 users?

We're currently only doing annual billing, we may look into monthly billing in the future.

The billing application is a separate app and effectively oAuths with GitLab - you should just be able to click on the login button and if you are already authenticated, grant permission to the billing app.

Interestingly, we've found little to no correlation between the number of users in a group and CI usage. Moving forward, the plans are going to be much more feature-centric than just CI minutes, hence the per user per month pricing model.

I think if you bill your customers per year it would be fair to list the prices per year as well rather than 'per user per month'. You're setting up an expectation of a monthly billing cycle with the option to cancel monthly as well. Principle of least surprise and all that.

Fair criticism, I've brought it up with the team. Thanks :)

We will fix it in https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/...

Super. That's a pretty quick turn around :)

That's live now, thanks for your help.

https://about.gitlab.com/gitlab-com/

You're more than welcome and I'm super impressed with the speed with which you take feedback like this and put it to work.

I think the GitLab Frontend team should improve this site. The navbar is not aligned correct, missing clearfixes and in general just carelessly put together.

You want my money, so I can at least expect you to provide me with a proper page to pay you. :)

We'll have a look at improving this.

One HUGE drawback is that now free plan is basically Community Edition, and you should pay for Enterprise features such as autosquash commits etc. I thought that Gitlab.com is a showcase of full edition, and you buy it for self hosting if needed.

I've experienced so much downtime and other random outages with GitLab that I would probably just go to GitHub if I was going to pay for something.

We've been doing a huge amount of work on performance and availability over the last number of releases [1] and are continuing to make big advancements in our infrastructure [2] to host millions of projects on GitLab.com. Expect this to be a lot better now and in the future, especially as this marks a big step in GitLab.com's maturity.

[1] https://gitlab.com/groups/gitlab-org/issues?label_name%5B%5D... [2] https://gitlab.com/gitlab-com/infrastructure/issues?scope=al...

I was going to say just this.

I've been between github and gitlab lately, mostly because gitlab had private repos and I'm developing a new FOSS app that I want to release at a later point.

But recently I wanted to create a new simple public repo for a small task and gitlab just refused to work. Eventually there was some sort of ghost repo created that prevented me from using the path I wanted, but it wouldn't show up in my projects.

So to get on with my work I created the repo at github.

Sad because I was really invested in migrating from github.

Legal at my current and I think any company I have worked at would never approve use because of the terms of service. Issues include but may not be limited to unrestricted use of name and logo for promotional purposes, changes to the terms including material ones are without notice or any time period before they take effect, and binding arbitration in The Netherlands. I would have expected the terms to more closely resemble those of the githost.io service.

Besides the legal issues there is the issue of no availability or performance SLAs. Given Gitlab's performance and availability track record this is a non starter. Especially when combined with the annual billing.

Is there an online document, with the current working backup/recovery/verification procedures? I need some type of guarantee that my data is actually safe, and being backed up properly, before I put money into GitLab.

You should ask those questions for any SaaS offering, as well as how easy it is to export all your data.

Particularly ones who only recently learned about proper backup procedures.

We have some relevant issues linked from the Postmortem blog post: https://about.gitlab.com/2017/02/10/postmortem-of-database-o...

Will paid accounts get faster and more responsive service on the website? One of the biggest issues we have with GitLab right now is the speed and reliability of the website and service. Very often (for a service used/depended on daily by our team) the website would be extremely slow to load, and sometimes our CI/CD pipeline would hang.

We've been improving performance for all users over the last year, in the last few weeks we introduced a custom load balancer among other things.

One thing these changes _should_ do is decrease the strain on the shared runners so you don't need to wait as long for the CI/CD pipelines to run. Right now we have some people/projects using a lot more resources than others, which was causing some of the back-up.

We can't really make the site faster only for specific users, and even if we could I don't think we would.

That said, with a proper revenue stream we'll be able to focus more resources toward performance on GitLab.com, so you should see continued improvement.

You can look through our issues labeled performance for GitLab CE[1], the infrastructure issue tracker[2], or our Gitaly project[3] for some examples of progress.

[1]: https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf...

[2]: https://gitlab.com/gitlab-com/infrastructure/issues

[3]: https://gitlab.com/gitlab-org/gitaly

I wanted to add that the problem of the performance of GitLab.com was not because of the revenue but because of our focus and the fast growth. The revenue will help with paying the hosting bills as we keep growing.

And we'll make GitLab.com fast for everyone, including the free users.

GitLab benefits a lot from Azure and DO credits / free usage. Since they will stay in the cloud the costs will be huge looking into the future and I think it's only a matter of time until the private repos won't be free anymore. No company likes to lose money.

I doubt their infrastructure would scale well, even with more income. They still haven't adopt WebSocket/Rails 5, and this would attract more CI runners to DDoS their database.

This sounds like you threw in a few buzzwords. Why would a CI runner DDoS their database? How would WebSockets help them scale?

They doesn't use any long polling method but periodical fetching method for getting pending CI jobs. This causes massive lock on their database, and once it bring down the server entirely.

Per worker? That seems bad, yes.

Heya,

Just wanted to let you know that we introduced long pooling with GitLab Runner version 1.9.0 (~ three months ago).

Also you might want to take a gander at https://about.gitlab.com/2017/04/10/upcoming-runner-changes-... We're throttling older runners.

Interesting. I would be curious to see how this works out. My understanding was that people went to GitLab for the same reason they went to bitbucket - unlimited private repos.

But that's not changing. The free plan retains unlimited private repositories. The only thing that's changing for free is the amount of time they can run CI for free.

As noted in both the article you're commenting on and their (linked in that same article) product[1] site that lists the different plans:

  FREE
  2,000 CI pipeline minutes per month
  Unlimited private projects and collaborators

[1]: https://about.gitlab.com/gitlab-com/

I should have been more clear. (In my mind) The primary reason why people go to gitlab.com was for "free" tier. This is basically for free everything. Now that CI is paid, I am wondering how this will work out.

For me, this is great news. I generally tend to steer away from free (as in beer) products from startups since it is a sure shot sign of things to come (again, personal opinion).

You can still use the CI for free.

CI is still free. For public repos nothing changes related to CI. For private repos, the build time is limited. However, you always can use a custom runner for your private repo to have unlimited minutes.

How do you know how many CI minutes you have used?

The only reason I use GitLab is that they allow me to host private repos for free. Otherwise I'd be using another service, one that's more reliable and has actual users... its name begins with GitHu and ends with b

Seems like this will not change though

Reply on news.ycombinator.com