To me one of the clear things that GitHub gave us was a structure around a person rather than a project. To me it felt liberating to quickly create a repository attached to my name than it was to go through the (what felt to me) very serious process of coming up with a project name and reserving it on sourceforge just to get a cvs or svn repository (along with website, mailing lists, issue tracking(?), etc, etc...). It felt like the mental load of "oh this is just a quick thing" was a lot easier with github.
> It gave projects issue trackers, pull requests, release pages, wikis, organization pages, API access, webhooks, and later CI.
Although it didn't give us this all at once. I still remember when we created a new user account in order to simulate an organisation, before they existed. I distinctly recall discussing with friends if we wanted to set up a bug tracker software for our project with the assumption that "GitHub will probably release one in a few months anyway". In the end we just kept a text file committed in the repository. Issues were announced a few months later.
If I remember correctly, it was also one of the few places sticking to the now-standard passing of the parameters via path rather than the '?' URL query part.
It might not seem like much now, but then the ease and simple beauty of having just github.com/user/repo - not only for web access but also cloning - was definitely some freshness factor.
And they weren't free until 2020: https://docs.github.com/en/get-started/learning-about-github...
Honestly, pretty sociopathic behavior right here.
You’re not exposing any new ideas. You’re just attacking.
There is no need to pretend for novelty in such a critic, indeed. Just because we don't reinvent it on the fly doesn't make the use of arithmetic worthless.
To the risk it might seem surprising, I actually completely agree that trust is essential to software creation and and use.
Actually I would more broadly frame it as, no trust, no viable sustainable society, no technical/cultural artifact.
But trust and societies can be realized without individualism as underlying chief paradigm.
That doesn't mean total negation of individual though. One alternative, among others yet different approches, can be state as a metaphor of individual like a cell in a social body. Thus the term metastasis, as when a cell starts to degenerate in self centric behavior at the expense of the health of the body as a whole. On the other hand, no cell, no body.
https://en.wiktionary.org/wiki/bruh for those who also wonder.
I use Fossil for all my freelance work and it so easily allows me to get right back into the context of a project, niche details and agreements had with a client, etc. No need to pollute the codebase or gather together a million emails or notetaking software just to get back up to speed.
It can still change, I hate the notion that because Git is so culturally embedded we couldn’t ever switch. Fossil makes it super easy to switch and the workflow is actually easier coming from Git.
Two things I keep coming back to: (1) The "opinionated / small-teams only" critique others have raised in this thread is real, and I think Fossil should own it instead of fighting it. The 5,000-engineer monorepo market is a solved problem (Git won). Fossil should own the 1-50 person bracket — where having issues, wiki, forum, and code in one self-contained, syncable SQLite file is a huge unfair advantage.
(2) AI agents are a brand-new reason to look at Fossil that didn't exist when Git won. Every repo is a queryable SQLite file. An agent reads tickets + wiki + code + history with one SELECT — not 47 GraphQL calls and a rate limit. RAG and MCP setups against the repo become trivial.
We're stuck on the name (fossilforge vs fossilhub). If you have an opinion: https://fossilhub.io | https://fossilforge.io — vote, get early access.
The self-hosted side is already shipping at fossilrepo.io if you'd rather run your own.
--- Disclosure: founder, so grain of salt accordingly.
You can even run it on shared hosting as a CGI (never done it myself).
The only thing that took some setup was sending email notifications.
> The "opinionated / small-teams only" critique others have raised in this thread is real, and I think Fossil should own it instead of fighting it.
I agree I use Fossil for multiple personal and small projects. Anywhere I can, really. It is very simple and everything is distributed.
palaeontology.dev ... too awkward.
museum.dev has a sort of "this is dead" ring to it.
Ironically what fossils are stored in within a museum is referred to as a "repository"..
Well, there's only 2 hard problems in computer science right?
I own a cute domain for that: repositoryum.com. I had the plans for it, but it's one of those that never came to a realization.
- amber.dev
- quarry.sh
You’ll probably need to play with gTLDs to find something that works.
Can also echo “scm” from fossil’s domain:
- amberscm.dev
Along with useX.com, Xhq.com, etc., patterns.
Of the two you have listed, I’d choose fossilforge, but would vote for an alternative TLD since .io has an expected meaning coming from GitHub.
It just... never was something majority actually want so they didn't really get any traction.
Issues wise you also get few nasty cases where you really do not want to keep it with project, like having clients send a bunch of screenshots or even videos of triggering some bugs can grow storage pretty quickly... and while extra few GBs on a file server isn't a big deal, keeping it with code repo just so someone can look at tickets locally is PITA, and you quickly get into "let's not use it, it just makes everything complicated and everyone repo bloated".
Someone could probably implement most of fossil features using git as backing store without all that much problems, the wiki/issues/whatever else features would just be separate, parallel branch hierarchy
I explicitly dislike the idea of using Git as the backing store. Forget the fact that Git is not native on Windows and is immensely bloated; the actual .git folder is a mess for backup systems when working locally compared to a single database file.
Sure but there is a big difference between being stored once (modulo backups) on a central server, and every developer needing to download all the resources for every issue and the entire wiki in order to work on the code at all. It works fine for sqlite, because they only have a handful of developers, so it's not a big deal for them each to have their own local copy of everything. But having to download GBs of issue and wiki data in order to make a pull request (however that would work with fossil) or otherwise contribute is a significant barrier to entry.
Git certainly had (and perhaps still has) worse user experience, but it worked and felt production-ready, with, of course, one of the largest open source projects in the world using it, and that made all the difference, perception-wise.
I was exposed to Mercurial before Git and I stubbornly tried to advocate for it over Git for a while. BitBucket, at the time, gave Github a good run for their money and had great Mercurial support and was what I preferred.
I'm not really sure VCS were ever differentiated for there to be a wide world of them. They all solved the same set of problems so similarly that it felt, to me, that there had to be one winner. Right now most of the competition is in the Git Porcelain space.
N.B. I actually have a soft spot for darcs, which was my first actual DVCS. I just loved it so much more than svn and refused to use svn in college and used darcs to actually manage my projects and push them to svn after.
I grew up on CVS and then Subversion. Played with Bazaar a little, mainly because it could use an SFTP location as the back-end.
And I still avoid Git if I can help it. I would/do figure it out when I have to, but it never feels comfortable. Such is my avoidance that I'm dabbling with Jujutsu although I'll still need to really sit down and read through it some more to grok the way it works.
I was expecting when I make a commit, I would have the facility to specify what issues it addressed and it would close them for me automatically. It seemed there is so much opportunity there to "close the loop" when the issue tracker, etc and integrated in your VCS, but it wasn't taken.
Personally speaking though, I don't want things automagically closed GitHub-style based on parsing a check-in comment. An issue ought to be closed with intention.
Sure, I get that. I was just disappointed that none of the project management stuff seemed terribly integrated in any way from my brief review. It seemed like opportunities there that were not taken.
I don't think he's got public sign ups turned on yet. Maybe hit him up on the Twitter for more info.
[0] - https://x.com/ragelink
"This service is completely free and run because a service like it should exist."
"All public repositories":
https://chiselapp.com/repositories/
I don't know if it has all the GitHub features people may be looking for.
Chisel runs on Flint, "The ISC licensed codebase behind http://chiselapp.com.":
https://chiselapp.com/user/rkeene/repository/flint/index
EDIT: Add "...should exist." sentence from the homepage.
Could something like github be made with fossil, aka fossilhub?
I believe the answer is ... in theory yes, in practice no. So this already means, if correct, the comparison between git and fossil is incorrect here. Fossilhub would not have dominated; git + github on the other hand did. Again, in theory a fossilhub could win over people to use it (and fossil), but people will compare it to github (back when github was still great) and become quite critical when fossilhub does not offer the same or similar set of functionality. At the least the core functionality - great issues + discussions, easy committing and changing of code and so forth.
Perhaps with enough resources, fossilhub could have conquered the world, but for whatever the reason, it did not, and I think this is in part due to the design. GitHub changed how people interact with repositories. They even made it easy to e. g. add files and change them online, at a later point in time. For instance in one project I am a co-maintainer and I rarely have to use the commandline; I can simply edit via the browser as it is. I don't think fossilhub would have done the same - actually, there is not even a fossilhub, so how would you want to compare git to fossil? It's not just the commandline code. Git has github; while it is a separate project, what does fossil have that people know and use?
> It can still change, I hate the notion that because Git is so culturally embedded we couldn’t ever switch.
We all have our dreams. All desert to become forests or agriculture may be a great idea. Effecting this is hard - but best luck to you betting on fossil here. I don't see it happening. Git raised the barrier here, even if only indirectly via github.
Why? I don’t see any practical reason.
"Just use SQLite" feels like missing the forest for the tree (the pun being coincidence here). That is, certainly any database out there already use all kinds of very efficient structures to walk graphs under the wood.
Maybe Git has a more bespoke approach to its specific goal of source code as main topic to deal with, and finner layer of abstractions. Which could also explain the clumsy leaky interface it presents.
I think this is a bad thing actually. Having something that's centralized but helpful-99%-of-the-time atrophies our collective archival skills. If everything had to be seeded by someone to keep it alive, everyone would be better at holding on to their copies of the things they really cared about instead of being able to assume they can just check it out again when they want to.
There should be no single place that something can be taken down. When a project on GitHub gets DMCAed it takes everyones' forks with it too. Just look at what happened when Nintendo took down the popular Switch emulators in 2024, where archival/continuation efforts consisted of people figuring out who had the latest revision checked out and sharing it. That was only possible because they were very popular project: https://news.ycombinator.com/item?id=40254602
Aside: I really love the Splatoon-ish header/footer animation on this site! Very unintrusive, adds a lot to the vibe, and also quickly gets out of your way as soon as you scroll down. I'm totally going to rip this off lol
Also it feels like "if it's not on GitHub, it doesn't exist", which is a bad thing. Feels like too many developers don't know that code can be stored somewhere else.
The alternative would be many sites, each one of them with their own DMCA rules.
What would be the better alternative?
Still dependent on centralized trackers. Same story with every useful package manager, there's always a middleman.
If anything Codeberg’s legal structure (being a non-profit) and vision makes it a lot more aligned with the objectives of free and open source projects than GitHub in the long run (which has always been the case but it’s just abundantly clearer today).
I think “for-profit corporations providing high quality public services for free” was a zero interest-rate phenomenon and never sustainable.
There is already such an organization in Europe:
https://www.softwareheritage.org/
Underfunded relative to the task, and the (accelerating) speed of free software production.
My laptop is on all the time, make a WASM slave and thousands of developers can give their CPU/Memory/Disk for build slaves.
Like bitcoin mining, there could be some competition between 3 parallel builds to pick the winner if the output is the same.
Codeberg does have some free CI runners, although I’m not sure what capacity they currently have, and how well it would work out if everybody decides to switch from GitHub today. They do encourage you to pick the smallest runner that works for you, and keep the workflows lean: https://codeberg.org/actions/meta
Or you can self-host your own runners too, of course.
Edit: there’s one caveat – Forgejo Actions are Linux only. If you need Windows or macOS runners, this won’t work for you. But... you could have a readonly GitHub mirror (which you should probably do if you want people to discover your project), and use the GitHub Actions runners for free :-)
Fun fact: Django is still running on Trac today, and has been for more than 20 years now: https://code.djangoproject.com/timeline
(I was not involved in setting that one up, though it's possible I helped get the private Trac that pre-dated it running, I honestly can't remember!)
But, my first issue tracker was bugzilla. Setting that up was a bit of a pain, and it didn’t integrate well with anything, but it was very satisfying to see “Zarro Boogs”.
I remember being interested in MantisBT and a few others (Launchpad for BZR?) mainly because it seemed they made a bunch of decisions for me.
In retrospect, it was probably the flexibility of projects like Bugzilla that heralded the "opinionated" approaches to software that followed. In many ways software also follows the patterns of the language they are written in . Bugzilla was written in Perl, so of course there is more than one way to do anything.
I had forgotten about Mantis, but that was the first tracker that the non-programmers in our group were comfortable using. It is a bit funny how quickly we all migrated to Github as a larger community as it became the default for just about everything.
Employers used GH so I switched but even now I use GH as a dumb git endpoint and do all my build/deploy with docker and shell scripts so switching for me is extremely cheap.
For work stuff I’ll use whatever I’m paid to use if I don’t get to make the call just as it was back in the svn days.
I guess that award goes to Gitlab now, which I will probably also remember fondly.
Honestly, Gitlab's CI is one of its killer features.
I really enjoy Gitlab CI.
But, nearly everything else (kubernetes management, AST, AI "DUO", work items, milestones, snippets, workspaces, "operations", "security dashboards", "value stream managements", "service desk") - ugh, awful.
I guess some of the artifact repository stuff is nice, but like; their terraform repository is probably the worst of all choices, all the downsides of the HTTP state backend and no upside..
It's so hit and miss; but! the CI is actually good..
Painfully true - I remember a company I was at replacing GitHub and a bunch of other tools with GitLab because it was better to pay for one tool that does it all. Kind of.
GitHub has their own: https://archiveprogram.github.com/
Software Heritage is a non-profit funded by UNESCO: https://www.softwareheritage.org/2019/08/05/saving-and-refer...
Although they're mostly the code / commit history, not so much surrounding metadata like issues, PRs, discussions, wiki, etc.
My memory is telling me that I set up Bugzilla at some point after I joined the core team, though that may have been someone else. When git started becoming a big deal, I spearheaded converting our big SVN repo into many git repositories, and set up the cgit web interface for it. We were still using Bugzilla at that point.
I left the project in 2009 or 2010 or so (I'd joined a small startup and didn't have much time for OSS, sadly), and rejoined in 2022. In the intervening years they'd stood up a GitLab instance with CI runners, and had migrated everything from Bugzilla to GitLab issues.
It's still a very small team (handful of active people), and the infra is mostly managed by one person. It's all very doable, even for small teams. We're very lucky that our infra is generously donated/sponsored, though we also probably get just enough in regular donations that we could pay for it ourselves if we had to. I really appreciate that we're not dependent on Github/Microsoft for anything. Seriously, if you told me 20 years ago that Microsoft of all companies was going to own the largest OSS code forge in the world, I would have thrown up. It still doesn't sit well with me.