I no longer maintain my Emacs projects on Sourcehut(protesilaos.com)
protesilaos.com
I no longer maintain my Emacs projects on Sourcehut
https://protesilaos.com/codelog/2024-01-27-sourcehut-no-more/
154 comments
It's really a drag. I really really really want to like sourcehut and I like Drew Devault's stance on things, but it seems like it's one of those projects that's almost there but not quite.
Github is great. However, it would be wonderful if there were true viable alternatives, and if the global ecosystem played nicely together. (e.g. sourcehut took in patches from github and visa versa) I idly worry that with the state of things on the internet now, there's gonna eventually be a github-only version of git that ends up drifting and then wham lock-in.
Github is great. However, it would be wonderful if there were true viable alternatives, and if the global ecosystem played nicely together. (e.g. sourcehut took in patches from github and visa versa) I idly worry that with the state of things on the internet now, there's gonna eventually be a github-only version of git that ends up drifting and then wham lock-in.
I'm not trying to start trouble, I'm genuinely interested in hearing why GitLab is not a true viable alternative. I'll be upfront that I'm a fanboi (and now a shareholder) but my question is in good faith since it interests me to hear the different perspectives and requirements
From my experience with Gitlab, it feels like Github but slightly worse so things aren't exactly in the place you expect them to be. Sourcehut is completely different, so (for better or worse) any user knows they have to adjust their approach.
GitLab's free plan is pretty limited; one of the nice things about GitHub is that the free/open source plan is actually sufficient for the vast majority of projects. And with the cheapest plan being $29/user per month that's not really an option for personal accounts or open source projects. GitLab's pricing strategy has been discussed on HN extensively before, and very few people seemed willing to pay that. It's strongly focused on business cases (and even for that, it's actually quite expensive).
Other than that, I think it's "viable" in the sense of "it works", but I hate using it. The UI is SLOW and overly complex. And lots of things don't work well if you zoom things to make text larger. So even without all the pricing plan woes I wouldn't want to use it.
Other than that, I think it's "viable" in the sense of "it works", but I hate using it. The UI is SLOW and overly complex. And lots of things don't work well if you zoom things to make text larger. So even without all the pricing plan woes I wouldn't want to use it.
gitea, drone
Gitea is commercial now though. historically speaking, it's likely just a question of time until they switch to a more restrictive licence to extract more money.
They also added their own CI system the other day. Haven't tried it myself, but I don't think drone-ci is necessary anymore.
They also added their own CI system the other day. Haven't tried it myself, but I don't think drone-ci is necessary anymore.
Gitea is as commercial as sourcehut.
Gitea's CI was marked stable in 1.19 in March 2023.
Gitea's CI was marked stable in 1.19 in March 2023.
IMO Gitea is fairly protected against a 'random' relicensing, as the project does not use a contributor licensing agreement.
While license and quality shenanigans can still happen, say if their technical oversight committee went bad, they cant do the same sort of rugpull done by projects that made contributors give all ownership interest to a single party.
GOGS (gitea's origin project) is still around and keeps moving at its own pace, as well.
While license and quality shenanigans can still happen, say if their technical oversight committee went bad, they cant do the same sort of rugpull done by projects that made contributors give all ownership interest to a single party.
GOGS (gitea's origin project) is still around and keeps moving at its own pace, as well.
Forgejo which powers codeberg recently hardforked from gitea and is looking like a nice alternative
maybe, or maybe not. https://lwn.net/Articles/963608/
Reading through all this drama frankly demotivates me from using any of these projects.
I'll stick to pushing to a bare Git repository via SSH for my personal projects. Plain Git works fine for that.
I'll stick to pushing to a bare Git repository via SSH for my personal projects. Plain Git works fine for that.
Ditto.
An "ssh init --bare" is enough, and after the first pull everything's the same.
But I'm generally of the mind that not everything needs to be public all the time, so I'm OK with not having a wiki and issues on such bare repos.
An "ssh init --bare" is enough, and after the first pull everything's the same.
But I'm generally of the mind that not everything needs to be public all the time, so I'm OK with not having a wiki and issues on such bare repos.
My decision tree for selecting source control:
Q: Do I want contributors?
A: Yes, use GitHub.
A: No, use whatever I want.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.
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.
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).
That is true. In practice, a higher barrier of entry tends to result in higher contribution quality. You wouldn't get a lot of hackathon PR spam if one could only send a patch with git send-email.
If you are only looking for a place to host your open source projects, you could take a look at codeberg.org.
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.
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).
Definitely path of least resistance but also bound to get us a monoculture
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.
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.
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.
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.
> 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_...
https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_...
> 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/ 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.
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/ 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.
What complexity? Sending an email using git instead of having to create an account and open a merge request using a web app?
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.
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)
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)
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.
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.
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.
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.
Maybe this is making a good argument for managing these things as commits in a directory in the git tree?
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.
>git makes it relatively easy to move, so that if Github suffers excessive enshittification...
what if the enshittification is making it hard to move?
what if the enshittification is making it hard to move?
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.
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.
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.
The biggest problem I see is duplicate issues being raised across forge issue trackers, which using a single forge doesn't fix anyways.
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.
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.
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).
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).
People mistake GitHub for a source control system, when it is actually a social network for developers.
Q: Do I want to actively antagonize contributors while torturing myself?
A: Yes, use SCCS.If I do not want contributor, then I'd just use plain git through SSH on my own VPS.
lol, that’s pretty much what I do as well. For me the “whatever” is usually a self-hosted fossil server.
Prot's thoughts echo some of the fears I had during the "slow leap" of 2018. I never made the jump to sourcehut, but I did leap to Gitlab, and have a general feeling that whatever small following I was building got snapped in half and never recovered.
I just suddenly stopped engaging with the users in my projects. Also a good thing in some cases, but it made my work take on a new private and hidden aspect, which is the opposite of what I wanted (open collab, easy dialogue, connecting with like-minded peers).
Gitlab just doesn't have the audience that Github does, and so my new strategy since a few months has been to develop on Gitlab, but to clone everything onto Github, just to get some audience.
I just suddenly stopped engaging with the users in my projects. Also a good thing in some cases, but it made my work take on a new private and hidden aspect, which is the opposite of what I wanted (open collab, easy dialogue, connecting with like-minded peers).
Gitlab just doesn't have the audience that Github does, and so my new strategy since a few months has been to develop on Gitlab, but to clone everything onto Github, just to get some audience.
GitLab’s UI really feels like it steers you towards work inside of a company more than open collaboration like GitHub does. Very segmented UI without discoverability.
I prefer GitLab but I understand why GitHub is the default. Just different products and use cases.
I prefer GitLab but I understand why GitHub is the default. Just different products and use cases.
> GitLab’s UI really feels like it steers you towards work inside of a company more than open collaboration like GitHub does.
That's kind of what it was designed for, though. GitLab.com wasn't a popular choice for open projects compared to GitHub until the "big migration" several years ago. Before that, GitLab was very popular for self-hosted internal instances (their customer reel demonstrated that). Even before modifying their OSS org policy for self-hosting, many groups ran their own GitLab CE instance. You couldn't (and still can't) do this with GitHub*. It also had a longstanding unlimited private repos compared to GitHub's free tier (formerly) that enticed developers.
GitLab's UI/UX was made for business workflows and processes (hence it being an "all-in-one DevOps platform." GitHub leans more into the community graph and semi-social media style for orgs/communities (the Discussions section a case example). It has come a long way for the business side, though.
* Yes, GitHub Enterprise Server exists: good luck getting it without paying for it (unless things have changed).
That's kind of what it was designed for, though. GitLab.com wasn't a popular choice for open projects compared to GitHub until the "big migration" several years ago. Before that, GitLab was very popular for self-hosted internal instances (their customer reel demonstrated that). Even before modifying their OSS org policy for self-hosting, many groups ran their own GitLab CE instance. You couldn't (and still can't) do this with GitHub*. It also had a longstanding unlimited private repos compared to GitHub's free tier (formerly) that enticed developers.
GitLab's UI/UX was made for business workflows and processes (hence it being an "all-in-one DevOps platform." GitHub leans more into the community graph and semi-social media style for orgs/communities (the Discussions section a case example). It has come a long way for the business side, though.
* Yes, GitHub Enterprise Server exists: good luck getting it without paying for it (unless things have changed).
GitLab has some long open tickets about federating instances but the technical implementation of such a thing is really only a small piece of the puzzle.
EDIT— here's a newer epic trying to gather some of that together into a cohesive effort: https://gitlab.com/groups/gitlab-org/-/epics/11247
EDIT— here's a newer epic trying to gather some of that together into a cohesive effort: https://gitlab.com/groups/gitlab-org/-/epics/11247
> Very segmented UI without discoverability.
Sometimes it has far too much discoverability.* It seems some searches are global. For instance, when I go to `My Merge Requests` and try and change the author, it shows me every single account on GitLab.
* One could argue this wraps around and becomes undiscoverable. Which I would agree with.
Sometimes it has far too much discoverability.* It seems some searches are global. For instance, when I go to `My Merge Requests` and try and change the author, it shows me every single account on GitLab.
* One could argue this wraps around and becomes undiscoverable. Which I would agree with.
I sheepishly collect analytics, and sourcehut provides similar relative traffic to my website as github does (I host more projects on github). Unfortunately nothing is immensely popular so I cannot say with certainty this will hold true, but I've observed high engagement with popular sourcehut projects.
Did you find out why engagement stopped? Is a preference to the GitHub UI? Or, they simply don't want another site to deal with?
If anything, the only value of GitHub to me personally is this vague rationale that 'people like that more' ... but I host everything on GitLab. But, what I host are really not active projects. That's the big difference possibly.
If anything, the only value of GitHub to me personally is this vague rationale that 'people like that more' ... but I host everything on GitLab. But, what I host are really not active projects. That's the big difference possibly.
Two years ago gitlab.com stopped allowing anonymous users to search issue trackers[1], which is nuts if you want to host anything there for which your users might want to search through existing issues. I don't think I've interacted with gitlab.com again after that. It seems that stupid decision has been overturned now? Anyway they've lost me for the foreseeable future.
[1] https://news.ycombinator.com/item?id=32252501
[1] https://news.ycombinator.com/item?id=32252501
I can’t speak for most, but for me it’s simply that GitHub operates more like a social media network for developers than a web-based git. As such I evaluate it by number of users because it equates directly to the number of social interactions I’m likely to have.
Morally I would love to stop using Microsoft products, much in the same way I’d like to stop using Meta products, but the problem is that I’m not there for the product, I’m there for the people. I can find products that better align with my values but I can’t bring along all the connections and possibility of connections
Morally I would love to stop using Microsoft products, much in the same way I’d like to stop using Meta products, but the problem is that I’m not there for the product, I’m there for the people. I can find products that better align with my values but I can’t bring along all the connections and possibility of connections
> I can’t speak for most, but for me it’s simply that GitHub operates more like a social media network for developers than a web-based git. As such I evaluate it by number of users because it equates directly to the number of social interactions I’m likely to have.
My final employer blocked GitHub as “social media” and rejected all arguments regarding its many other attributes. New CIO came in, heard of this, agreed it was silly and promised to have the block removed. Apparently somebody dissuaded him, because it never happened. Strange stuff.
My final employer blocked GitHub as “social media” and rejected all arguments regarding its many other attributes. New CIO came in, heard of this, agreed it was silly and promised to have the block removed. Apparently somebody dissuaded him, because it never happened. Strange stuff.
For me at least, I presume that the social network comes from the people you talk to, with whatever medium you use, when one is involved in a project, wherever the code is hosted. I never saw GitHub to be special. I got work from meetups, from participating on mailing lists, etc. but not GitHub. There is no tight link to it, but I can presume for myself that can be that case for a particular project. But - to each their own on this matter.
how do people use GitHub as a social media network exactly? I know the features are there but I've never talked to anyone who uses it.
a simpler explanation is that GitHub has a simpler/better interface than alternatives, and most people already have an account.
a simpler explanation is that GitHub has a simpler/better interface than alternatives, and most people already have an account.
For me, it's two things:
* Whenever I come across an interesting project hosted on Github (On Hacker News, Mastodon or some such place), I usually star it. Then when I'm later looking for a library or piece of software I usually search my Github stars first for a nice pre-filtered list of options.
I know I could also use a bookmark manager to keep track of interesting non-Github projects, but that's way too high-friction and so in practice I usually forget about them.
* There's also the social feed on the homepage where you can see which repositories your friends have starred/contributed to. I don't personally use this super often but frequently I star some repository and then notice a bunch of my friends starred it shortly after, presumably because they saw it in their feed.
* Whenever I come across an interesting project hosted on Github (On Hacker News, Mastodon or some such place), I usually star it. Then when I'm later looking for a library or piece of software I usually search my Github stars first for a nice pre-filtered list of options.
I know I could also use a bookmark manager to keep track of interesting non-Github projects, but that's way too high-friction and so in practice I usually forget about them.
* There's also the social feed on the homepage where you can see which repositories your friends have starred/contributed to. I don't personally use this super often but frequently I star some repository and then notice a bunch of my friends starred it shortly after, presumably because they saw it in their feed.
> Or they simply don't want another site to deal with?
This, mostly. Some of the contributors make mostly small (but important) documentation changes, and for them "Git" is "Github" since the UI makes all of it seemless.
Asking them to create an account on another service to do the same will leave these new contributors scratching heads
This, mostly. Some of the contributors make mostly small (but important) documentation changes, and for them "Git" is "Github" since the UI makes all of it seemless.
Asking them to create an account on another service to do the same will leave these new contributors scratching heads
> Asking them to create an account on another service to do the same will leave these new contributors scratching heads
Honestly, this can sometimes be a good thing.
Creating a bit of friction for contributors can separate the signal from the noise, leading to more meaningful contributions. We're all familiar with the fiasco and annoyance of #hacktoberfest on GH, and the incessant spam in popular projects and issue trackers.
That said, the friction of Sourcehut might be too much even for people with good intentions, since it insists on a very opinionated workflow that's alien to most. The choice of hosting ultimately depends on each project's needs, as mentioned elsewhere.
Honestly, this can sometimes be a good thing.
Creating a bit of friction for contributors can separate the signal from the noise, leading to more meaningful contributions. We're all familiar with the fiasco and annoyance of #hacktoberfest on GH, and the incessant spam in popular projects and issue trackers.
That said, the friction of Sourcehut might be too much even for people with good intentions, since it insists on a very opinionated workflow that's alien to most. The choice of hosting ultimately depends on each project's needs, as mentioned elsewhere.
Hacktoberfests will not be stopped by trivial friction, but small important doc changes will, so it's pure waste
Github has network effects that will always be difficult for challengers to overcome. Even Gitlab is nowhere near taking over. GH is effectively a professional resume for many people, and if they're contributing to something they want that recorded on their profile. When was the last time a recruiter asked to see your Gitlab or Sourcehut profile? As far as they're concerned those contributions might as well not exist, and like it or not that really matters to people. In short, it's the people, not the code that counts.
In my experience github has no value in your cv/resume at all
I'm really surprised to hear that. My GH profile has got me plenty of jobs over the years and also allowed me to skip things like programming tests that are usually part of the interview process.
I've seen jobs claiming they let you skip their tests but none have yet to do so. I have multiple conpleted side projects. They are small non-commercial but not trivial and solve a problem for me.
You are fortunate, which is great for you, but your advice will not work for most people.
You are fortunate, which is great for you, but your advice will not work for most people.
half finished projects that you developed on your own don't hold that much value. They may pad those green stats, but those can be faked quite easily. It's contributions to projects with other contributors that really matter.
Why work on half-finished personal projects when you can contribute to a high(ish)-profile public projects, especially such that your prospective employers might be using?
Seems like you lucked out, because this never really happened for me. I wish this was the case! I have a ton of half-finished projects I could show instead of doing tests.
Doesn’t seem like luck if he actually finished his projects. Every undergrad has a github full of half finished projects. Seeing professional contributions to a widely used project is a completely different story.
Even half-finished projects can be a valuable reference if they showcase passion, good development practices, or some specialty skill. Contributions to popular projects are valuable as well, but they should also showcase some of these attributes.
Something people often miss is that it's not enough to just link someone to your GH profile. If it's full of half-finished projects, they will likely look at your pinned ones (if you have those set), and not bother with the rest. The crucial thing is linking them directly to specific files of a project, specific PRs and contributions, that showcase the value you can bring. This makes the job much easier for the other side, while highlighting your strengths.
Something people often miss is that it's not enough to just link someone to your GH profile. If it's full of half-finished projects, they will likely look at your pinned ones (if you have those set), and not bother with the rest. The crucial thing is linking them directly to specific files of a project, specific PRs and contributions, that showcase the value you can bring. This makes the job much easier for the other side, while highlighting your strengths.
I have to agree a stubborn portion of companies refuse to look at it. It's their loss. If a company does not respect open source contributions I think it's a good filter.
I have so far found it to be a very good filter, helping eliminate BS or candidates grossly exaggerating their abilities. I've yet to experience the opposite but I have hope.
It certainly does for the people I've been hiring if they talk to me about open-source contributions during interviews
But would you accept their contributions if they were on gitlab, sourcehut, or some other server?
Because GP implies only github matters and that does not seem like truth to me.
Because GP implies only github matters and that does not seem like truth to me.
I'd definitely look at their code contributions on any code platform they'd provide on their CV. In addtion to this, sr.ht would hint me "you're actually interested in your craft way beyond what's in your school curriculum".
gitlab would hint me "you absolutely don't care about an UI which is slow as mollasses but you maybe have stronger moral principles."
gitlab would hint me "you absolutely don't care about an UI which is slow as mollasses but you maybe have stronger moral principles."
I tend to agree. My company (and many other companies) don't let you use a personal github account for company code, so we have separate accounts for the businesses private repo. Obviously these contributions can't appear on my personal github account.
The other issue is that commit activity is just a very poor signal for engineer quality. I've met truly terrible engineers with the brightest green activity boards you'll ever see. And I've met absolutely brilliant wizards whose activity board is very sparse.
Seniority is another issue -- as you grow in an org, you won't always grow in a way that leads to more contributions. I personally am spending a lot of time pairing, a lot of time leading, and a lot less time busting out individual tickets with constant commits.
I've also found that instead of taking 30 commits over 2 weeks to finish a project, the more experienced I get, I can do the same work in 5 commits over 3 days. It's just the nature of experience. But which one looks better on the github activity graph?
The other issue is that commit activity is just a very poor signal for engineer quality. I've met truly terrible engineers with the brightest green activity boards you'll ever see. And I've met absolutely brilliant wizards whose activity board is very sparse.
Seniority is another issue -- as you grow in an org, you won't always grow in a way that leads to more contributions. I personally am spending a lot of time pairing, a lot of time leading, and a lot less time busting out individual tickets with constant commits.
I've also found that instead of taking 30 commits over 2 weeks to finish a project, the more experienced I get, I can do the same work in 5 commits over 3 days. It's just the nature of experience. But which one looks better on the github activity graph?
As an interviewer it is the opposite to me. If there is a link showing your open source work, I want to review it to see if it indicates anything good or bad, and could be a topic for discussion. Too few people have good content there, so it can be a useful filter.
Me too. In particular, I look at how they handle pull requests. If it's full of derogatory comments or other asshole-isms, probably not going to be a fun person to have on the team. If they handle the occasional annoyance with a modicum of professionalism, it's usually a good sign.
As someone who has done hiring, we specifically asked for Github links and we checked the code there.
Granted this was mostly done for junior-level positions to gauge their level of proficiency in pretty much the basic tooling for the job.
Granted this was mostly done for junior-level positions to gauge their level of proficiency in pretty much the basic tooling for the job.
I just find GitHub's interface very intuitive and easy to use. Even GitLab isn't close despite being very similar; and it was miles ahead of sourceforge, Google Code etc.
(This is from someone who is not a dev by profession and had no idea about version control at the time.)
(This is from someone who is not a dev by profession and had no idea about version control at the time.)
One will never hear me defend GitLab's UI as "good" or "helpful" and for damn sure nowhere near fast, but in their defense the number of things they need to provide an interface for is much, much larger than GitHub's. I could very easily see them making better use of "and the rest of it" to put the 80/20 front and center versus the "cheesecake factory menu" approach they have going now
You mean that if you sent links to your Gitlab or Sourcehut profiles (or even your personal site) when asked for your Github profile, those recruiters would refuse to look at it?
If you replace "refuse" by "not bother to", the sentence suddenly becomes very believable. When you have dozens of resumes to sift through, and one applicant is difficult for no apparent reason, it's very easy not to bother. It's going to require a bit of effort to switch to the gitlab context and figure out the interface if the recruiter isn't used to it, which is annoying. Unless you already stand out for some positive reason, you don't really want to stand out for being annoying.
Well if clicking a link to your Gitlab profile is more difficult than clicking a link to your Github profile... yes, that could happen.
I have no idea how it could happen in practice. It's quite believable that there is some recruiter out there that has this kind of problem. But I do think it's quite safe to assume most of the tiny minority that will click on the link will get the same information from either one.
I have no idea how it could happen in practice. It's quite believable that there is some recruiter out there that has this kind of problem. But I do think it's quite safe to assume most of the tiny minority that will click on the link will get the same information from either one.
Well I personally am sick of seeing github profiles that are just a bunch of trash commits. List specific projects, what you contributed, and a link to who cares which service on your resume. Way easier to read
yeah i think they're much less likely to look at it, unless they're already significantly interested in you as a candidate for some other reason. We're in a competitive marketplace and having a profile that stands out is definitely an edge
Wouldn't a personal site stand out more if everyone has a GitHub?
remember that a recruiter is probably spending about 30 seconds assessing your job application, and that you're one candidate out of dozens. In that environment they're going to go with the easy route and showing them a bunch of pinned, interesting repos with a healthy number of stars in a format they're used to is going to help them to quickly put you in the "maybe" pile rather than the "nope" pile.
> Users replying to mailing list threads frequently do not “reply to all”, so the filter I have for SourceHut lists does not apply and my inbox is noisy again.
The major webmail clients defaulting to "Reply to Sender" rather than "Reply to List" really broke mailing lists as a sane workflow for corroboration. Most traditional e-mail clients will reply to the list if you hit the "reply" button.
This is probably due to people accidentally sending company-wide replies to announcement lists (e.g. I did this when our company wide e-mail target changed from an alias to a list).
I'm guessing most list-servers don't make it easy to put a reply-to header on announcement lists where list-reply is typically wrong? Or if they do, most list administrators don't know about it?
I'm not sure I have a point to this other than "this is why we can't have nice things" as I find e-mail to be one of the better collaboration tools; everybody can use the client they prefer, and for the most part, things "just work" which is rather amazing.
The major webmail clients defaulting to "Reply to Sender" rather than "Reply to List" really broke mailing lists as a sane workflow for corroboration. Most traditional e-mail clients will reply to the list if you hit the "reply" button.
This is probably due to people accidentally sending company-wide replies to announcement lists (e.g. I did this when our company wide e-mail target changed from an alias to a list).
I'm guessing most list-servers don't make it easy to put a reply-to header on announcement lists where list-reply is typically wrong? Or if they do, most list administrators don't know about it?
I'm not sure I have a point to this other than "this is why we can't have nice things" as I find e-mail to be one of the better collaboration tools; everybody can use the client they prefer, and for the most part, things "just work" which is rather amazing.
Good mailing list management software substitute list address to "Reply-To" header, so even simple "Reply" works fine (all known MUIs respect "Reply-To").
But it is typically breaks DKIM signature :-(
But it is typically breaks DKIM signature :-(
I just interpret this whole thing as "developer realises their preferred set of trade-offs matches host A more than host B, so they are switching hosts". This happens fairly frequently in various directions for many different reasons.
Slightly off topic, but related: I wish we could focus less on which git host is "best" and more on figuring out workable interoperability between them. Sadly, it seems less of a technical challenge and more a question of motive.
Slightly off topic, but related: I wish we could focus less on which git host is "best" and more on figuring out workable interoperability between them. Sadly, it seems less of a technical challenge and more a question of motive.
But it's not about a git host. It's about a discussion / issues / code review host.
All it takes to host git proper is a network-accessible machine with git and ssh. It's the trivial part.
Making it convenient for you to communicate with other varied humans contributing to, or otherwise interested in the code, is the key differentiator. And apparently this is not the part SourceHut prioritizes. No wonder, because it's the hardest part.
All it takes to host git proper is a network-accessible machine with git and ssh. It's the trivial part.
Making it convenient for you to communicate with other varied humans contributing to, or otherwise interested in the code, is the key differentiator. And apparently this is not the part SourceHut prioritizes. No wonder, because it's the hardest part.
> Making it convenient for you to communicate with other varied humans contributing to, or otherwise interested in the code, is the key differentiator. And apparently this is not the part SourceHut prioritizes. No wonder, because it's the hardest part.
Just because you don't seem to understand or agree with another person's priorities doesn't mean that they don't have them. By my reading, contributors to SourceHut absolutely do prioritize tools that humans use to communicate, and in particular ones that have been demonstrated to support complex and nuanced technical discussions.
Just because you don't seem to understand or agree with another person's priorities doesn't mean that they don't have them. By my reading, contributors to SourceHut absolutely do prioritize tools that humans use to communicate, and in particular ones that have been demonstrated to support complex and nuanced technical discussions.
This is great to know!
SourceHut is new, and likely has a ton of competing priorities.
Also, different groups have different preferred styles of communication. (E.g. chat vs email vs forums is a typical divide.) Different places offer different styles, and this is great, because one size often does not fit all.
That said, most people are conditioned by using GitHub, and this sets their default expectations. Then the network effect kicks in.
SourceHut is new, and likely has a ton of competing priorities.
Also, different groups have different preferred styles of communication. (E.g. chat vs email vs forums is a typical divide.) Different places offer different styles, and this is great, because one size often does not fit all.
That said, most people are conditioned by using GitHub, and this sets their default expectations. Then the network effect kicks in.
I'm not sure we have full data on the question, but by my own experiences the default expectation for most people regarding version control is copy the file and rename it. The default expectation for most people on collaboration tooling is sending an email. If they consider such things at all.
We can easily define a niche within which GitHub-awareness can be presumed but it's certainly not "most people".
We can easily define a niche within which GitHub-awareness can be presumed but it's certainly not "most people".
I suspect the majority of people who come to GitHub with intentions other than contributing come either to skim the README for installation instructions, or to complain about a problem. They may not even know about git. This is the wide kind of GitHub-awareness, which still assumes a level of computer literacy above that of most people.
It's also not entirely a technical issue, anyway. In a vacuum the Sourcehut UX might be fine, but if people are used to GitHub-style UX, then they will have a hard time with Sourcehut and end up doing the wrong thing, like emailing the maintainer directly rather than using the mailing lists – through no fault of the mailing lists themselves!
Sourcehut is really targeting users who want an email-centric workflow, which it excels at. It's not trying to be(at) GitHub.
You want it to be something that it isn't.
You want it to be something that it isn't.
I agree about the discussion / issues aspects. I suspect doing that interoperably would be hard or impossible because of the vastly different feature sets on different hosts.
All I am looking for is a few interoperability features for the repositories themselves. In fact, if I were to describe the most important single feature, it would be something like this:
I am able do some work in my repo hosted on host A, which was originally cloned from a repo on host B, and offer it back to the author on host B to merge if they wish. I'd like to be able to do this by notifying them (in a way integrated into my workflow) with the same kind of information that `git request-pull` generates. Importantly I would not need an account on host B for this. Possibly this might need some one-off setup on the original authors side, perhaps adding my repo as an remote.
The use cases I have in mind here are mostly occasional contributions or minor changes. I don't think this would work well for people who are frequent major contributors - they would really need the discussion / issues aspects to collaborate effectively.
All I am looking for is a few interoperability features for the repositories themselves. In fact, if I were to describe the most important single feature, it would be something like this:
I am able do some work in my repo hosted on host A, which was originally cloned from a repo on host B, and offer it back to the author on host B to merge if they wish. I'd like to be able to do this by notifying them (in a way integrated into my workflow) with the same kind of information that `git request-pull` generates. Importantly I would not need an account on host B for this. Possibly this might need some one-off setup on the original authors side, perhaps adding my repo as an remote.
The use cases I have in mind here are mostly occasional contributions or minor changes. I don't think this would work well for people who are frequent major contributors - they would really need the discussion / issues aspects to collaborate effectively.
The issue I had with Sourcehut was minor yet very annoying: My memory might fail me, but I remember I had a hard time navigating from a project's home page to its source code or mailing list. IIRC they are hosted on separate subdomains, and not linked with each other, which is terrible UX. I had to manually change the URL host to git.sr.ht to get to the code.
Also, user error, I paid for it to learn that they forbid commercial projects — I like my code host to be free of any restrictions. Sadly Codeberg is the same, so the choice is either the awful Git(Hub|Lab), or self hosting.
I guess my payment served as donation to a FOSS-friendly service, which isn't too bad karma-wise.
Also, user error, I paid for it to learn that they forbid commercial projects — I like my code host to be free of any restrictions. Sadly Codeberg is the same, so the choice is either the awful Git(Hub|Lab), or self hosting.
I guess my payment served as donation to a FOSS-friendly service, which isn't too bad karma-wise.
At least for me, the article keeps going offline intermittently. Archive link: https://web.archive.org/web/20240308111845/https://protesila...
To some extent there's a horses for courses argument here: which projects stand to benefit from a high proportion of drive-by contributions? Which projects can appropriately leverage nuanced textual discussion?
If the Linux kernel had been hosted on GitHub from the start it would have turned out very different.
If the Linux kernel had been hosted on GitHub from the start it would have turned out very different.
> If the Linux kernel had been hosted on GitHub from the start it would have turned out very different.
Of course I get the point you're making and agree, but this is still an amusing statement to read :)
Of course I get the point you're making and agree, but this is still an amusing statement to read :)
And why not use Codeberg instead of GitHub? AFAIK it solves the problems the post mentions while staying in a libre platform
I cannot see active development of Sourcehut. You can see the latest closed `beta` label is two years ago: https://todo.sr.ht/~sircmpwn/todo.sr.ht?search=status%3Aclos...
That's a to-do list. You've filtered tickets for two tags (status:closed label:beta).
I think you can look at the actual project development here: https://git.sr.ht/~sircmpwn?search=sr.ht
If you're just after "the number/recency of closed tickets equates to development activity," then you could look here: https://todo.sr.ht/~sircmpwn/todo.sr.ht?search=status%3Aclos...
I think you can look at the actual project development here: https://git.sr.ht/~sircmpwn?search=sr.ht
If you're just after "the number/recency of closed tickets equates to development activity," then you could look here: https://todo.sr.ht/~sircmpwn/todo.sr.ht?search=status%3Aclos...
Is there any reason to use mailing lists for a new project? I totally get why you'd want to keep the mailing list structure for existing ones especially if your contributors are used to it, but it's such an off putting experience that I don't get why a newer project would want to use it. I read the article about why mailing lists are still good from sourcehut, but I think it just isn't convincing. So I'm genuinely wondering what I'm missing? I'm glad sourcehut is taking a different approach to other git services but I can't help but think that there's got to be a better way even if you don't want "GitHub style" pull requests.
Mailing list is an open standard that anyone can join. Git even sends patches to it via git CLI.
People talk about federation and decentralisation a lot, e-mail is sort of that.
But it sucks UX-wise compared to github. Linux can afford it, because it will always have enough contributors anyway.
People talk about federation and decentralisation a lot, e-mail is sort of that.
But it sucks UX-wise compared to github. Linux can afford it, because it will always have enough contributors anyway.
A mailing list is not the greatest thing in my opinion:
1. You have to subscribe to it 2. The interface for finding old issues can be bad (like long densely-packed threads with no search feature) 3. It forces me to manage my inbox (well, that's my problem)
They can all be solvable though. I never used sourcehut - are these all the same issues?
1. You have to subscribe to it 2. The interface for finding old issues can be bad (like long densely-packed threads with no search feature) 3. It forces me to manage my inbox (well, that's my problem)
They can all be solvable though. I never used sourcehut - are these all the same issues?
> threads with no search feature
If it's a mailing list then surely the mail is searchable using your choice of mail client?
If it's a mailing list then surely the mail is searchable using your choice of mail client?
Presuming you were subscribed to the mailing list at the time the issue was reported. Which may be true for your own projects, but is much less likely for arbitrary projects that you may be looking to report an issue on yourself.
Not for emails that were sent before you subscribed.
(and that means new contributors get the worse experience.. not ideal)
(and that means new contributors get the worse experience.. not ideal)
Lot of mailing lists offer the option to download mbox with old messages. So you can just download those for months/years when you were not subscribed.
they do? I don't think I've ever seen this in practice. And even if I do, having to download dozens of monthly archives is pretty annoying.
(Also for example SourceForge only gives mbox files to administrators, not to regular users [0])
[0] https://sourceforge.net/p/forge/documentation/Mailing%20List...
(Also for example SourceForge only gives mbox files to administrators, not to regular users [0])
[0] https://sourceforge.net/p/forge/documentation/Mailing%20List...
Sourcehut's specifically allows download of the full mailing list, or just the last 30 days.
Threads can also be downloaded individually.
And the search function is decent(ish) in the web interface.
Threads can also be downloaded individually.
And the search function is decent(ish) in the web interface.
I mostly read GNU mailing lists, and there mbox is offered https://lists.gnu.org/archive/mbox/ . Linux seems to offer a git repositories with the messages, which is bit annoying, but script-able.
Well, it is not perfect, much still, the hassle is one-time, so meh.
Well, it is not perfect, much still, the hassle is one-time, so meh.
It's one-time for one project, but is a repeated hassle over multiple projects, and likely a different hassle at that.
[deleted]
Should I put up the sircmpwn signal? Would be nice to see his take.
I thought he was banned for having unpopular opinions. Or was that just on lobsters?
On lobsters he was banned for shilling sourcehut, and knowing Drew, I find it hard to believe he's not already in this thread one way or another.
That's farcical. He was banned for having strong opinions about many things, meaning that nearly everybody would disagree with him about at least something, if not everything. The result was that nobody liked him so a pretext for banning him was devised. Hell, I disagree with him on many if not most things, but I don't think he should be banned for it.
Drew, if you're in this thread: I've argued with you several times before but the way you get 'canceled' for having strong convictions is an injustice. Stay true to you.
Drew, if you're in this thread: I've argued with you several times before but the way you get 'canceled' for having strong convictions is an injustice. Stay true to you.
Thanks Drew et al for Sourcehut, Hare Lang, principles, and more!
I tangoed with Fossil[1].. it was a nice experience. In the end, I self host everything in bare git repos on my own server. I don't have or want contributors so it's fine... plus, I have the server in the cloud anyway for backups, etc.
[1]: https://www.fossil-scm.org
[1]: https://www.fossil-scm.org
If you have a choice what to use, I can only recommend to compare the terms and conditions of gitlab, GitHub and sourcehut. Last time I checked, sourcehut‘s terms were much better for the customer.
As an example, check out paragraphs 8.6 and 10.2 here:
https://handbook.gitlab.com/handbook/legal/subscription-agre...
As an example, check out paragraphs 8.6 and 10.2 here:
https://handbook.gitlab.com/handbook/legal/subscription-agre...
I left githup due to how Microsoft enabled 2FA, now back to anon ftp via gemini.
I would like to find something like github and was thinking about sourcehut. But now I may think of looking elsewhere. But to be honest, anon ftp is good enough for me since my things are about as far from earth shattering as something can get :)
I would like to find something like github and was thinking about sourcehut. But now I may think of looking elsewhere. But to be honest, anon ftp is good enough for me since my things are about as far from earth shattering as something can get :)
I raised many of the author's point about Sourcehut several times. I'm an, enthusiastic FOSS supporter who has always advocated for alternatives to Github. But Sourcehut seems to take the worst out of everything. It strips down all the features, provides a web interface that seems to come out of the 1990s, removes anything that is even vaguely interactive in favour of emails, and it turns reviews and PRs a mess of emails and patch files that is impossible to browse.
Seriously, when we say that Github is bad, it doesn't mean that the solution is to get back to the software development cycles of the early 2000s and throw out of the window all the innovations made in the past two decades.
Sourcehut's extremely elitist and proudly feature-poor approach is only pushing away potential users and contributors, and I don't think it's doing a good favour to the community.
I would advise the author to give Forgejo a try (Gitea has almost become fully enshittified with its business plans and vision, so I wouldn't recommend it to anyone anymore). Everything is very similar to Github, but FOSS and self-hosted, and it takes a tiny fraction to run than the resources required by that shapeless beast called Gitlab.
Seriously, when we say that Github is bad, it doesn't mean that the solution is to get back to the software development cycles of the early 2000s and throw out of the window all the innovations made in the past two decades.
Sourcehut's extremely elitist and proudly feature-poor approach is only pushing away potential users and contributors, and I don't think it's doing a good favour to the community.
I would advise the author to give Forgejo a try (Gitea has almost become fully enshittified with its business plans and vision, so I wouldn't recommend it to anyone anymore). Everything is very similar to Github, but FOSS and self-hosted, and it takes a tiny fraction to run than the resources required by that shapeless beast called Gitlab.
> I raised many of the author's point about Sourcehut several times. I'm an, enthusiastic FOSS supporter who has always advocated for alternatives to Github. But Sourcehut seems to take the worst out of everything. It strips down all the features, provides a web interface that seems to come out of the 1990s, removes anything that is even vaguely interactive in favour of emails, and it turns reviews and PRs a mess of emails and patch files that is impossible to browse.
That's exactly what its goals are. Sourcehut is for people who want to do everything out of email. All of this is a feature. Stop trying to make it GitHub. If it's not for you, it's not for you.
For some of us, Sourcehut is a revelation. Sourcehut works for its users rather than its users work for it.
That's exactly what its goals are. Sourcehut is for people who want to do everything out of email. All of this is a feature. Stop trying to make it GitHub. If it's not for you, it's not for you.
For some of us, Sourcehut is a revelation. Sourcehut works for its users rather than its users work for it.
As someone who's found Sourcehut to be a great fit for my workflow, I fully agree that it's been a "revelation."
Is this the most Hacker News title ever?
document.title += " in Rust using ChatGPT"I really want forgejo and their federation to make a dent in the git world.
hope this doesn't sound sarcastic, what's the problem with github?
i've always defaulted to github, what are some the reasons not to use it?
sourcehut UI is atrocious I’m not sure why anyone uses it when codeberg, GitHub and GitLab exist.
Completely understandable and yet another example that practicality beats purity.
I love Emacs and have used it since the start of my programming career. It is so powerful and I consider it more like a portable programming environment than a text editor. But I find it's performance frustratingly slow. I accept that it will never be as fast as Vim, but when it takes as long or longer to boot up as a regular IDE it makes me question why I'm not using that. Plus there are large json files I can open up no problem in NeoVim that Emacs chokes on.
With that being said, there is no program that has come along that is a sufficient modern replacement for Emacs like Neovim is for Vim. Unless you've used Emacs heavily then it's just hard to understand. And it's not just being able to use a terminal or write some markdown/org notes in it.
It's built in support for IRC. Reading email. Emacs Speaks Statistics. It's being able to make functions and bind just about anything to a set of key chords. It's using things like restclient to send rest requests, and many other awesome things. Using Emacs kind of feels like programming in Smalltalk in a way.
With that being said, there is no program that has come along that is a sufficient modern replacement for Emacs like Neovim is for Vim. Unless you've used Emacs heavily then it's just hard to understand. And it's not just being able to use a terminal or write some markdown/org notes in it.
It's built in support for IRC. Reading email. Emacs Speaks Statistics. It's being able to make functions and bind just about anything to a set of key chords. It's using things like restclient to send rest requests, and many other awesome things. Using Emacs kind of feels like programming in Smalltalk in a way.
> I accept that it will never be as fast as Vim, but when it takes as long or longer to boot up as a regular IDE it makes me question why I'm not using that.
You can significantly increase startup speed by running the emacs daemon on boot and using `emacsclient` for each new instance.
You can significantly increase startup speed by running the emacs daemon on boot and using `emacsclient` for each new instance.
> but when it takes as long or longer to boot up as a regular IDE it makes me question why I'm not using that
How many packages do you have? I have over 200 enabled but my startup time is consistently >2 seconds on average. The `use-package` macro really helps here. (And now it’s built-in to Emacs 29!)
Yeah, performance is a bit of an issue. But recent development has put it on a good trajectory with native comp and better JSON handling.
How many packages do you have? I have over 200 enabled but my startup time is consistently >2 seconds on average. The `use-package` macro really helps here. (And now it’s built-in to Emacs 29!)
Yeah, performance is a bit of an issue. But recent development has put it on a good trajectory with native comp and better JSON handling.
For startup speed, use an Emacs server. For speed in JSON files, the new fixes for long lines in Emacs 29 should improve the situation markedly.
> The SourceHut web interface does not show any kind of indication that a message has an attachment. Last time I tried it, I had to download an mbox file and extract the patch from there. This was helped by the fact that I knew what I was searching for, but the experience was not pleasant anyway.
If it doesn't work as they expect, why not submit a PR to fix the issue on srht?
I'm pretty sure all of the 4 points the author listed can be easily fixed either by code or by talking to some veteran sourcehut users and finding the best solution for the issues. The blog post make it seem like the author is just expecting srht to be exactly like GitHub, which it isn't, plus it does seem like they're lazy to try to fix this issues and have decided to jump ship instead.
If it doesn't work as they expect, why not submit a PR to fix the issue on srht?
I'm pretty sure all of the 4 points the author listed can be easily fixed either by code or by talking to some veteran sourcehut users and finding the best solution for the issues. The blog post make it seem like the author is just expecting srht to be exactly like GitHub, which it isn't, plus it does seem like they're lazy to try to fix this issues and have decided to jump ship instead.
Or maybe he is busy maintaining his own projects and does not have time/ don't want to onboard and contribute to SourceHut ...
Then he does not have a right to complain about SourceHut.
Right, how dare he, complaining about a paid service.
> The blog post make it seem like the author is just expecting srht to be exactly like GitHub
The author complains users don't use the mailing list correctly or at all. That's something the author expects to work the way srht intended, but the users expect it to work like github. And that's pretty much the point of the article.
The author complains users don't use the mailing list correctly or at all. That's something the author expects to work the way srht intended, but the users expect it to work like github. And that's pretty much the point of the article.
>If it doesn't work as they expect, why not submit a PR to fix the issue on srht?
Because people have their own things to mind and does not always have time to commit to every oss project they use?
Seriously, "just submit a PR" is the worst comment you always expect to see in a discussion.
Because people have their own things to mind and does not always have time to commit to every oss project they use?
Seriously, "just submit a PR" is the worst comment you always expect to see in a discussion.
Because something is opensource and "easy to fix" are we expected to not talk about it?
No, it's just that srht was built with this in mind. If I were the author I would talk to some srht maintainers or people that have projects in srht to brainstorm solutions for my issues instead of just writing a blog post and jumping ship. The author doesn't mention at any time that they tried to talk to other maintainers about these problems.
The problem is that the general population do not want mailing lists. It is a self-selecting group that actively wants to use these for their projects.
Everything else you mention takes time and especially for projects like this the time is often great because you will hit roadblocks like "you are using the product wrong" when proposing changes/features.
Everything else you mention takes time and especially for projects like this the time is often great because you will hit roadblocks like "you are using the product wrong" when proposing changes/features.
So without the benefit of being able to add code for things I care about, and without an interest in helping more niche software projects the benefits over GitHub seemed to just evaporate.