6 ms·

You don't need to agree with all of his opinions to use SourceHut :) I'm not a big fan of some of his hot takes, but I still respect him and trust him with my

You don't need to agree with all of his opinions to use SourceHut :) I'm not a big fan of some of his hot takes, but I still respect him and trust him with my data.

sneak 3y ago
The reason I don’t use srht is because of his opinions about product development (of srht itself), not his personal opinions. Social/collaboration features are explicitly deprioritized by design; I think this is a natural consequence of srht being built by and for lone wolf developers. GitHub and Gitea (which is basically a github clone) seem much more geared toward collaboration by groups, something most small-time f/oss developers don’t need. Also, the emphasis on email and irc is bad, imo. The web won because it is better. A lot of the anti-web stuff is just tradition.
- tslocum 3y ago
  As someone who was there in the early days, who joined the chorus of people warning Drew about the effects of such a policy, I just want to say that Forgejo is a treat to self-host and use. Gitea is now open-core, and its future is unclear. https://forgejo.org https://forgejo.org
  - mroche 3y ago
    This really comes down to the intended workflow. By design, SourceHut aims to provide the Linux kernel development model to a wider audience (with extra features beyond mail and Git). It is a very different collaboration model than the likes of GitHub and its peers. I summarize the comparison of the two as "to each their own"; I'm okay with both models and see the merits of both, but my preferences and willingness or ability to work with a given model won't always line up with contributors. I also self-host Forgejo in my homelab and really enjoy it.
  - zufallsheld 3y ago
    The only mention I can find that gitea is open core comes from forgejo. Do you have some kind of proof that there are parts of gitea that are not MIT licensed?
    - radlad 3y ago
      Gitea Ltd's stance seems to be that it does "custom development" support contracts.[0] It may be a matter of perspective whether you consider this "open-core" or "contract work." See also their clarifications on Gitea the company[1]: > Gitea Ltd. will be open to building special versions for special clients and will contribute any features back to the main repository when possible This was in a followup to the original announcement.[2] Forgejo (i.e. Codeberg, a FOSS non-profit) maintains that the project should be led by the community, not a company[3]: > Sadly, Gitea Ltd broke that trust by a lack of transparency: its existence was kept a secret during months. After the initial announcement, Gitea Ltd published another blog post but it was still vague and there has been no other communication since. Who are the Gitea Ltd shareholders? Who, among the Gitea maintainers, are employees of Gitea Ltd? [0] https://about.gitea.com/pricing/ https://about.gitea.com/pricing/ [1] https://blog.gitea.com/a-message-from-lunny-on-gitea-ltd.-and-the-gitea-project https://blog.gitea.com/a-message-from-lunny-on-gitea-ltd.-an... [2] https://blog.gitea.com/open-source-sustainment/ https://blog.gitea.com/open-source-sustainment/ [3] https://blog.codeberg.org/codeberg-launches-forgejo.html https://blog.codeberg.org/codeberg-launches-forgejo.html
      - deleted 3y ago
        [deleted]
- tarxvf 3y ago
  That the social and communication tools they prefer are not the tools you prefer does not mean they are asocial.
  - kstrauser 3y ago
    That's so true, but I agree with sneak here (did I just write that?). If my code is on GitHub or GitLab or Gitea or whatever, and I want to work on it with a friend, I can invite them to join me on a website using a workflow similar to 1,000 other not-source-code-related collaboration tools. It's damn near impossible to talk someone into joining an email-based process unless that's something they've already been doing elsewhere. Look at the git-send-email docs[0] which talk about configuring SMTP auth. Followup question from the new person I'd be trying to rope in: "I dunno, my work uses Outlook. What's SMTP?" If someone contended that SourceHut optimizes for devs who've been writing Linux kernel code for 25 years, so you weed out all the newbs and can get the hardened veterans involved in your project, I could buy that. I'd disagree that it's what I'd want for my project, but to each their own. I couldn't recommend it as an alternative to other services that require participants to know how to use a web browser. [0]https://git-scm.com/docs/git-send-email https://git-scm.com/docs/git-send-email
    - myaccountonhn 3y ago
      Once you learn the git-send-email flow, it is a lot better, especially for distributed development. With the PR flow, people need to sign up to the website, create a fork, clone the repo, make their changes, go into a slow web ui etc. It mostly works because everyone is on Github. However, even that solution sucks if you are having a polyrepo setup and need to make changes in many places. For bazaar style development where you accept contributions from anyone and don't use Github, the email flow is so much faster and simpler. Yes, you need to set it up once. But the other day I contributed to a open source project that was self-hosted, and it's amazing that I just can clone the repo, make my changes, commit and then git-send-email, bam done. Had I needed to sign up and create an account, set up a fork, I probably wouldn't have bothered because it was a small contribution. However no need to register to a website, no need to click through a slow ui, no need to create a fork, it reduces the ritual to make contributions by quite a lot, given that you've set it up. There is also https://git-send-email.io/ https://git-send-email.io/ which provides a nice tutorial for people. I am glad that there is a good alternative that supports this flow, because I think it is superior. There are a ton of alternatives if you want the PR flow (Gitlab, Gitea, Github, Codeberg).
- kstrauser 3y ago
  I adore Gitea. 99% of the stuff I keep there is private code, where Gitea is basically an SSH-able Git remote. However, I occasionally want to share a project with a friend, and then it's trivially easy to invite them to collaborate with me using the same infrastructure I was already using. Minus that last part, I'd just stick with plain Git. It's everything I need for my own personal, only-for-me projects.
- xigoi 3y ago
  Everyone has an e-mail account. That means if you want to contribute to a project on SourceHut, you don’t need to create an account there. Also, I hate when I’m looking for useful forks of something on GitHub and have to sift through tens of useless forks that were created just to be able to submit a pull request.
  - bombcar 3y ago
    Those “onetime” forms are blight on GitHub. Sometimes useful when the main project gets nuked or deleted, if you can find them.
- avgcorrection 3y ago
  Are they deprioritized (spelling dunno)? Or are they just different in a way which you judge as being not-conducive to collaboration? (I mean you mention mailing lists.) There’s not really much need for a “forge” without collaboration. I wouldn’t pay the price of SourceHut just so that I can fetch and whatever between my machines. That’s like a pricey sneaker net.
  - MaxBarraclough 3y ago
    Per my reply to sneak's comment, collaboration features are part of SourceHut's goals, but its approach is very different from that of GitHub. If all you want is a lightweight web UI for a git repository, git's official GitWeb project offers this. SourceHut isn't just an alternative to GitWeb. https://git-scm.com/book/en/v2/Git-on-the-Server-GitWeb https://git-scm.com/book/en/v2/Git-on-the-Server-GitWeb
- zilti 3y ago
  LOL! That something wins because it's better almost never happens. Your example included.
- MaxBarraclough 3y ago
  > Social/collaboration features are explicitly deprioritized by design; I think this is a natural consequence of srht being built by and for lone wolf developers. It's not the case that SourceHut treats collaboration features as out-of-scope. Drew seems to draw a bright line between social and collaboration features, and intends for SourceHut to offer solid collaboration features, but without any hint of trying to be a social network. From an old comment of Drew's: (edit: I now see Drew's comment was replying to you yourself) > SourceHut is designed to facilitate collaboration, of course, but it's done differently from platforms like GitHub and those that seek to emulate it. And of course it is more than a git frontend, providing tools specifically to facilitate collaboration such as mailing lists and bug trackers. SourceHut is an engineering tool, not a social network. It is designed to get your work done and then get out of your way. > GitHub is explicitly designed like a social network, and this is a design that we reject. (From https://news.ycombinator.com/item?id=31963467 https://news.ycombinator.com/item?id=31963467) > I think this is a natural consequence of srht being built by and for lone wolf developers Built by lone wolf developers, plural?
gray_-_wolf 3y ago
I stopped paying for sourcehut because his opinions are relevant here since he bans types of projects based on them. You never know when another restriction will be added.
- cornstalks 3y ago
  If you're talking about banning cryptocurrency and blockchain projects, personally that earned some favor in my eyes. I'm happy to use and pay for a service that doesn't contribute to that blight. For the curious, the terms are here: https://man.sr.ht/terms.md#permissible-use https://man.sr.ht/terms.md#permissible-use
  - gray_-_wolf 3y ago
    I also do not like "crypto", but I do not think this type of restriction is great on a paid service. Maybe, maybe it could be argued for public repositories. Or if it was free. But like, why does Drew DeVault care that I would have a private repository with "explicit sexual content"? On an account I pay for? And even if you agree with the current set of restrictions, are you sure it will not be further expanded? I am not.
    - eesmith 3y ago
      > why does Drew DeVault care that I would have a private repository with "explicit sexual content"? For the same reason GitHub does? GitHub's AUP at https://docs.github.com/en/site-policy/acceptable-use-policies/github-acceptable-use-policies https://docs.github.com/en/site-policy/acceptable-use-polici... says: "We do not allow content or activity on GitHub that: ... is sexually obscene or relates to sexual exploitation or abuse, including of minors". Atlassian's AUP at https://www.atlassian.com/legal/acceptable-use-policy https://www.atlassian.com/legal/acceptable-use-policy says "Inappropriate content" includes "Posting, uploading, sharing, submitting, or otherwise providing content that ... Is deceptive, fraudulent, illegal, obscene, defamatory, libelous, threatening, harmful to minors, pornographic (including child pornography, which we will remove and report to law enforcement, including the National Center for Missing and Exploited Children), indecent, harassing, hateful"? GitLab's AUP at https://handbook.gitlab.com/handbook/legal/acceptable-use-policy/ https://handbook.gitlab.com/handbook/legal/acceptable-use-po... says "unacceptable use of our services [which] applies to all users of all GitLab services including those on the Free, Premium, and Ultimate GitLab tiers" mean "you must not: Create, upload, submit, execute, transmit, or host anything that ... is vulgar, obscene, or pornographic, or gratuitously depicts or glorifies violence." Now, there are differences between "explicit sexual content", "sexually obscene" and "pornographic", but if you are worried about possible further expansion, you shouldn't use any of these code hosting services.

You don't need to agree with all of his opinions to use SourceHut :) I'm not a big fan of some of his hot takes, but I still respect him and trust him with my data.

sneak 3y ago

The reason I don’t use srht is because of his opinions about product development (of srht itself), not his personal opinions. Social/collaboration features are explicitly deprioritized by design; I think this is a natural consequence of srht being built by and for lone wolf developers. GitHub and Gitea (which is basically a github clone) seem much more geared toward collaboration by groups, something most small-time f/oss developers don’t need. Also, the emphasis on email and irc is bad, imo. The web won because it is better. A lot of the anti-web stuff is just tradition.

tslocum 3y ago
As someone who was there in the early days, who joined the chorus of people warning Drew about the effects of such a policy, I just want to say that Forgejo is a treat to self-host and use. Gitea is now open-core, and its future is unclear. https://forgejo.org https://forgejo.org
- mroche 3y ago
  This really comes down to the intended workflow. By design, SourceHut aims to provide the Linux kernel development model to a wider audience (with extra features beyond mail and Git). It is a very different collaboration model than the likes of GitHub and its peers. I summarize the comparison of the two as "to each their own"; I'm okay with both models and see the merits of both, but my preferences and willingness or ability to work with a given model won't always line up with contributors. I also self-host Forgejo in my homelab and really enjoy it.
- zufallsheld 3y ago
  The only mention I can find that gitea is open core comes from forgejo. Do you have some kind of proof that there are parts of gitea that are not MIT licensed?
  - radlad 3y ago
    Gitea Ltd's stance seems to be that it does "custom development" support contracts.[0] It may be a matter of perspective whether you consider this "open-core" or "contract work." See also their clarifications on Gitea the company[1]: > Gitea Ltd. will be open to building special versions for special clients and will contribute any features back to the main repository when possible This was in a followup to the original announcement.[2] Forgejo (i.e. Codeberg, a FOSS non-profit) maintains that the project should be led by the community, not a company[3]: > Sadly, Gitea Ltd broke that trust by a lack of transparency: its existence was kept a secret during months. After the initial announcement, Gitea Ltd published another blog post but it was still vague and there has been no other communication since. Who are the Gitea Ltd shareholders? Who, among the Gitea maintainers, are employees of Gitea Ltd? [0] https://about.gitea.com/pricing/ https://about.gitea.com/pricing/ [1] https://blog.gitea.com/a-message-from-lunny-on-gitea-ltd.-and-the-gitea-project https://blog.gitea.com/a-message-from-lunny-on-gitea-ltd.-an... [2] https://blog.gitea.com/open-source-sustainment/ https://blog.gitea.com/open-source-sustainment/ [3] https://blog.codeberg.org/codeberg-launches-forgejo.html https://blog.codeberg.org/codeberg-launches-forgejo.html
    - deleted 3y ago
      [deleted]
tarxvf 3y ago
That the social and communication tools they prefer are not the tools you prefer does not mean they are asocial.
- kstrauser 3y ago
  That's so true, but I agree with sneak here (did I just write that?). If my code is on GitHub or GitLab or Gitea or whatever, and I want to work on it with a friend, I can invite them to join me on a website using a workflow similar to 1,000 other not-source-code-related collaboration tools. It's damn near impossible to talk someone into joining an email-based process unless that's something they've already been doing elsewhere. Look at the git-send-email docs[0] which talk about configuring SMTP auth. Followup question from the new person I'd be trying to rope in: "I dunno, my work uses Outlook. What's SMTP?" If someone contended that SourceHut optimizes for devs who've been writing Linux kernel code for 25 years, so you weed out all the newbs and can get the hardened veterans involved in your project, I could buy that. I'd disagree that it's what I'd want for my project, but to each their own. I couldn't recommend it as an alternative to other services that require participants to know how to use a web browser. [0]https://git-scm.com/docs/git-send-email https://git-scm.com/docs/git-send-email
  - myaccountonhn 3y ago
    Once you learn the git-send-email flow, it is a lot better, especially for distributed development. With the PR flow, people need to sign up to the website, create a fork, clone the repo, make their changes, go into a slow web ui etc. It mostly works because everyone is on Github. However, even that solution sucks if you are having a polyrepo setup and need to make changes in many places. For bazaar style development where you accept contributions from anyone and don't use Github, the email flow is so much faster and simpler. Yes, you need to set it up once. But the other day I contributed to a open source project that was self-hosted, and it's amazing that I just can clone the repo, make my changes, commit and then git-send-email, bam done. Had I needed to sign up and create an account, set up a fork, I probably wouldn't have bothered because it was a small contribution. However no need to register to a website, no need to click through a slow ui, no need to create a fork, it reduces the ritual to make contributions by quite a lot, given that you've set it up. There is also https://git-send-email.io/ https://git-send-email.io/ which provides a nice tutorial for people. I am glad that there is a good alternative that supports this flow, because I think it is superior. There are a ton of alternatives if you want the PR flow (Gitlab, Gitea, Github, Codeberg).
kstrauser 3y ago
I adore Gitea. 99% of the stuff I keep there is private code, where Gitea is basically an SSH-able Git remote. However, I occasionally want to share a project with a friend, and then it's trivially easy to invite them to collaborate with me using the same infrastructure I was already using. Minus that last part, I'd just stick with plain Git. It's everything I need for my own personal, only-for-me projects.
xigoi 3y ago
Everyone has an e-mail account. That means if you want to contribute to a project on SourceHut, you don’t need to create an account there. Also, I hate when I’m looking for useful forks of something on GitHub and have to sift through tens of useless forks that were created just to be able to submit a pull request.
- bombcar 3y ago
  Those “onetime” forms are blight on GitHub. Sometimes useful when the main project gets nuked or deleted, if you can find them.
avgcorrection 3y ago
Are they deprioritized (spelling dunno)? Or are they just different in a way which you judge as being not-conducive to collaboration? (I mean you mention mailing lists.) There’s not really much need for a “forge” without collaboration. I wouldn’t pay the price of SourceHut just so that I can fetch and whatever between my machines. That’s like a pricey sneaker net.
- MaxBarraclough 3y ago
  Per my reply to sneak's comment, collaboration features are part of SourceHut's goals, but its approach is very different from that of GitHub. If all you want is a lightweight web UI for a git repository, git's official GitWeb project offers this. SourceHut isn't just an alternative to GitWeb. https://git-scm.com/book/en/v2/Git-on-the-Server-GitWeb https://git-scm.com/book/en/v2/Git-on-the-Server-GitWeb
zilti 3y ago
LOL! That something wins because it's better almost never happens. Your example included.
MaxBarraclough 3y ago
> Social/collaboration features are explicitly deprioritized by design; I think this is a natural consequence of srht being built by and for lone wolf developers. It's not the case that SourceHut treats collaboration features as out-of-scope. Drew seems to draw a bright line between social and collaboration features, and intends for SourceHut to offer solid collaboration features, but without any hint of trying to be a social network. From an old comment of Drew's: (edit: I now see Drew's comment was replying to you yourself) > SourceHut is designed to facilitate collaboration, of course, but it's done differently from platforms like GitHub and those that seek to emulate it. And of course it is more than a git frontend, providing tools specifically to facilitate collaboration such as mailing lists and bug trackers. SourceHut is an engineering tool, not a social network. It is designed to get your work done and then get out of your way. > GitHub is explicitly designed like a social network, and this is a design that we reject. (From https://news.ycombinator.com/item?id=31963467 https://news.ycombinator.com/item?id=31963467) > I think this is a natural consequence of srht being built by and for lone wolf developers Built by lone wolf developers, plural?

gray_-_wolf 3y ago

I stopped paying for sourcehut because his opinions are relevant here since he bans types of projects based on them. You never know when another restriction will be added.

cornstalks 3y ago
If you're talking about banning cryptocurrency and blockchain projects, personally that earned some favor in my eyes. I'm happy to use and pay for a service that doesn't contribute to that blight. For the curious, the terms are here: https://man.sr.ht/terms.md#permissible-use https://man.sr.ht/terms.md#permissible-use
- gray_-_wolf 3y ago
  I also do not like "crypto", but I do not think this type of restriction is great on a paid service. Maybe, maybe it could be argued for public repositories. Or if it was free. But like, why does Drew DeVault care that I would have a private repository with "explicit sexual content"? On an account I pay for? And even if you agree with the current set of restrictions, are you sure it will not be further expanded? I am not.
  - eesmith 3y ago
    > why does Drew DeVault care that I would have a private repository with "explicit sexual content"? For the same reason GitHub does? GitHub's AUP at https://docs.github.com/en/site-policy/acceptable-use-policies/github-acceptable-use-policies https://docs.github.com/en/site-policy/acceptable-use-polici... says: "We do not allow content or activity on GitHub that: ... is sexually obscene or relates to sexual exploitation or abuse, including of minors". Atlassian's AUP at https://www.atlassian.com/legal/acceptable-use-policy https://www.atlassian.com/legal/acceptable-use-policy says "Inappropriate content" includes "Posting, uploading, sharing, submitting, or otherwise providing content that ... Is deceptive, fraudulent, illegal, obscene, defamatory, libelous, threatening, harmful to minors, pornographic (including child pornography, which we will remove and report to law enforcement, including the National Center for Missing and Exploited Children), indecent, harassing, hateful"? GitLab's AUP at https://handbook.gitlab.com/handbook/legal/acceptable-use-policy/ https://handbook.gitlab.com/handbook/legal/acceptable-use-po... says "unacceptable use of our services [which] applies to all users of all GitLab services including those on the Free, Premium, and Ultimate GitLab tiers" mean "you must not: Create, upload, submit, execute, transmit, or host anything that ... is vulgar, obscene, or pornographic, or gratuitously depicts or glorifies violence." Now, there are differences between "explicit sexual content", "sexually obscene" and "pornographic", but if you are worried about possible further expansion, you shouldn't use any of these code hosting services.