Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introducing paid subscriptions on GitLab.com

about.gitlab.com

Post reply on HN
Print view View original

31–40 of 81 posts

Re: Introducing paid subscriptions on GitLab.com

#31

Post by mydigitalself »

mizzao wrote: post #27

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

Re: Introducing paid subscriptions on GitLab.com

#32

Post by newsat13 »

daenney wrote: post #29
newsat13 wrote: post #28

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…

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

Re: Introducing paid subscriptions on GitLab.com

#33

Post by Vinnl »

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

Re: Introducing paid subscriptions on GitLab.com

#34

Post by EduardoBautista »

newsat13 wrote: post #32
daenney wrote: post #29

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

You can still use the CI for free.

Re: Introducing paid subscriptions on GitLab.com

#36

Post by jacquesm »

a3_nm wrote: post #35
jacquesm wrote: post #2

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

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.

Re: Introducing paid subscriptions on GitLab.com

#37

Post by mydigitalself »

btashton wrote: post #30

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 fillin…

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.

Re: Introducing paid subscriptions on GitLab.com

#38

Post by jd007 »

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.

Re: Introducing paid subscriptions on GitLab.com

#39

Post by connorshea »

jacquesm wrote: post #19
mydigitalself wrote: post #14

Earlier quoted context omitted.

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, t…

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

Re: Introducing paid subscriptions on GitLab.com

#40

Post by connorshea »

jd007 wrote: post #38

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

Post reply on HN