Hacker News Reader

"That knowledge about GitLab left a weird and confused taste in me. It gives me an impression, that is if a free tier user becomes inactive, they're no longer valuable for GitLab and can be treated as second-tier."

GitLab has an explicit program for approved Open Source projects:

https://about.gitlab.com/handbook/marketing/community-relati...

This is their philanthropic effort. They need to remain financially solvent to provide anything long term, so of course they need to be careful how much they're giving away and for how long.

If you're not in the approved open source program, you should consider your usage of the "Free Tier" as part of their freemium business model whereby they hope to convert you at some point into a paying customer.

> GitLab should seriously re-learn what's more important for their service: user engagement or the code hosted on it.

They're a business that needs to pay the builds (including the long-term costs of storage). If they haven't approved your projects into their open source program, you should consider paying them to host the code.

I have my own issues with GitLab, but I won't judge them for the need to pay the bills.

I do understand that they need pay for their running cost, but to be completely honest, I don't think that they're running the business in a smart way.

When GitHub took off, they were not offering private repository at all. Instead, they added it in slowly when they can afford to do so. This is one of the reason why GitHub has now become the #1 platform for open source projects around the world.

GitLab is trying a different approach by focusing on offering repository hosting as service, but as time progresses and GitHub grows, this business model became less and less attractive. As a result of it, now days GitLab mainly attracts people who thinks GitHub isn't the right option for them, and that's not a big market. No matter how many cost they cut, if this remain unchanged, GitLab is already on it's dead bed (by that, I mean stop growing, not close for business).

GitHub is smart because at very beginning (before allowing private repositories), they knew that if they want to attract good programmers and projects, they must also accept and respect garbage, because that's what it takes to build their trust.

Deleting user data however, always destroy trust. If storing those repositories creates unbearable cost for GitLab, then maybe introduce a reasonable cap and then rejects new commits once the cap is exceeded (while asking user to buy more spaces). Making the entire repository just disappear is too much.

I'm glad that they did not end up choosing that route, but at the same time, not choosing that route should be the default, not something you just realized after it went to the media.

I was a paying GitHub customer, but they had such a crummy private repo policy at the time (I think only 5 private repos were allowed) it forced me to make poor technical decisions: "I'll delete this github repo, keep my local copy, to open up a slot." I switched all my private repos to gitlab and stopped paying for github and was happier for it.

Later github changed its policy to something saner, but I never switched back to using github for private repos. This decision by gitlab even if it's rescinded, however, might give me the impetus to do so.

I'm doing the same for the 5 user limit on GitLab currently.

But the pricing is just too steep for me to justify setting up, e.g. an extra user for some automated tasks.

You shouldn't need a user account for automated tasks, that's what webhooks and deploy keys are for.

I don’t know if this issue has been resolved, but as late as four years ago, GitLab didn’t have a notion of a service user. If you wanted a server to authenticate and pull from a private repo, you had to use a licensed account to do so. This meant your 5 user tier became a 4 user tier.

Project access tokens (https://docs.gitlab.com/ee/user/project/settings/project_acc...) is what you need and they have been around for 2+ years

I had forgotten why I default every little hello world type repo I create on GitHub to public. I knew there was a reason I started doing that but had forgotten.

The five slots were precious and I didn't want to waste them.

Which, of course, was entirely their goal: to get more public content to increase the network effect.

Gitlab's approach also sounds like an easy way to hijack dormant projects to inject malicious code and let unsuspecting users download "updates"

Except that projects are namespaced under their owner, so you'd need to hijack the owner's account. They don't appear to have been proposing deleting users (or groups), just projects.

Other than that, you can fork whatever you want today...

OP is talking about obtaining an username from an inactive user. If they were able to obtain the username, they effective took over the namespace.

> It gives me an impression, that is if a free tier user becomes inactive, they're no longer valuable for GitLab and can be treated as second-tier.

You can't, without paying, sit on a namespace for years and do nothing with it, if there is interest from a user willing to pay. And even if that is what you're doing, gitlab will contact you before taking back the account to make sure you don't suffer data loss. I don't know, this seems pretty reasonable to me, especially considering gitlab is a business and provides you with a free service.

You just have to log in more than once every two years!

I don't blame Gitlab for not understanding the levels of self-entitlement of some of its free users. And maybe, just maybe, Gitlab is better off without those users. In my experience, the cheap customers were always the worst and most demanding.