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.
Introducing paid subscriptions on GitLab.com
41–50 of 81 posts
Re: Introducing paid subscriptions on GitLab.com
#42On 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/
This section specifically has the comparisons: https://about.gitlab.com/products/#compare-options
Re: Introducing paid subscriptions on GitLab.com
#43Plans 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?
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. :)
Re: Introducing paid subscriptions on GitLab.com
#44Is 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.
We have some relevant issues linked from the Postmortem blog post: https://about.gitlab.com/2017/02/10/postmortem-of-database-o...
Re: Introducing paid subscriptions on GitLab.com
#45Earlier quoted context omitted.
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…
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).
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.
Re: Introducing paid subscriptions on GitLab.com
#46On 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/
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
Re: Introducing paid subscriptions on GitLab.com
#47Earlier quoted context omitted.
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/...
Re: Introducing paid subscriptions on GitLab.com
#48Re: Introducing paid subscriptions on GitLab.com
#49Earlier quoted context omitted.
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...
Re: Introducing paid subscriptions on GitLab.com
#50Will 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…
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.