Hi,
recently Sourcehut lost a user, someone quite reknown in the Emacs community that moved to GitHub.
In this blog post he explains the technical and political reasons why he moved to GitHub:
https://protesilaos.com/codelog/2024-04-30-re-emacs-github-freedom-microsoft/
More details about when he left Sourcehut last January:
https://protesilaos.com/codelog/2024-01-27-sourcehut-no-more/
Setting aside the political reason (not relevant here), he mentions that:
- sr.ht has very little network effect and attracted basically no contributors to his projects
- Patches he received on sr.ht were often malformed and needed to be manually modified before applied
- Patches sent as an attachment gets a ">" appended on the first line and this breaks the formatting
- The web UI of sr.ht does (did?) not have any indication that a message has an attachment, nor a button to download a patch so it's hard to tell patches from other emails (note: to be understood if he used to receive emails without a proper subject, as suggested by https://git-send-email.io)
He concludes mentioning that he understads that sr.ht is still in alpha state.
Posting this here only to underline also why people /leave/ Sourcehut: that's a valuable feedback, I think.
Would also be nice to see some glimps of a roadmap about the future of Sourcehut.
Thanks.
> Setting aside the political reason (not relevant here), he mentions that:> - sr.ht has very little network effect and attracted basically no contributors to his projects> - Patches he received on sr.ht were often malformed and needed to be manually modified before applied> - Patches sent as an attachment gets a ">" appended on the first line and this breaks the formatting> - The web UI of sr.ht does (did?) not have any indication that a message has an attachment, nor a button to download a patch so it's hard to tell patches from other emails (note: to be understood if he used to receive emails without a proper subject, as suggested by https://git-send-email.io)> > He concludes mentioning that he understads that sr.ht is still in alpha state.> > Posting this here only to underline also why people /leave/ Sourcehut: that's a valuable feedback, I think.
Agreed that there's valuable feedback. I would summarize your summary (I
did also read the article) as:
- He's looking for a more web-centric workflow.
- He values lots of feedback.
I work on a popular project on GitHub and we get a lot of bad feedback
and bug reports that take a considerable amount of time to filter. I
value that SourceHut has a higher bar to entry; it forces the person to
take extra steps and therefore filters out low-effort reports. That does
mean that you might miss some legitimate reports. But I'm a big believer
that if it's not worth the effort to report then it's probably not that
important.
That doesn't mean every project is right for SourceHut. I wouldn't
suggest that my current GH project move over here. But for my own
personal stuff, I couldn't imagine going back to GH.
The web interface parts; I can't comment on much as I don't use them.
I'm sure there's probably some improvements that can be made there if
anyone wants to take it on.
Just my take on the article, of course. Don't mean to diminish the
writer's perspective.
Дана 24/05/01 12:40PM, jman написа:
> https://protesilaos.com/codelog/2024-04-30-re-emacs-github-freedom-microsoft/
Skimming over this article, it contains a lot of false arguments. One
of the worst offenders being the fallacy that since Big tech are
contributors to Linux, we should use their AI-feeding platform.
(Right...)
GNU in general is broken for years now, anyway (OpenBSD is an eye
opener). The only thing of value they still have right now is the
uncompromising GNU GPL v3+.
When I read that article, my initial reaction is that I hope there's not much change in response to that, or that any change is purely additive, in the sense of letting project owners choose alternate workflows. It seems OK that different workflows are better for different projects, and that one forge might fit a particular project's needs better than another.
I hope it's not dragging this thread too far off-topic to ask, though: is sourcehut doing OK? I'm certainly still happy using it, and it's been stable and very nice to use from my perspective.
I've noticed two things that make me want to hear an update on how both the project and the business is doing, though:
1. Drew recently offered a fork of Redis, called Redict, and chose to host development on Codeberg.[1]
2. The only posts on the SourceHut blog[2] in the past year or so are the ones that discuss the notable outage from early 2024.
I'm not trying to sound any kind of alarm; things are working great for me, and I could continue to use sourcehut in its current state indefinitely.
I'm assuming all the news is good, and people are just too busy to stop and talk about good news, as happens frequently. If anyone close enough to know could make time for even a brief update, though, it'd be great to hear a bit about what's gone on since the review of the 2022 financial report, other than the unexpectedly accelerated datacenter move.
[1](https://redict.io/posts/2024-03-22-redict-is-an-independent-fork/)
[2](https://sourcehut.org/blog)
On Wed, May 01, 2024 at 03:43:34PM -0400, Geoff Beier wrote:
Subject: Re: Article about flaws of Sourcehut
> When I read that article, my initial reaction is that I hope there's not> much change in response to that, or that any change is purely additive,> in the sense of letting project owners choose alternate workflows. It> seems OK that different workflows are better for different projects,> and that one forge might fit a particular project's needs better> than another.> > I hope it's not dragging this thread too far off-topic to ask, though:> is sourcehut doing OK? I'm certainly still happy using it, and it's> been stable and very nice to use from my perspective.> > I've noticed two things that make me want to hear an update on how> both the project and the business is doing, though:> > 1. Drew recently offered a fork of Redis, called Redict, and chose to> host development on Codeberg.[1]> 2. The only posts on the SourceHut blog[2] in the past year or so are> the ones that discuss the notable outage from early 2024.> > I'm not trying to sound any kind of alarm; things are working great> for me, and I could continue to use sourcehut in its current state> indefinitely.> > I'm assuming all the news is good, and people are just too busy> to stop and talk about good news, as happens frequently. If anyone> close enough to know could make time for even a brief update, though,> it'd be great to hear a bit about what's gone on since the review of> the 2022 financial report, other than the unexpectedly accelerated> datacenter move.
That datacenter move did give sr.ht IPv6 connectivity.
Yes, that might deserve some Public Relation attention.
Having redict at Codeberg is like having Kubernetes at the Linux
Foundation or your favorite from https://projects.apache.org/projects.html
at the Apache Software Foundation. It avoids "too much control from
one player hassle".
Being independent is already in the title of [1].
Groeten
Geert Stappers
[1](https://redict.io/posts/2024-03-22-redict-is-an-independent-fork/)
[2](https://sourcehut.org/blog)
--
Silence is hard to parse
Страхиња Радић <contact@strahinja.org> writes:
> Skimming over this article, it contains a lot of false arguments. One > of the worst offenders being the fallacy that since Big tech are > contributors to Linux, we should use their AI-feeding platform.
Or this:
" I am aware of the problems and do know Codeberg. I cannot run my own
server due to the costs and time involved. The technical reason for
not opting for such alternatives is that I will not be getting enough
contributions there."
Using Codeberg is totally orthogonal to running your own server.
Codeberg is a community-operated platform; Forgejo is the software
powering that platform.
Network effect isn't a technical reason either. If I had a kid and they
told me, "Dad, my friend Bobby Tables jumped in a lake, so I have to do
it", I wouldn't buy that argument.
Nine tenths of the article boils down to "I'm switching to the hub
because network effect". And that's fine. Freedom means we're not
always going to agree with the choices of others. And at the end of the
day, I'm grateful that people have options.
They do bring up some technical issues they've had. They don't
mention trying to get those fixed, so I assume that bringing them up is
only a way to help rationalize a social choice.
> GNU in general is broken for years now, anyway (OpenBSD is an eye > opener). The only thing of value they still have right now is the > uncompromising GNU GPL v3+.
Regardless of how one feels about GNU, the article is just an opinion
piece from someone who writes Emacs packages, not a statement from GNU
or from someone who claims to speak for it. I'm pretty sure that GNU's
stance is diammetrically opposed to "GitHub FTW". They operate and use
their own code hosting platform, Savannah.
-- Chris
> Skimming over this article, it contains a lot of false arguments.
I've explicitely asked to keep the "political" part of that article out of this email thread. You can open another thread for that if you prefer.
I'm interested only in discussing the technical aspects and the user experience of Sourcehut.
Thanks
> When I read that article, my initial reaction is that I hope there's not much change in response to> that, or that any change is purely additive, in the sense of letting project owners choose alternate> workflows.
Totally fair point. I also want Sourcehut to improve while staying faithful to its "manifest". I think that both GitHub and Sourcehut cater to (or at least intersect) the same audience: software development. The workflows are known, we know what is needed, it's just a matter of how these collaborative workflows are implemented. I prefer the Sourcehut "way" but it's currently too raw for me to honestly feel like hosting a collaborative project.
For example, Sourcehut still does not wrap automatically emails. If you are reading this message on a browser, you have to scroll horizontally. For a forge that is based on mailing lists, that's pretty annoying.
> it'd be great to hear a bit about what's gone on since the review of the 2022 financial report,> other than the unexpectedly accelerated datacenter move.
I also opened a thread months ago but nothing substancial came out of that.
https://lists.sr.ht/~sircmpwn/sr.ht-discuss/%3C87a5rcjvil.fsf@city17.xyz%3E
No communication is bad communication (imo)
Дана 24/05/02 10:18AM, jman написа:
> I've explicitely asked to keep the "political" part of that article > out of this email thread. You can open another thread for that if you > prefer.
The "technical" arguments presented in the article are there just to
give its main (what you call "political") premise false sense of
validity.
There are many long-term free software projects which operate
successfully for years without Github (or Sourcehut, for that matter).
Using Github is not a prerequisite to maintain a quality free software
project. On the contrary, the "social network" nature of Github has
only lead to low quality "issues" and "PRs".
If a programmer can't manage formatting and sending patches via email,
it is correct to question the quality of his contribution.
I had no problem contributing to ~lanodan/Badwolf and ~bptato/chawan on
Sourcehut, using public-inbox and ticket trackers for those projects,
for example. The **only** reason I have not contributed to more
projects on Sourcehut, but instead did it on Github, such as Neomutt,
ELinks, sc-im, etc is because they are not yet on Sourcehut, so I had
to use Github.
On 2024-05-02 11:31, Страхиња Радић wrote:
> Дана 24/05/02 10:18AM, jman написа:>> I've explicitely asked to keep the "political" part of that article >> out of this email thread. You can open another thread for that if you >> prefer.> > The "technical" arguments presented in the article are there just to > give its main (what you call "political") premise false sense of > validity.> > There are many long-term free software projects which operate > successfully for years without Github (or Sourcehut, for that matter). > > Using Github is not a prerequisite to maintain a quality free software > project. On the contrary, the "social network" nature of Github has > only lead to low quality "issues" and "PRs".> > If a programmer can't manage formatting and sending patches via email, > it is correct to question the quality of his contribution.> > I had no problem contributing to ~lanodan/Badwolf and ~bptato/chawan on > Sourcehut, using public-inbox and ticket trackers for those projects, > for example. The **only** reason I have not contributed to more > projects on Sourcehut, but instead did it on Github, such as Neomutt, > ELinks, sc-im, etc is because they are not yet on Sourcehut, so I had > to use Github.
Not every contribution is code. If you make it difficult for people to
report issues or contribute docs, you are going to end up with a worse
product.
2024-05-02T09:31:48Z Страхиња Радић <contact@strahinja.org>:
> If a programmer can't manage formatting and sending patches via email,> it is correct to question the quality of his contribution.
This is a non sequitur, I think. Being able to use a system like the
email-based workflow has no bearing on whether or not they are able to
provide worthwhile contributions. That is ignoring non-code contributions
like documentation changes, issues, or translations.
--
Moritz Poldrack
https://moritz.sh
Дана 24/05/02 11:49AM, raingloom@riseup.net написа:
> Not every contribution is code. If you make it difficult for people to> report issues or contribute docs, you are going to end up with a worse> product.
Regarding reporting "issues", I don't see the problem. Anyone finding
writing emails hard would have a hard time using most software anyway.
See here for an example of how problem reporting should be done:
https://www.openbsd.org/report.html
Contributing documentation is not that different from contributing
code, also with regards to the quality of documentation. One needs to
know the software well to be able to write about using it.
Catering to the masses is a general plague of modern age, in more
fields than just software.
Дана 24/05/02 01:19PM, Moritz Poldrack написа:
> This is a non sequitur, I think. Being able to use a system like the> email-based workflow has no bearing on whether or not they are able to> provide worthwhile contributions. That is ignoring non-code contributions> like documentation changes, issues, or translations.
Maybe it is not immediately obvious, but it is still a filter.
Programmers won't have any issues with it. "Coders" might.