6 ms·

My decision tree for selecting source control: Q: Do I want contributors? A: Yes, use GitHub. A: No, use whatever I want.

abound 3y ago
This is pretty much where I'm at. If I want visibility and people to contribute, GitHub. If it's a truly private project (dotfiles dump, esoteric highly personalized tools), self-hosted Gitea. Everything else I put on Sourcehut.
DonHopkins 3y ago
Q: Do I want to actively antagonize contributors while torturing myself? A: Yes, use SCCS.
Havoc 3y ago
Definitely path of least resistance but also bound to get us a monoculture
- Tuna-Fish 3y ago
  The monoculture already exists, and it was always going to be formed. The one good thing is that git makes it relatively easy to move, so that if Github suffers excessive enshittification, something else can steal their lunch.
  - kibwen 3y ago
    Git makes it relatively easy to move the code itself and its commit history, but not the other things people use Github for: issues, automation, CI... The lock-in is there.
    - zelphirkalt 3y ago
      Maybe this is making a good argument for managing these things as commits in a directory in the git tree?
      - jbaber 3y ago
        There are a few attempts to do this (git-bug is the most recent I remember). I desperately want one to get traction. git-bug even has a way to bridge your issues to github/gitlab/etc. trackers.
  - LightFog 3y ago
    MSFT gobbling up your code and selling it back to you isn’t enshittified enough for you?
    - whatevaa 3y ago
      Like public code on Sourcehut won't be gobbled up...
      - LightFog 3y ago
        And private code? MSFT make no promises private code on GitHub.com won’t be trained on.
  - mathstuf 3y ago
    You can move the code, sure. It's the infrastructure that is hard to relocate (issues, pulls). If one uses references like `#123` in the history, you need to do something to keep them "alive" on a migration. GitLab itself has an interesting solution where instead of short references, full URLs are used so that they work in any context (including locally). These URLs are then rendered as `#123` or whatever depending on the location of the render.
  - fsckboy 3y ago
    >git makes it relatively easy to move, so that if Github suffers excessive enshittification... what if the enshittification is making it hard to move?
- mbreese 3y ago
  The network effects associated with hosting code in a public source repository are just too great. If you want your code to be seen, used, trusted, you put it on one of the primary code repositories. At one point, this was sourceforge. For a while bitbucket had a good share. Then came GitHub. There are also always a few secondary repositories that share the same tooling, but still have less traction (like GitLab). But the network effects of GitHub are hard to ignore. But, like was said in a previous comment, it least it is easy to move Git repositories from one host to another. So when there is an inevitable successor to GitHub, we’ll all be able to migrate to the next hotness easier. (That’s assuming that the next hotness supports Git. Prior shifts followed from changing underlying technologies… CVS -> SVN or Hg -> Git)
- cybrox 3y ago
  Even ignoring the userbase, GitLab or BitBucket would have a better chance at hosting thriving projects. Sourcehut has a very good and noble idea but it just adds so much complexity in the name of purity to a hurdle that is already very big for newcomers. They basically undo all the progress on collaboration since the 90s to get rid of the modern problems that these changes cause, without realizing that the way forward is to solve these problems, not just revert to a time when they didn't exist.
  - Pet_Ant 3y ago
    > They basically undo all the progress on collaboration since the 90s to get rid of the modern problems that these changes cause, https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_fence https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_...
  - aidenn0 3y ago
    > They basically undo all the progress on collaboration since the 90s to get rid of the modern problems that these changes cause, without realizing that the way forward is to solve these problems, not just revert to a time when they didn't exist. Saying they are "reverting to a time when they didn't exist" is missing the point. It's about improving the problems that caused people to switch away from the collaboration tools in the 90s; e.g. [1]. So it's more of a fork of the 90s than a rollback. Also, it's not like the people at SH (and their users) haven't tried new collaboration tools. I (at least) have tried them and found them wanting in important ways. The conclusion that it's better to fix the older tools than the newer tools could be debated with[2], but nobody's sticking their heads in the sand here. 1: https://sourcehut.org/blog/2022-07-06-sourcehut-and-irc/ https://sourcehut.org/blog/2022-07-06-sourcehut-and-irc/ Note also that even without SH, e-mail, IRC, &c. are all greatly improved in both small and large ways in the time between the 90s and now. 2: I mean everybody involved with SH already prefers the older tools for one reason or another, so fixing the older tools is going to be the obvious path forward for them.
  - busterarm 3y ago
    It's not about purity. It's about a workflow where everything lives in email rather than some company's walled garden. It also doesn't give a toss about newcomers. It's for users who want something very specific and know what that looks like already. It's like the same reasons that OpenBSD still uses CVS -- it works perfectly fine for those involved in the project and the switch to Git would not only take time away from what's important to work on but also add a ton of noise from new contributors who may not have the same goals as the project.
Zambyte 3y ago
Why not just use both? The great thing about git is that you can easily coordinate multiple repositories (git push --all). The great thing about the web is you can hyperlink to different sites (link to related discussion on another forge). Source forges all send email notifications, so you can get updates in one place. The biggest problem I see is duplicate issues being raised across forge issue trackers, which using a single forge doesn't fix anyways.
buovjaga 3y ago
A: Yes, provide mentoring and use whatever fits your needs. If you funnel potential contributors straight into mentoring, the popularity of the tools is not an issue. For visibility, there are many possibilities, such as volunteer platforms.
- zbentley 3y ago
  Then those aren’t contributors, at least not at first; they’re mentees/students. Projects which can follow that practice are substantially fewer than projects who can quickly solicit contributions on e.g. GitHub: requiring mentoring restricts the field to projects whose authors have the time, skills, and inclination to mentor, and restricts potential contributors to people willing to be mentored in new tooling rather than the (much more common) case of people who simply want to provide an improvement to code with minimal friction (and often minimal other involvement with the project, if we’re talking about point fixes for issues faced by the contributing user).
chillfox 3y ago
lol, that’s pretty much what I do as well. For me the “whatever” is usually a self-hosted fossil server.
sph 3y ago
The problem is wanting contributors. I want to release open source software, contributors (which mostly means bug reporters and entitled users) tend to be a drag turning a hobby project into work. Remember, open source doesn't mean to accept any inane suggestion or PR from anybody. The best software is the opinionated and limited-in-scope. If people want to add an MP3 player to your project, they can always fork it. And since using GitHub basically means training AI undermining my career, for free, so that Microsoft can turn a profit, the choice is simple, really. Disclaimer: I am still using Github because I haven't found the time to set up my self-hosted Gitea instance just yet.
- Propelloni 3y ago
  If you are only looking for a place to host your open source projects, you could take a look at codeberg.org.
  - sph 3y ago
    I also need to host private, commercial repos which are forbidden on Codeberg. When I migrate out of the Github loving embrace, I might as well self host and be safe forever.
    - mroche 3y ago
      I run a self hosted Forgejo instance in my homelab, and have it set up to push mirror to hosted forges for redundancy/publication. It's stupid easy to set up and maintain (I've given it 2vCPUs, 2GiB of RAM, and a 20GiB disk).
- The_Colonel 3y ago
  There's a sweet spot number of contributors which provide valuable feedback, testing, ideas and maybe some code. It's not that difficult to get to that sweet spot, the problem is staying there. It may happen that the number grows too much, and you get overwhelmed, burned out (eventually).
  - 3y ago
derekzhouzhen 3y ago
If I do not want contributor, then I'd just use plain git through SSH on my own VPS.
fmajid 3y ago
People mistake GitHub for a source control system, when it is actually a social network for developers.

abound 3y ago

This is pretty much where I'm at. If I want visibility and people to contribute, GitHub. If it's a truly private project (dotfiles dump, esoteric highly personalized tools), self-hosted Gitea. Everything else I put on Sourcehut.

DonHopkins 3y ago

Q: Do I want to actively antagonize contributors while torturing myself? A: Yes, use SCCS.

Havoc 3y ago

Definitely path of least resistance but also bound to get us a monoculture

Tuna-Fish 3y ago
The monoculture already exists, and it was always going to be formed. The one good thing is that git makes it relatively easy to move, so that if Github suffers excessive enshittification, something else can steal their lunch.
- kibwen 3y ago
  Git makes it relatively easy to move the code itself and its commit history, but not the other things people use Github for: issues, automation, CI... The lock-in is there.
  - zelphirkalt 3y ago
    Maybe this is making a good argument for managing these things as commits in a directory in the git tree?
    - jbaber 3y ago
      There are a few attempts to do this (git-bug is the most recent I remember). I desperately want one to get traction. git-bug even has a way to bridge your issues to github/gitlab/etc. trackers.
- LightFog 3y ago
  MSFT gobbling up your code and selling it back to you isn’t enshittified enough for you?
  - whatevaa 3y ago
    Like public code on Sourcehut won't be gobbled up...
    - LightFog 3y ago
      And private code? MSFT make no promises private code on GitHub.com won’t be trained on.
- mathstuf 3y ago
  You can move the code, sure. It's the infrastructure that is hard to relocate (issues, pulls). If one uses references like `#123` in the history, you need to do something to keep them "alive" on a migration. GitLab itself has an interesting solution where instead of short references, full URLs are used so that they work in any context (including locally). These URLs are then rendered as `#123` or whatever depending on the location of the render.
- fsckboy 3y ago
  >git makes it relatively easy to move, so that if Github suffers excessive enshittification... what if the enshittification is making it hard to move?
mbreese 3y ago
The network effects associated with hosting code in a public source repository are just too great. If you want your code to be seen, used, trusted, you put it on one of the primary code repositories. At one point, this was sourceforge. For a while bitbucket had a good share. Then came GitHub. There are also always a few secondary repositories that share the same tooling, but still have less traction (like GitLab). But the network effects of GitHub are hard to ignore. But, like was said in a previous comment, it least it is easy to move Git repositories from one host to another. So when there is an inevitable successor to GitHub, we’ll all be able to migrate to the next hotness easier. (That’s assuming that the next hotness supports Git. Prior shifts followed from changing underlying technologies… CVS -> SVN or Hg -> Git)
cybrox 3y ago
Even ignoring the userbase, GitLab or BitBucket would have a better chance at hosting thriving projects. Sourcehut has a very good and noble idea but it just adds so much complexity in the name of purity to a hurdle that is already very big for newcomers. They basically undo all the progress on collaboration since the 90s to get rid of the modern problems that these changes cause, without realizing that the way forward is to solve these problems, not just revert to a time when they didn't exist.
- Pet_Ant 3y ago
  > They basically undo all the progress on collaboration since the 90s to get rid of the modern problems that these changes cause, https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_fence https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_...
- aidenn0 3y ago
  > They basically undo all the progress on collaboration since the 90s to get rid of the modern problems that these changes cause, without realizing that the way forward is to solve these problems, not just revert to a time when they didn't exist. Saying they are "reverting to a time when they didn't exist" is missing the point. It's about improving the problems that caused people to switch away from the collaboration tools in the 90s; e.g. [1]. So it's more of a fork of the 90s than a rollback. Also, it's not like the people at SH (and their users) haven't tried new collaboration tools. I (at least) have tried them and found them wanting in important ways. The conclusion that it's better to fix the older tools than the newer tools could be debated with[2], but nobody's sticking their heads in the sand here. 1: https://sourcehut.org/blog/2022-07-06-sourcehut-and-irc/ https://sourcehut.org/blog/2022-07-06-sourcehut-and-irc/ Note also that even without SH, e-mail, IRC, &c. are all greatly improved in both small and large ways in the time between the 90s and now. 2: I mean everybody involved with SH already prefers the older tools for one reason or another, so fixing the older tools is going to be the obvious path forward for them.
- busterarm 3y ago
  It's not about purity. It's about a workflow where everything lives in email rather than some company's walled garden. It also doesn't give a toss about newcomers. It's for users who want something very specific and know what that looks like already. It's like the same reasons that OpenBSD still uses CVS -- it works perfectly fine for those involved in the project and the switch to Git would not only take time away from what's important to work on but also add a ton of noise from new contributors who may not have the same goals as the project.

Zambyte 3y ago

Why not just use both? The great thing about git is that you can easily coordinate multiple repositories (git push --all). The great thing about the web is you can hyperlink to different sites (link to related discussion on another forge). Source forges all send email notifications, so you can get updates in one place. The biggest problem I see is duplicate issues being raised across forge issue trackers, which using a single forge doesn't fix anyways.

buovjaga 3y ago

A: Yes, provide mentoring and use whatever fits your needs. If you funnel potential contributors straight into mentoring, the popularity of the tools is not an issue. For visibility, there are many possibilities, such as volunteer platforms.

zbentley 3y ago
Then those aren’t contributors, at least not at first; they’re mentees/students. Projects which can follow that practice are substantially fewer than projects who can quickly solicit contributions on e.g. GitHub: requiring mentoring restricts the field to projects whose authors have the time, skills, and inclination to mentor, and restricts potential contributors to people willing to be mentored in new tooling rather than the (much more common) case of people who simply want to provide an improvement to code with minimal friction (and often minimal other involvement with the project, if we’re talking about point fixes for issues faced by the contributing user).

chillfox 3y ago

lol, that’s pretty much what I do as well. For me the “whatever” is usually a self-hosted fossil server.

sph 3y ago

The problem is wanting contributors. I want to release open source software, contributors (which mostly means bug reporters and entitled users) tend to be a drag turning a hobby project into work. Remember, open source doesn't mean to accept any inane suggestion or PR from anybody. The best software is the opinionated and limited-in-scope. If people want to add an MP3 player to your project, they can always fork it. And since using GitHub basically means training AI undermining my career, for free, so that Microsoft can turn a profit, the choice is simple, really. Disclaimer: I am still using Github because I haven't found the time to set up my self-hosted Gitea instance just yet.

Propelloni 3y ago
If you are only looking for a place to host your open source projects, you could take a look at codeberg.org.
- sph 3y ago
  I also need to host private, commercial repos which are forbidden on Codeberg. When I migrate out of the Github loving embrace, I might as well self host and be safe forever.
  - mroche 3y ago
    I run a self hosted Forgejo instance in my homelab, and have it set up to push mirror to hosted forges for redundancy/publication. It's stupid easy to set up and maintain (I've given it 2vCPUs, 2GiB of RAM, and a 20GiB disk).
The_Colonel 3y ago
There's a sweet spot number of contributors which provide valuable feedback, testing, ideas and maybe some code. It's not that difficult to get to that sweet spot, the problem is staying there. It may happen that the number grows too much, and you get overwhelmed, burned out (eventually).
- 3y ago

derekzhouzhen 3y ago

If I do not want contributor, then I'd just use plain git through SSH on my own VPS.

fmajid 3y ago

People mistake GitHub for a source control system, when it is actually a social network for developers.