I simply need my tools to not run like shit. There are things that you cannot do with GitHub anymore that you once were able to. For example, reviewing 500 file PRS might be an "anti-pattern" in HN's mind on average, but there are a lot of real-world scenarios at actual businesses where this comes up and there's literally nothing you can do about it other than have tools that don't suck at the job.
I've been working on a self-hosted GitHub alternative in my spare time. The goal is to have a lightweight public instance for discoverability and community over reasonably sized projects and to also offer a freeware download of the same for private and other self-hosting needs. The entire focus is on the simplest possible thing. Absolutely zero energy into AI, LLMs, client-side rendering circuses, etc. All that really matters to me is code/issues/pulls - primarily in B2B SaaS contexts. I'm just trying to run a small team and manage a codebase for 1-100 customers. I don't need to run an entire war and I certainly don't need my tools to entertain me with an endless stream of shiny distractions.
Is it costly to do?
> In my experience, no they won’t help with gdpr takedowns
I would have expected that I could say "This is my code, hence this is my data, and I want you to remove my data from your website". I wonder how hard it is to file a complaint to the EU and see what happens.
But what about discoverability? Is there any good search engine for code? These days I often find more interesting projects when searching code on GH rather than by name or description on repos.
I'm all for the idea of self-hosting in abstract, but in practice I don't want to spend my life looking after services.
I'm all for the idea of growing your own rice, but in practice I'd rather pay someone else to do it for me.
I'm not trolling, I'm just emphasizing a super super important aspect which HNers tend to minimize, which is that self-hosting is work and even people who are technically able to do it might not want to.
Otherwise, yes, non-essential things are best delegated, especially when it's free. Some essential things also have to be delegated, if doing them yourself takes too much (like growing rice). The latter works best when the essential thing is a commodity with a wide choice of suppliers (like rice).
In practice, if you do not require 99.99% uptime SLAs, all you do is connect every 6 months to do a docker pull and update the image.
a) Sign up for an account in your forge: Do contributors really want another account? Does your captcha/email verification actually work (I've encountered ones that don't)? There are also forges that require you to ask for an account which is another hurdle.
b) Send an email: Configuring `git send-email` is alien to many contributors and may not even be doable in some corporate environments (OAuth2 with no app passwords allowed). Diverging from this is error-prone and against social norms which the contributor may not even be aware of (until they get flamed in the mailing list). You are also giving up automated CI which is a big part of the contributor feedback loop.
To be clear, going independent does indeed work for small personal projects (do not care much about contributions) as well as established ones (large incentive for new contributors to jump over hoops), and I'm fully aware that a lot of HNers do not see the need for those "niceties" provided by GitHub. But I feel that people often underestimate the barriers that they are putting up.
On the other hand, if I spent time and effort writing a patch for public release, I have no issues jumping through hurdles to see it published, whether I have to create an account or learning the correct incantation to git send-email. Usually the thing that stops contribution is finding the time and will to prepare a PR for review; in comparison to that effort, creating an account is trivial.
The way I see it, using a distributed VCS like git benefits from having a distributed ecosystem. Putting everything in Microsoft’s hand for them to train their commercial AI product on your code is a little reckless and short-sighted. And we could do with fewer siloes.
I know the author is accepting patches, but even learning that their forge exists, and that the user wants to contribute is stymied if the users search for projects starts at a github search.
Of course it has no interface, etc. but it is functional to push and share commits, and there is nothing to maintain other than ssh credentials.
> This is not a technical, but a social problem.
Indeed, and you've offered no solution by erecting a lot of social barriers
People trust a project with 5K stars on GitHub.com more than a self-hosted project.
VCs fund startups based on the star history.
Big companies decide which FOSS projects to use based on the star history.
Why do people trust these useless metrics? Ah yes because reading the code and deciding if it's any good is difficult.
No one has infinite time in the universe to read the code of all alternatives before deciding which one is best for their use case.
GitHub stars are a filtering mechanism.
Most engineers, when given 5 projects with the following star count - 5K, 2K, 500, 200, 100, will only evaluate the code of the first two projects.
Then most engineers are not doing their job properly, if you ask me.
I tried doing this for Open-VSX extensions for handling justfile:
https://open-vsx.org/?search=justfile&sortBy=relevance&sortO...
2.4k nefrob.vscode-just
2.5k kokakiwi.just
3.4k skellock.just
0.3k wolfmah-vscode.just-syntax
kokakiwi's has nextmost downloads, but its website and git repository is self-hosted on a site that was gone since December 2020, so also 5 years of staleness. I suppose that's another way to archive your extension.
nefrob's has fewer downloads yet, but got a single 5-star review (Open-VSX doesn't have a lot of active users), the GitHub repo was updated 3 months ago, and it seems alive. Also, the parser itself seems simplistic and admits to not get things perfect.
wolfmah's has been inactive for more than one year, and it contains a single commit.
It was even less obvious with Typst: There are 12 results for the keyword "typst", and the leading extension didn't have many downloads at all -- I can see now that it's #2 for downloads.
Altogether, downloads / stars / reviews are a great way to get an honest answer in many cases when there aren't commercial interests at play, since there are fewer incentives to game metrics.
The first two are more likely to get VC backing. Rug pull is a false assumption.
edit: lol you're an angel investor and I guess you feel attacked. I stand by what I said.
I presume you don't use any VC-backed projects like Google, Apple, Amazon, Facebook, etc.
You have proven your adversary's point exactly.
I also don't get why you wouldn't go for something like Forgejo/Gitea, or if you're really dead set on the email pattern like the author seems to, Sourcehut.
I moved my personal stuff to codeberg. There's also the advantage that fewer people have accounts so I get fewer pull requests that change thousands of lines and fail every single test.
Of course I could be wrong, predicting the future is difficult.
Imagine the noise if github ended up on a spam list.
It's literally far more trivial than you may think. (At least if you already own a VPS or a dedicated server.)
Basically, (1), add a git user, (2), configure .ssh/authorized_keys, and that's basically it!
To add a bit more security, you may also want to edit /etc/shells and add git-shell as a login shell, then change git user to use that shell, but that's entirely optional (and it'd actually make it less trivial to create add extra repos, so, for a single-user repos, you may want to delay doing that).
In all, the entire set of official instructions can be printed on like a single double-sided Letter / A4 piece of paper.
P.S. Actually, I guess it's 3 single-sided pages, but that's only because you'd be printing the example SSH key twice, which takes a quarter of an A4 each time, thus, the entire official instructions take almost 3 single-sided pages total.
Optionally, public repos: Set-up git-daemon in some /var directoy and do the git init dance there. Also touch the git-daemon-export-ok file to whitelist each repo for public serving. chown the repository directory to your own user so you can write there freely, while git-dameon can read and serve the contents to the world.
Everything is just dumping UI over a file system and executing command line stuff.
If you want that too take a look at forgejo or gitlab, both of which I use for self hosting. The setup is similar to setting up any other server that requires user accounts, a database, and exposed ports.
sudo apt-get install git
sudo dnf install git
(Etc)
In other words, the server is sshd.
Enjoy!
My question was posed because I believe the post did not read the original request carefully.
My experience is managing over a hundred thousand vms at once across multiple countries, and have managed large fleets of tens of thousands or hundreds thousand+ for decades. This is old hat.
My desktop runs Linux. My laptop runs Linux. My phone runs Linux. The phone is the only one without a running SSH server. I'm pretty sure the openssh server is also a default package in Fedora Workstation, it's just got the service disabled by default unless you flick on a check box in the Gnome window.
Windows Server also supports SSH, and has several shell options.
I couldn't answer for any Apple device.
I guess my experience is narrow, though.
Hey, how many git servers do you know not running Linux? That's an interesting question!
Edit: Curious what you think both GitLab and GitHub run on, and if those have ssh enabled or not.
This one's no different. I didn't even know Copilot was the issue until halfway through -- by then, I'd stopped caring.
If Copilot is your dealbreaker, fine. But don't bury the lead. Just say what you're switching to and why it's better. That's the useful part.
https://www.merriam-webster.com/wordplay/bury-the-lede-versu...
> A deliberate misspelling of lead, originally used in instructions given to printers to indicate which paragraphs constitute the lede, intended to avoid confusion with the word lead which may actually appear in the text of an article. Compare dek (“subhead”) (modified from deck) and hed (“headline”) (from head).
Further:
> In 1990, the American author and journalist William Safire (1929–2009) was still able to say: “You will not find this spelling in dictionaries; it is still an insiders' variant, steadily growing in frequency of use. […] Will lede break out of its insider status and find its way into general use? […] To suggest this is becoming standard would be misledeing […] But it has earned its place as a variant spelling, soon to overtake the original spelling for the beginning of a news article."