5 ms·

Few years ago, I tried to un-squatting an username from both GitLab and GitHub (yes, GitHub were doing this back then), both with success. During the attempt I

by nirui 4y ago

Few years ago, I tried to un-squatting an username from both GitLab and GitHub (yes, GitHub were doing this back then), both with success. During the attempt I studied the policies for both service and noticed the difference between the two: For GitHub, they were lean towards not to release the username especially when the account is valid and not "empty"; For GitLab however, they will release the username if the account was inactive (not pushing/posting issues/login etc) for a period of time (See [1]). [1]: https://about.gitlab.com/support/gitlab-com-policies/#name-squatting-policy https://about.gitlab.com/support/gitlab-com-policies/#name-s... 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. For that reason, I cannot seriously being myself to use GitLab. If you knew that all of your investments will rot to nothing as soon as you stopped paying, you'll probably consider to stop investing it. Sadly, this idea of removing "dormant" projects followed the same train of logic: If you're not constantly contributing (paying/publising content) to our platform, you're second-tier, and we can just kick you out. From the previous article where they announced the plan: > GitLab is aware of the potential for angry opposition to the plan, and will therefore give users weeks or months of warning before deleting their work... GitLab don't seemed to understand their users well. "Angry opposition" is what might happen if GitHub decides to remove dormant repositories, not GitLab. GitLab users will just feel disappointed and leave (to self-hosting, or maybe host it (back) on GitHub). GitLab should seriously re-learn what's more important for their service: user engagement or the code hosted on it. Tip: GitLab is not running a social network business.

trinovantes 4y ago
Gitlab's approach also sounds like an easy way to hijack dormant projects to inject malicious code and let unsuspecting users download "updates"
- L6489afSMNLNFDa 4y ago
  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...
  - trinovantes 4y ago
    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.
shizzy0 4y ago
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.
- pooper 4y ago
  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.
  - L6489afSMNLNFDa 4y ago
    Which, of course, was entirely their goal: to get more public content to increase the network effect.
- benjymo 4y ago
  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.
  - will-bradley 4y ago
    You shouldn't need a user account for automated tasks, that's what webhooks and deploy keys are for.
    - clintonb 4y ago
      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.
Ironlikebike 4y ago
"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-relations/opensource-program/ 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.
- nirui 4y ago
  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.
Lutger 4y ago
> 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.

by nirui 4y ago

trinovantes 4y ago

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

L6489afSMNLNFDa 4y ago
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...
- trinovantes 4y ago
  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.

shizzy0 4y ago

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.

pooper 4y ago
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.
- L6489afSMNLNFDa 4y ago
  Which, of course, was entirely their goal: to get more public content to increase the network effect.
benjymo 4y ago
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.
- will-bradley 4y ago
  You shouldn't need a user account for automated tasks, that's what webhooks and deploy keys are for.
  - clintonb 4y ago
    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.

Ironlikebike 4y ago

"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-relations/opensource-program/ 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.

nirui 4y ago
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.

Lutger 4y ago

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