I no longer maintain my Emacs projects on Sourcehut
protesilaos.com
protesilaos.com
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.
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.
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.
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.
I'll stick to pushing to a bare Git repository via SSH for my personal projects. Plain Git works fine for that.
While the gogs developer only set the record straight and moved on with his life, the Gitea forkers kept drumming up controversy for weeks
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.
Gitea's CI was marked stable in 1.19 in March 2023.
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.
Q: Do I want contributors?
A: Yes, use GitHub.
A: No, use whatever I want.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.
Q: Do I want to actively antagonize contributors while torturing myself?
A: Yes, use SCCS.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.
what if the enshittification is making it hard to move?
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)
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.
https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_...
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.
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.
The biggest problem I see is duplicate issues being raised across forge issue trackers, which using a single forge doesn't fix anyways.
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.
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).
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.
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 prefer GitLab but I understand why GitHub is the default. Just different products and use cases.
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
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).
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.
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.
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
a simpler explanation is that GitHub has a simpler/better interface than alternatives, and most people already have an account.
* 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.
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.
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
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.
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.
You are fortunate, which is great for you, but your advice will not work for most people.
Because GP implies only github matters and that does not seem like truth to me.
gitlab would hint me "you absolutely don't care about an UI which is slow as mollasses but you maybe have stronger moral principles."
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?
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 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.
(This is from someone who is not a dev by profession and had no idea about version control at the time.)
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.
But it is typically breaks DKIM signature :-(
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.
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.
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.
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.
We can easily define a niche within which GitHub-awareness can be presumed but it's certainly not "most people".
You want it to be something that it isn't.
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.
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.
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 :)
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...
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?
If it's a mailing list then surely the mail is searchable using your choice of mail client?
(and that means new contributors get the worse experience.. not ideal)
(Also for example SourceForge only gives mbox files to administrators, not to regular users [0])
[0] https://sourceforge.net/p/forge/documentation/Mailing%20List...
Well, it is not perfect, much still, the hassle is one-time, so meh.
Threads can also be downloaded individually.
And the search function is decent(ish) in the web interface.
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.
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.
As an example, check out paragraphs 8.6 and 10.2 here:
https://handbook.gitlab.com/handbook/legal/subscription-agre...
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 :)
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.
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.
document.title += " in Rust using ChatGPT"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.
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.
You can significantly increase startup speed by running the emacs daemon on boot and using `emacsclient` for each new instance.
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.
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.
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.
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.