4 ms·

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 a

by 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.
zilti 3y ago
What complexity? Sending an email using git instead of having to create an account and open a merge request using a web app?
- aidenn0 3y ago
  Just in case you are being serious, I would estimate more people have GitHub accounts than know how to submit a git patch via e-mail. Most people use Outlook, Gmail or Apple's Mail.app as their MUI and I don't know how to do it with any of those 3.

by cybrox 3y ago

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.

zilti 3y ago

What complexity? Sending an email using git instead of having to create an account and open a merge request using a web app?

aidenn0 3y ago
Just in case you are being serious, I would estimate more people have GitHub accounts than know how to submit a git patch via e-mail. Most people use Outlook, Gmail or Apple's Mail.app as their MUI and I don't know how to do it with any of those 3.