You must log in or register to comment.
This person obviously has their own way of doing things that works for them and that’s great. Some of his views are patently absurd though. This is mostly commenting on his reasons against using a forge and not a comment that he should do something differently.
Trust
100% fair and I think this is the main take-away from the blog post. If you don’t trust something, don’t use it. Full stop, the post could have ended there and been fine. But then it goes on to say:
You get a workflow imposed on you
You mean like forcing people to use email to submit pull requests to your self-hosted git repos? It doesn’t matter what you are doing, if you are working on an open source project you are going to have workflow limitations. This is arguing a fallacy.
In particular, your project automatically gets a bug tracker – and you don’t get a choice about what bug tracker to use, or what it looks like. If you use Gitlab, you’re using the Gitlab bug tracker. The same goes for the pull request / merge request system.
Nothing is forcing you to use these features so just don’t use them. Plenty of teams use 3rd party tools but host their code in a forge site. Having options available to you automatically is not the same thing as being forced to use them. If it was, JIRA wouldn’t exist because everyone would use github/gitlab/whatever’s built-in issue tracking and project management.
The majority of the post comes across as someone who just doesn’t like the forge sites and aside from the trust aspect, then spent a bunch of effort trying to create associations and limitations between things that don’t exist.
Trust is 100% the main reason not to use a forge site and all the other things cited are superfluous and/or very subjective.
I think his dude would be better er served by radicle. He can host his seed node, people can push their branches into namespaces in the bare git repositories there, they can request that those branches be merged into a branch in his namespace, they can create tickets that are all stored in the git repositories, comments on patches/merge requests/etc. are also in git, he can add trusted contributors, and so on.
People don’t have to create an account. Just a public key pair on their machine and they are off to the races.
I don’t know his email, but somebody could mail him and make him aware of radicle.
I wouldn’t mind doing a self-hosted git repo and only using cli if I didn’t have to also use email to do so.
Seriously the worst part. Email is a technology that should be left in the past. It’s just awful. There’s no good way to do email.
Do you mean sending patches by email? The author for the article also despises them as suggest alternatives for collaboration where you do “pull request” by people giving you a link to their repo and branch name (like literally asking you to try pulling from their git repo), or sending git bundle files which get around a lot of the problems of trying to send patch files around.
Yes. The only way to send patches without something like Github is over email. I don’t mind all the other stuff, but there’s no other way to do PRs than over email, and I hate email. I didn’t see that he gave alternatives. His preferred solution was an email
The formal PR button in a forge is a way to do that with one click, but a short email with all the same information is just as good.
Like, dawg, no it aint
Interesting read, I learned some things that git can do and its’s cool to know it’s possible, but I get the sense that „I’m just used to doing it this way” is the author’s main reason. Making most project communication private is a huge sacrifice, and if all projects did things this way then open source development would be far worse off.
I could imagine an „account-less” git forge that uses email verification to create user sessions that then allow conversation and contribution under that email address and name. You’d have to click a magic link in your email every time you wanted to create a session, but they could be long-lived and you don’t have to manage a password.
the AUR is already kind of like a git without a forge under the hood (albeit not for the usual git purpose). You authenticate with your arch account, which is also used for the forum (and maybe also the wiki)
I agree that having all the commentary in private by default is not ideal for open source. the email verification idea is interesting since it gives you the benefits of not having to create an account.
To me the article was interesting because it points out ways that git “just works” that people might not realize. Like that you can just create a bare repo and upload to that.
I think it’s an interesting idea, and I’d see it as fine for simple host + fetch. But as soon as you start interacting, I see it as far worse.
A personal support email may work, but as they write by the end, ticket tracking and collaborating on a platform with a shared web interface is much superior for information sharing and but also iteration (they talk about back and forth emailing earlier).
Self-hosting yet another platform/forge with its own account system is not viable to me either. (I’m still hoping for forgejo federation for a centralized account. Until then, GitHub seems like the best choice purely because it’s the biggest and everyone has an account and can contribute and post without account barriers.)
The idea that it could be a hosted repo with an integrated mailing list (and potentially bug tracker) is interesting, but ultimately, almost/actually a full forge then anyway.
Saying it’s “an interesting idea” makes it sound as if git wasn’t intended to be used like this from the start. But it was intentionally designed to allow posting patches to the Linux kernel mailing lists. It even has commands for producing email directly from the command line.
Sites like GitHub are the “idea”.
and Sourceforge now has a pretty bad reputation
The bad reputation is largely obsolete. The owner had changed to a bad owner with bad practices, but that owner was eventually replaced by a better owner again.
I still hate the UI though. We have much better alternatives today, which is why I don’t see any reason for anyone to go back to (or start) using Sourceforge. It’s no longer an issue of owner and bad practices, but solely of the platform itself with its UI/UX.
I don’t know if I’d agree that Sourceforge’s reputation has recovered. The previous owners’ actions of hijacking open-source projects and injecting adware into their installers absolutely destroyed any trust they had, and even years later few of the projects that left the platform in protest have returned.
Admittedly the lack of new/returning projects is likely because of how much better the competition is from a UX perspective, as you noted. But at least personally, that scandal is still the first thing to come to mind when I hear the name Sourceforge.
Yeah, I agree with that, and also feel like that. That’s why I called it “obsolete”, not wrong or an outdated assessment.
Most people who know Sourceforge probably feel like that. And those who don’t know it have no reason to get into it.
Introduction
I’ve written quite a lot of free software in my life. Most of it was from scratch: projects I started myself. So I get to choose where to host them – or rather, I have to choose where to host them.
These days, all my projects are held in Git. And mostly, I put them in ‘bare’ git repositories on my personal website.
I don’t use any git ‘forge’ system layered on top of Git, like Gitlab or Github, which automatically makes a bug tracking database for each project, and provides a convenient button for a user to open a merge request / pull request. I just use plain Git. People can ‘git clone’ my code, and there’s a web-based browsing interface (the basic gitweb) for looking around without having to clone it at all. But that’s all the automated facilities you get.
Occasionally this confuses people, so I thought I should write something about it.
Discussion with the author @ https://hachyderm.io/@simontatham/114111520633445984
