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.
>To me it felt liberating to quickly create a repository attached to my name
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.
Definitely not. That's been a thing for at least as long as mod_rewrite has existed (and I'm sure there's prior art). It was common long before GitHub.
It happened, but not as often as you'd think. In 2017 I was arguing with someone that the back button should work and URLs should be obvious in a fairly large project and they said "people are used to the back button not working - like a bank website".
1. not use query params for key entities in the URL
2. to stick user identifiers at the root path! totally unheard of to occupy such an important path at that point!
Taken together, this was entirely novel. Next to nobody did this. Twitter was the one other notable example, and that's literally all I can think of.
The URL bar was so different back then. It wasn't search by default. The average tech savviness of internet users was higher. People cared about URLs despite the fact most websites had garbage cgi-bin query string slop. Lots of folks had personal domain names. People typed URLs and shared them a lot - so this was a big deal, because they were memorable, unlike the other slop URLs at the time.
To give more character - HN's urls would have been considered exceptionally nice back then. The average URL was way worse and was littered with hundreds of query parameters.
A great deal of websites put your session token in the query params. PHP had first class ways of spending "sessions" to all urls. Essentially a cookie. It was disgusting.
GitHub revolutionized urls as a product. Even today, not many companies followed suit.
Reddit did it, linked in, most social media really, this is all just a throwback to /~user/ paths from apache and other early webservers. I think slashdot used the same convention.
I enjoy speculating on what could come from revisiting the first principles with our new tech stack.
The Fediverse makes it much easier to broadcast updates in a truly decentralized fashion. Maybe this can be the discovery layer instead of requiring a centralized social network in GitHub?
Git itself has many of the primitives needed, but issue tracking and CI/CD seem the main pieces still lacking. Seems likely that issues can be solved satisfactorily both natively in git, or in the fediverse. I bet that agents can pass branches/patches amongst themselves just fine, maybe native git (pulling from each others’ remotes on a crontab, or sharing patches by listserv) is actually completely viable now.
I also wonder if agents will cause a shift from forking and contributing back upstream, to more like horizontal gene transfer where people or tight teams broadcast their repos and other projects borrow/steal whatever may be useful. You see this with the Claws where maintainers are simply swamped with contributions and no way to verify whether they are correct/positive. (Things like “first time install on a Mac mini breaks at step 7, due to some iMessage issue” are fiendishly difficult to automate”)
I am still so salty that Git won out for the average project over Fossil. Sure Git has some performance advantages for massive codebases like the Linux Kernel, but the vast majority of projects will never run into performance limits from their VCS. Fossil’s internal tools (wiki, forum, tickets<issues>, etc) are just so useful to have versioned with your code in one file.
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.
"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.
It worked on ipv6 only for like a year, it seemed to be back this last month but it seems to be back down right now probably because of this whole github ragequit happening.
I feel like part of that was timing. IIRC, when git was already stable and usable as a daily-driver, Fossil was still sometimes requiring that you completely recreate your repo when updating to a new version.
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.
You can (and people did) do same kind of tooling based off git protocol and storage. Hell, even one for distributed code reviews.
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
Those screenshots and videos are taking up space SOMEWHERE, whether it be your inbox or your filesystem, why not have them as unversioned artifacts in your db? (Fossil supports this). Of course if you have multiple people working on it and many assets, other solutions would be better (shared cloud drives, etc). But for my use case of a storing textual information only (and perhaps a demo video, which many Git users often keep a video in their source and link it in the readme), Fossil works great to keep all my stuff together in the same context.
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.
> Those screenshots and videos are taking up space SOMEWHERE,
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.
Not without having a degraded git experience like shallow clones, or using hacks like LFS or Xet, and then you're back at the initial problem of depending on "something else besides your repo".
I tried out like five or six of those back when they were trendy, and they all had one or more of these issues that made them unusable:
* Changes being tied to a commit (akin to git notes) so issues could have different status and comments on different branches. No overall view of the project.
* Using their own branches to separate from code state, which made a huge mess when looking at your branches or git history.
* Using a separate space (like git notes does, I forget what this is called), which isn't included in the standard push/pull.
* All of the above being distributed, issues in your checkout could be very different than someone else's, and now you have to merge those too.
* No non-developer UI for project managers to see or comment on issues.
> 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.
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'm still using Mercurial whenever I can (including work!). The Tortoisehg GUI is good for doing reviews, and the command line is comfortable.
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.
If it got proper tooling this would be true—but the community will need to build it. Darcs has more out of the box & more existing ecosystems to work with. Pijul is barebones by design, ready to be scripted, there’s just not much out there.
Yeah I've played around with pijul over the years but it's still not at a maturity level that I would like and at this point I'm not sure how the actual work behind patch theory is progressing.
My first distributed VCS was Tom Lord's Arch. I may have started early, but it took me a long time to understand distributed version control, thanks in no small part to Tom Lord, lol. GNU.
When I tried Fossil it had things weirdly separated.
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.
This is a current architectural limitation, manifests (defining check-ins) and tickets are different types of artifacts and you cannot combine the card types into the same artifact. Changing this would likely break backwards compatibility with previous Fossil versions and I'd expect resistance. It may still be worth bringing up on the Fossil forum if you desire the feature.
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.
> I don't want things automagically closed GitHub-style based on parsing a check-in comment.
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 wanted to host our company wiki in Fossil, but there is no way to import it because Fossil completely separates versioned project docs and the built-in Wiki function. Our git-based wiki could be imported into Fossil as "docs" but would not receive the nice formatting, GUI editor or dedicated page that the Wiki function does. There is also no benefit to manually converting it all to Fossil Wiki as some of our wiki editors work on raw markdown.md files and commit changes by git which is not possible with the Fossil Wiki; everyone would be forced to use the online editor only, whereas currently we have a choice of markdown or Gitea's editor.
Part of the problem is that fossil is very opinionated. It's great if your development flow is similar to that of the sqlite team. But it is very difficult to get it to work for other workflows. And in particular, fossil is designed for use by small teams and isn't really designed to be used by large organizations. This is even explicitly mentioned in the "Fossil versus Git" page (https://fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki)
Funny timing — I've been working on a hosted Fossil service to scratch this exact itch. The integrated wiki+forum+tickets+code is killer for small teams, but most people who'd pick Fossil don't actually want to babysit a server. So we host it.
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.
there's a host your own version thats available now https://fossilrepo.dev live server (demo) in fossilrepo.io which is a modern wrapper UI. There's also the standard https://fossil-scm.org/ which you can also host yourself on a $5/mo server on Hertzner or the like.
I trust more a megacorp to survive more than 5 years than a personal host, I can't tell you how many times I've gone to a personal server where something I used was hosted and its dead.
Fossil is very easy to self host. If you already have a web server it needs maybe 10 or 15 lines of server config. If you want to avoid start up you need something to autostart/restart the server process. If you point it at a directory you can add a new repo simply by adding a Fossil file to the directory.
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.
And backups. Sqlite makes it easier but no backup process is easy. You always have to backup and restore at least once to have the confidence to rely on it.
It's another (big) point towards paying someone else to host it.
a lot of other commenters point out the dead connotation, so you could pivot the semantics and go for something like fossil.fuel? has some "oomph" to it, and represents a high energy density carrier, a feedstock that can go in many directions, oils, plastics, ...
being a software project makes the environmental connotation less important (using a different project would also cost server energy etc...) so its more clearly tongue in cheek
I think this shows that you do not consider all build-up options here. Let me explain that.
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.
> 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.
Hmm that's interesting to hear. I'm starting up a very small business this year (one guy selling shit at a craft fair booth) and I'm using plaintext accounting files in a Git repo for it. I wonder if Fossil could keep me from re-inventing some note taking and record keeping approaches. I'll have to look into what it can do.
It has a wiki, forum and issues included. So it definitely can do that, what fossil allows by default is to not have a docs/ or bugs/todo file, because its all in the server part.
A key feature of github is you could bug report on many projects without registering an account for each one, this is not true of fossil. if fossil is to be taken seriously, then it needs a distributed auto id system, oauth or the like.
I am a sucker for underdog software (anyone else using Ur/Web in prod?) and I was instantly infatuated when I first came across Fossil. I wasted a week of my life trying to fall in love with it but actually realising all the little things that make Git awesome. Beautiful diff output. Staging changes in hunks. Fixup commits, interactive rebase with autosquash. Git lets you treat not just your code as art but also your code evolution. In Fossil you don't get to clean up your branch into a coherent story. No, every path to and from dead-end blood-soaked alleys stays with you forever, unless you just don't commit anything until you have smoothed over all the details. No committing and pushing your WIP code to keep it safe (I mean you can, but you cannot then ever undo that). I'm sure other people feel very differently and that's ok. But Git's UX is on a completely different planet, imho.
Yes, I am someone who, when my branch code-wise is ready to be merged, I will still take however long it needs to clean the history into a coherent, bisectable set of patches.
To be fair, Fossil is kinda cool in many ways, but it's a downgrade for my dev UX. Also the configuration interface for access controls and suchlike to the repo server, issue tracker, etc. is... eccentric. I wouldn't be surprised to find some incorrectly/unsafely configured repos in the wild.
> But maybe the most underappreciated thing GitHub did was archival work: GitHub became a library. It became an index of a huge part of the software commons because even abandoned projects remained findable.
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
Archival is easy but copyright and IP law gets in the way. If we removed obstacles to making information accessible, it would lead to less concentration of power.
I don't agree with this. Github has existed for years and one of the reasons developers trust it is that they never monetized their "archival" work yet (TBD with all the new Copilot features).
The alternative would be many sites, each one of them with their own DMCA rules.
Torrent doesn't magically find peers, even with DHT the torrent files have seed nodes baked in. A middelman required for both the centralized trackers and trackerless torrents.
DHT seed nodes are optional. A torrent node that's already connected to the DHT doesn't need them. Most torrent software has some default nodes baked in, from which it can discover the whole DHT.
> Having something that's centralized but helpful-99%-of-the-time atrophies our collective archival skills.
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.
> I definitely cringed when Zig moved to Codeberg!
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.
>For a while, leaving GitHub felt like a symbolic move mostly made by smaller projects or by people with strong views about software freedom. I definitely cringed when Zig moved to Codeberg! But I now see people with real weight and signal talking about leaving GitHub. The most obvious one is Mitchell Hashimoto, who announced that Ghostty will move.
I didn't understand this. I perceive the Zig project and Mitchell Hashimoto / Ghostty to be at similar levels of "weight and signal." Especially because Ghostty is written in Zig.
It feels kind of like saying, "Oh, I didn't take this seriously when it was just Fabrice Bellard, but now that an actual influential person like Guido van Rossum is doing it, it's real."
It’s because the more visible people are, the stronger they have a pull on others. It’s not so much about person A vs person B but about what likelihood am I attributing to an individual or project to pull others along. For me projects moving off GitHub prior to Zig didn’t have that yet and even Zig itself didn’t feel that meaningful to me.
Their own example is an example of this. I've heard the name Fabrice Bellard but don't know who he is and don't know why I'd care, but Guido is a well-known name among python users and does hold weight. Looking up what Bellard is known for, I kind of expect this to be true of more people than not.
He's not as visible. I know those projects, not the people behind them. I don't know most of the people behind Python either, but I know Guido because his name keeps coming up when the Python project is talked about.
I agree with you. But I do see one crucial difference between the Zig and Ghostty announcements, namely that Ghostty did it purely for service degradation reasons while Zig did also mention ideological reasons such as GitHub’s relationship with ICE and their push for AI. Those were, naturally, much discussed points on HN. I can’t help but wonder if that contributed to the “cringing”.
Our announcement had plenty of examples of service degradation as well. People just become blind to all reason when somebody touches one of their political pet peeves (which sometimes might even be just referencing politics in the first place).
> Regardless of whether GitHub is here to stay or projects find new homes, what I would like to see is some public, boring, well-funded archive for Open Source software. Something with the power of an endowment or public funding to keep it afloat. Something whose job is not to win the developer productivity market but just to make sure that the most important things we create do not disappear.
The problem is GitHub spends on the order of $100m/year on providing free CI. Nobody else can compete with that. It's possible they could make it shit enough that a large number of projects will say "screw this we'll just pay for CI", but people really like free (and easy!) things so I think we are a long way from that point.
> make a WASM slave and thousands of developers can give their CPU/Memory/Disk for build slaves
WASM isn't a magic bullet for sandboxing. CI environments assume a full Linux. So you need to either ran a VM (with the attack surface that implies) or a write an x86 emulator in WASM (which would be very slow).
You also need anti-abuse to stop bitcoin miners from using your system. GitHub probably have full-time employees working on it.
> Like bitcoin mining, there could be some competition between 3 parallel builds to pick the winner if the output is the same.
It's a lot more complicated because many builds are not deterministic, you need to store artefacts, build secrets, etc.
Companies like golem.network or iex.ec have been working on this problem for a decade and they are still not easy to use.
It doesn't need to be thousands of developers. Whoever owns the project can use their machine for builds, or spend a few bucks a month on a VPS, or find a sponsor to pay a few bucks for them or provide their own machine (should be easy if the project is any size at all).
My theory is that we waste lots of resources on CI because it's invisible. If you can hear your fans spin up you might try to optimize more, even if the financial cost is still negligible. Back when every developer built the software and ran the tests on their own machine, slow-building projects were the exception not the norm. There was also a much faster feedback cycle for changes to the build and test processes.
Tooling around a self-hosted CI workflow really needs some work to make it as convenient as even the very difficult GitHub Actions.
And yet, GitHub Actions are notoriously broken, and serious customers are self-hosting their runners.
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 :-)
They are getting access to a supercomputer soon, and will be scanning all their archive for licensing information (using scancode and ort), security information, and other metadata.
I like Gitlab fine by ignoring pretty much everything it does other than host the source code and let me view READMEs in the browser (and for work, also merge requests). In general the more I have to use anything other than those, the more frustrated I get, which was also how I felt about Github in the past. I'm not sure I've ever had a non-frustrating experience when trying to set up a CI pipeline on any platform, so I guess Gitlab's CI isn't any better or worse than others in that regard. There are an awful lot of tabs on the left any time I look for something through those menus though, most of which I don't know what they do and I would probably not be happy to have to learn.
> I'm not sure I've ever had a non-frustrating experience when trying to set up a CI pipeline on any platform, so I guess Gitlab's CI isn't any better or worse than others in that regard.
Honestly, Gitlab's CI is one of its killer features.
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..
I don't hate using Gitlab CI once it's set up; I just hate "put shell scripts in YAML to define how this should work". The least annoying experiences I've had with them are when every entry is literally just a single line that invokes an external script; shell scripting is already annoying enough without having to also spend the time to understand a YAML schema for what order they get invoked in and what environmental variables are in scope (not to mention what the implicit inputs are; a few months ago I tried to add a task to run some check on the commit message for an MR, and I found that even on repositories where the merge commit option is disabled in favor of squashing or fast-forwarding, the top commit message is still a merge commit).
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.
GitLab's chief problem isn't that it does too much, it's that they really need to work on UX.
Everything is deeply nested. Many things hard to find. And the UI can be strangely slow or awkward in spots.
I recently worked a job where the client migrated to GitLab from GitHub at my suggestion. And while I think there was on the whole satisfaction with that, it did some with its own frustrations as well.
I liked bitbucket, it did its job, it didn’t break for me and I preferred mercurial.
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.
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”.
It's a bit fuzzy, but what I remember was getting it running was painless -- but there was a ton of effort in getting it configured.
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.
I've switched to GitHub from Trac because of spam. Despite using Akismet and bayesian filters, on a small instance, there were still several spam tickets if you didn't require an account (for the details, https://vincent.bernat.ch/en/blog/2011-migrating-to-github). I am a bit amazed that Trac still exists and is maintained today.
Damn Tenor's run by Google? I was always afraid this day would come. Guess its time to be relegated to the awfulness that is Giphy for the built-in GIF picker in applications.
Has Google ever done a good job with anything, other than search? I don't want to count YouTube since they bought it, but least they haven't ruined it...
An important part to me that gets overlooked is shared logins. Rust runs the tests of all known Rust projects in a tool called `crater`. I was analyzing a run identifying projects relying on internals of Cargo and opening issues. When making 200 issues by hand, it is a big help when the process is low friction: I had credentials for the site and allowing blank templates. Any time I came across a self-hosted instance, I usually ended up giving up.
This is something federation could help with: you would be able to use your account on, say, Codeberg to make issues on all self-hosted instances. Sadly, it’s still not in a great shape: https://forgefed.org/
(As a fallback, why not email the maintainers instead?)
I think I was one of the first people to try Flask. I learned Python so I could take advantage of AppEngine for free and easy modern hosting, which put me in the right spot when Flask launched. I've long been an admirer of Armin's, and recognized his domain before I clicked the link. As he points out, in those days, you didn't default to GitHub.
His post is a response to Mitchell's, from just a few hours ago. I'm impressed with how quickly he wrote a long-form, high-quality, well-reasoned post.
It's fun to read stuff like this and then reflect on the journeys of the projects I've been involved with. Most of my open source work has been done with self-hosted infra. My main example is Xfce: back when I started with them in 2004, we had a SVN server, using (I think) CVSweb's then-new SVN support for the web interface, and... maybe that was it?
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.
I use a self hosted Gitea instance and it's very simple. I was also surprised when Zig moved to Codeberg and had a big blog post about it, but now over time I start to see the reasons materialize in reality.
This archival project already exists, it is funded by France computer science research agency Inria, by Europe, and maybe by the UN through UNESCO if I'm not mistaken, but I really think it should still receive much more attention and funding to really pursue its goal: Software Heritage.
What we need is gitlab to finally integrate ActiviyPub so we can fork, comment, open merge request on all gitlab instances from our personal instance. Git is already decentralized, this isn't that hard to do.
Funny connection here between the proliferation of easy-to-install but not-quite-dependable dependencies and the recent spate of supply chain attacks.
And, at the same time, we have these AI tools that make it super easy to roll your own version of something. Feels like there's a big push from both sides to start reducing external dependencies.
I remember this old thing called Bugs Everywhere -- it was a bug/issue tracker which actually lived inside your hg repository. I wonder if we could standardize on something like that? or git notes with an issues ref? or something magical like that?
Then it's BYOR -- bring your own renderer. Trivial CLI bugtrackers, agentic nonsense, pretty web stuff, whatever and the data lives in the repo.
And probably the network/black-hole effect of platforms like GitHub, Linkedin and the like are hard to achieve with fully distributed solutions, all the more when the other side is backed by huge capital which absolutely love concentration of power.
Smaller, decentralised forges actually make lots of sense from a digital sovereignty point of view. Over reliance on a single instance like GitHub is not healthy in the long run. The issue they would have to solve is federation.
Yeah, federation is really the sticky bit. It's very frustrating for people to have to create yet another account in order to file an issue or submit a pull request.
And on top of that, spam is a huge issue. We've progressively further and further locked down new accounts on gitlab.xfce.org because the spam situation has just gotten so bad. We actually don't allow new "native" account creation at this point, and ask people to come to our Matrix channel to ask for an account. We do allow SSO from Github and gitlab.com, but some spam still sneaks through that way too.
I have my own personal Gitea instance that just doesn't allow outside users at all. I'd love to move all my personal projects to it, but at some point I would actually like to try to start a community around one or two of them, and I don't want to have to deal with spam.
I really like the idea of distributed forges, but am not familiar with viable solutions for federation. Are there good options available right now? Or at least a not-terrible option?
(Edit: Turns out there’s a very obvious and widely used option. git format-patch + git send-email is used to develop major open source software such as Linux, GCC, and Git itself.)
If you really think the UX of email is the same as the UX of a web-based forge, I'm not sure what to tell you.
You may prefer email over the latter, but I think these days you're in the minority. Your level of derision at this fact doesn't really change anything.
> But if projects move to something more akin to self-hosted forges, to their own self-hosted Mercurial or cgit servers, we run the risk of losing things that we don’t want to lose. The code might be distributed in theory, but the social context often is not. Issues, reviews, design discussions, release notes, security advisories, and old tarballs are fragile.
Thankfully, this doesn’t have to be the case – Forgejo imports pretty much everything mentioned. (1) Whether you decide to move to Codeberg or host your own instance, you won’t have to lose the context.
But I definitely agree we should also have a metadata archive of some sort, for both GitHub, Codeberg, and self-hosted projects.
(1): Not sure about code reviews, and you don’t get the security advisories, though I’m sure it can be replicated with a CI workflow somehow?
> The leaders there once cared a lot about keeping GitHub available even in countries that were sanctioned by the US.
The link leads to a blog post saying how they mercifully unblocked the users in Iran, but that was some time after they first suddenly blocked those users without any recourse and any way to even download their data and private repositories hosted there, without any advance warning…
If it wasn't for GitHub self-hosting and open-source development would be much more difficult. Like the article says open-source development was obviously still happening but it was a smaller space. I appreciate how many apps I've interacted with because of GitHub like OpenGOAL, IINA, and Ghostty along with the services running on my servers at home like Immich, Glance, Filebrowser, and audiobookshelf. I even used GitHub myself for some private repos, but I've since migrated them to a self-hosted Forgejo container.
This may be an unpopular opinion, but gatekeeping is sometimes good - in which case we call it by the more positively connotated term "curation".
A bigger space isn't necessarily a better one if it's flooded by low-quality content. Does a one-person project on GitHub have any advantage over one that uses a local git repo? I don't think so. It has a disadvantage because you're dependent on GitHub, and even worse, that first-year student learning development now thinks GitHub is an integral part of development.
If projects had to start with a local git repository and a local process, before being able to migrate to GitHub upon gaining minimal notability, developers would be more accustomed to the idea that a project isn't its hosting and that platforms like GitHub are optional. I think this would encourage more local-first attitudes instead of centralization, and that would be good. It wouldn't be seen as weird to send someone a zip file of the thing you're working on.
Plus (only tangentially related) imagine where the JavaScript ecosystem would be if packages like is-array and left-pad couldn't get accepted to npm.
SF was exe + source code as zip file. And an admin that made all the decisions and had to for a project,
I do not agree with details, because it was for me before and after git.
So the hidden denominator here is and still is git, which sparked a tooling frenzy with reversing flow by being online server first (it wasn’t named cloud back then).
So even today, all splinters are doing something around git. That hasn’t changed.
What I really miss is the some sort of standardization that GitHub provided for a brief period of time. Projects would get no love aka stars when you couldn’t easily be used even for the experts. Some convenience as well as tooling evolved, devops became a thing.
I think of the future of a concept called cocooning. The JavaScript expert of today would be puzzled to write code on a notepad in a html file, because it has become so meta, being TypeScript essentially.
There is so much tooling going on that especially Python before AI already felt like I would miss something out if I would code more than 100 lines and that there must be libraries that abstract this all away and instead of coding I should google better.
AI is one thing, but the cluttered tech stacks aren’t really sparking any interest or joy in me, I think it is the not invented here syndrome or because I can story.
I miss the die hard coders, who stick to a tech stack which simply worked, not optimizing for weird use cases which are contrived at worst and rarely needed at best.
This became evident with the decline of data sheets, because Grunt, Gulp etc. as build tools were great but slow. We JavaScript devs couldn’t any longer joke about the compile times of the Backend dudes. And besides that, build times costs you focus, money, cpu time. But this was the main currency.
With AI I stopped trying out lots of tools because they feel like a weekend project by some dude who blasted his Claude budget.
Over are the fork and commit wars. Until AI battles itself this hard for quality source code I will stick to GitHub.
Tangled supports hosting your own knots. Why wouldn't the current GitHub CEO choose to support self-hosted "databases". GH infra can protect you from all the traffic (ssh and http spam), while you keep the social aspect.
I don't need ~100 extra features, I need a reliable platform. If that means I need to self-host the storage, runners, etc. fine.
I was hoping that by now we would have an up and coming DVCS replacement that functioned as a "github in a box" (pretty sure fossil has been described as that, but it's too much on the cathedral side). Being able to mirror an entire project though version control would significantly help with mirroring if we go back to a decentralized world. Maybe going back to decentralized project hosting is just another pendulum swing similar to how compute moved to the cloud...
If it wasn’t for SourceForge I’m not sure my life would’ve ended up where it is! They use to promote projects they liked and ended up putting Waterfox on their front page a few times. Really sad when they started blasting people with ads and swapping out installers with adware for popular projects.
By that time I moved to Microsoft’s CodePlex, if anyone else remembers that? Felt like I was the only one using it at the time! I remember the connection speeds to it were atrocious, but appreciated they’d share ad revenue from the downloads of a projects page which was nice. I remember it was actually super expensive to offer downloads [for binaries] back then, using these code hosting websites was the only way to do it for “free”
I also remember SourceForge fondly, before the ad infested thing.
Specially, I remember not "getting" Github at some point. Bitbucket had mercurial support, sourceforge had SVN, and all the Cool projects lived in SF (I'm talking mid/late 2000s).
The first time I navigated into a github project and just saw the code three I was puzzled. (SF was centered on the project/product while GH focused on the code.
Hey, I also remember Launchpad and Bazar, and adding an individual new source to my apt. Launchpad had something like CI before everyone from what I remember.
This “slowly dying” effect is what happens to every company that gets acquired by big monster slug companies like Microsoft.
What Microsoft acquisitions still have any of their original spark left in them? Or Oracle? Or IBM? Or Google? Etc…
Hell, some Microsoft originals from
inside the company like Xbox have even lost their edge.
Money is great and I’m sure I’d take the big check, too, but I’m surprised more tech founders don’t think of their legacy in this way when they decide to sell out.
It’s considered a grand accomplishment to essentially lead the wonderful thing you created to its slow demise and hand it over to apathetic quarterly earnings zombies.
We used bitbucket for years in our academic research group because GH didn't allow private repos. But otherwise it was better to use, so when they allowed that, we made the switch.
> That is one of the great ironies of modern Open Source. The distributed version control system won, and then the world standardized on one enormous centralized service for hosting it.
Cycles everywhere indeed. Perhaps we should ->
> GitHub wrote a remarkable chapter of Open Source, and if that chapter is ending, the next one should learn from it and also from what came before.
Indeed! Try to learn from the inevitable iterations to make the next instance at least that slightly better.
... Where the stuff meets the metastuff it seems all works under very similar forces.
My thinking is step-by-step - it works on the individual level, and it scales up.
Day to day is step by step and a step today funds the step tomorrow.
I remember that. I've been writing code since the 70's, and have lost count of the number of source code management systems I have been forced to learn. Early on they were over engineered, and a pain in the ass to learn. Then they'd go "out of fashion" and the next pain-in-the-ass over engineered nonsense was forced and learned. I resisted git FOR FUCKING EVER because i was so tired of relearning how to do the same fucking thing slightly different in some other convoluted over engineered system. But it looked like Git was going to be the forever winner, so I finally gave in and learned git through and through. Fuck now its dying!?
I think github is at a point that its too hard to ignore just like google is even though we might not like what they are doing now but we were the one made them this big.
Radicle is a good answer, coupled with a reborn Usenet, maybe Nostr. We have like never before the ability to communicate and cooperate yet most fails to understand and implement that.
Nearly any of us could run an XMPP/Matrix server and federate with friends or Nostr/{0xchat,whitenoise}, all with audio, video, text, file exchange etc, yet less than 1% do that.
Simply people, techies as well, have forgot the meaning of personal ownership and therefore are owned by someone else.
IMHO the problem is always the same. Social networks (and I consider Github as one in this discussion) tend toward centralization and hence monopolization. But monopolization tends towards enshittification. It happens again and again. There's a new cool player, it grows, it's not the cool player anymore. Rinse and repeat.
Unfortunately I don't have a clever solution (to the social aspect of the problem).
Maybe something like https://fossil-scm.org/home/doc/trunk/www/index.wiki is worth another look. Although Forgejo is probably an easier switch from GitHub. If their federation ideas play out well, that could be a good outcome from all this
> That is why I find what is happening to GitHub today so sad and so disappointing. I do not look at it as just the folks at Microsoft making product decisions I dislike. GitHub was part of the social infrastructure of Open Source for a very long time.
Well ... sad or not sad ...
I remember I was very displeased when Microslop, 'xcuse me, Microsoft assimilated GitHub. But for some time it worked quite ok-ish, to some extent. Only more recently are things suddenly breaking down. I am not sure why they break down right now, but I suspect it has a lot to do with the new AI-focus Microslop pushes onto everything. The AI permeates everything like a virus and contages things (I just tried to create a new word from contagious ...). It seems as if this is the real new corporate identity. As Microslop proceeds to dive deeper into AI (they have no alternative anymore, they already sold their soul to AI), they forget that GitHub used to be about people, first and foremost. Steve Ballmer also had this with his fake antics aka "Developers developer developers" many years ago in 1999 (https://www.youtube.com/watch?v=8fcSviC7cRM - at the least Ballmer was entertaining, the current slop-CEO is boring to no ends).
> So when I think about GitHub’s decline, I also think about what came before it, and what might come after it.
Well - the decline happens largely because Microslop totally struggles. They could have decoupled departments and what not, but they decided the corporate strategy is AI-only now. And this creates a ton of downstream problems. So in many ways the current CEO is to be held responsible; he is in charge since 2014 after all. Fatigue kicks in. I am not saying a single person alone is responsible for failure, but it is clear that whatever the reasons for problems, this comes from Microslop first and foremost. The GitHub team contributes to this decline as well (services no longer working suddenly) but it really is induced from top, aka the overall corporate strategy here. And I also don't see Microslop being able to change course - they overcommitted already, so now the decline is indeed unstoppable.
> GitHub changed how Open Source feels, and later npm and other systems changed how dependencies feel. Put them together and you get a world in which publishing code is almost frictionless
Frictionless is a strange word. I retired from rubygems.org when shopify flooded the zone with ... corporate agenda. The final straw was the 100k download limit ("past that point we disallow you from removing old code you published to rubygems.org", which meant that people would download old code and assume that I would maintain that, which clearly was a lie, so thanks for that RubyCentral ... a year after that they went amok and mass-fired numerous devs; the whole story is a bit more complicated than that, but I can now wisely nod my head, since I retired about a year from that before that mass-fire devs event unfolding). I think if you have a source code hosting service in place, no matter what it is, you need to think about making publishing code super-easy at all times, including the UI. GitHub did this, sort of; I notice this when I compare it to gitlab. Perhaps gitlab has more features, but using it is soooooo much more annoying compared to GitHub. Codeberg lacks features on the other hand. Offering a good service here is actually difficult. It almost seems as if there are no clever UI designers anymore.
> My first Open Source projects lived on infrastructure I ran myself. There was a Trac installation, Subversion repositories
Well. I hated using Trac. Reporting issues is of course possible, but it feels so much more cumbersome than github issues. What could help would be to kind of make semi-universal IDs, e. g. I register once, but then I could use the same account on many different issue trackers. Right now I need to register for each instance and that is just tedious. I keep a password file (don't tell anyone) and I noticed that, say, after about 100 different websites and names and password, it just becomes unmanageable. Yes, I could use software to help me with that, but I decided that I simply no longer want to have a gazillion accounts. I almost never register for phpBB webforums (though discourse appears to be killing phpBB anyway).
> You could find forks, and old issues and discussions all stayed online.
That is true in general, but I would like to remind the blog author here that when the xz backdoors utils were found, Microslop took down the whole repository INCLUDING discussions. I remember that because I also discussed this on the xz utils github issue; and next day when I looked for more discussions, the whole thing was gone. Microslop censored here. Lateron the repository was back again, some days later, but if I recall correctly the whole discussion section was also gone. Microslop did not like the discussion; perhaps it was the author too, but the initial removal was from Microslop. So why was that bad? The whole discussion contained valuable information for people who were not yet familiar with this. Thus, Microslop deprived people of that information. Since then I am very wary about "trusting" Microslop or any private actor here when it comes to censorship. So I would not trust the "discussions stay online" claim here.
> Before GitHub, Open Source was a much smaller world.
Not that much smaller right-before GitHub and right-after it became available.
> but in the number of projects most of us could realistically depend on.
Most FOSS I realistically depend on I don't obtain from GitHub actually.
> There were well-known projects, maintained over long periods of time by a comparatively small number of people.
There were even more not-well-known projects, maintained for less time, by a larger number of people. They just weren't that many of them in one place.
> You knew the names.
You absolutely did not know the names. Post author is just thinking of the names they knew as though those were everybody.
> reputation mattered in a very direct way.
And now it doesn't?
> We took pride (and got frustrated) when the Debian folks came and told us our licensing stuff was murky or the copyright headers were not up to snuff, because they packaged things up.
RedHat was just as popular a distribution; and most users used Windows (like they do today); and the BSD distributions were a thing (although we didn't have Apple's BSD, i.e. MacOS)
> You absolutely did not know the names. Post author is just thinking of the names they knew as though those were everybody.
I absolutely knew the names of the people I interacted with and whose projects I used. I even went to conferences with some of them. When I worked on my first web portal for Ubuntu we had a total of about ~4 dependencies and all was vendored. I knew the person who packaged my Python libraries for Debian.
You might call it an inaccurate description of history but it is very much my experience.
That's one project. You did not know every name, or most names, in FOSS generally. Today as well - a project which uses GitHub still needs a mailing list, web forum, chat channel (Matrix/IRC/discord/Telegram/whatever) to discuss and coordinate, and that hasn't changed.
As for whether signal to noise ratio on mailing lists was high - that really depends on the list. I don't see that much noise on GitHub repositories, to be honest - it's not easy to post noise that many people will see, so there's not much motivation for it.
SVN (subversion) was working excellent for my team, about 20 yrs back. I never saw sufficient justification for the complexity brought in by Git.
But as I say, New tech invades the world and makes the perfectly working old tech as incompatible, just by changing the world around it. So git became a necessity imposed.
There was a big hype around it (you probably remember it), and around distributed version control, if you weren't using a DVCS you were suddenly seen as an inferior computer programmer and hence your employment opportunities were diminishing. That perspective when it comes to almost all-things programming-related has only accelerated ("if you're not quick to adapt to agentic AI you will lose your cushy job!"), with the recent AI craze the latest example of that.
I'm working pretty hard on building what comes after Github, but I'm going full-tilt boogie and trying to also work out what comes after Git.
I'd love to have a longer conversation with you about how we can seed a better system, because on the off chance I'm successful I have a once-in-a-generation opportunity to fix past mistakes.
To be clear for the past five years I've done nothing but write OSS code (https://github.com/conartist6) while sharing pretty much all my engineering thoughts on a public Discord server (https://discord.gg/NfMNyYN6cX), so I'm not very worried at all that a person determined to find out would be unable to tell if I'm legit. You just can't fake 20,000 hours worth of public toil.
I'm not sure if your aware, but in American English, "con artist" is another term for a scammer. Someone who does "cons", short for "confidence tricks" (or "confidence schemes") where you gain someone's confidence in order to take advantage of them in some way, usually financial fraud.
¯\_(ツ)_/¯ I'm me. 's not likely to change is it? I could color inside the lines and hope it buys me a nice life, but if I was that kind of person I would never have tackled this insane of a project
I guess I happily invite people to disrespect me for superficial reasons. Baseless disrespect keeps me motivated. Sorting out people who are only kicking tires also helps protect my time.
The ones who show real curiosity, those are the people I'll give my full attention to any day of the week.
> What GitHub Gave Us
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.
>To me it felt liberating to quickly create a repository attached to my name
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.
Definitely not. That's been a thing for at least as long as mod_rewrite has existed (and I'm sure there's prior art). It was common long before GitHub.
It happened, but not as often as you'd think. In 2017 I was arguing with someone that the back button should work and URLs should be obvious in a fairly large project and they said "people are used to the back button not working - like a bank website".
Path parameters has nothing to do with history replacement breaking the back button, did you mean to respond to someone else?
i've seen people argue about how the back button should work this year on HN
GitHub was one of the first popular places to
1. not use query params for key entities in the URL
2. to stick user identifiers at the root path! totally unheard of to occupy such an important path at that point!
Taken together, this was entirely novel. Next to nobody did this. Twitter was the one other notable example, and that's literally all I can think of.
The URL bar was so different back then. It wasn't search by default. The average tech savviness of internet users was higher. People cared about URLs despite the fact most websites had garbage cgi-bin query string slop. Lots of folks had personal domain names. People typed URLs and shared them a lot - so this was a big deal, because they were memorable, unlike the other slop URLs at the time.
To give more character - HN's urls would have been considered exceptionally nice back then. The average URL was way worse and was littered with hundreds of query parameters.
A great deal of websites put your session token in the query params. PHP had first class ways of spending "sessions" to all urls. Essentially a cookie. It was disgusting.
GitHub revolutionized urls as a product. Even today, not many companies followed suit.
They're still the gold standard.
Reddit did it, linked in, most social media really, this is all just a throwback to /~user/ paths from apache and other early webservers. I think slashdot used the same convention.
Reddit doesn't have users at top level (point 2 of the parent post). This is I think a very distinctive factor, at least at that time.
That was just a byproduct of how Rails did routing based on the URL
I enjoy speculating on what could come from revisiting the first principles with our new tech stack.
The Fediverse makes it much easier to broadcast updates in a truly decentralized fashion. Maybe this can be the discovery layer instead of requiring a centralized social network in GitHub?
Git itself has many of the primitives needed, but issue tracking and CI/CD seem the main pieces still lacking. Seems likely that issues can be solved satisfactorily both natively in git, or in the fediverse. I bet that agents can pass branches/patches amongst themselves just fine, maybe native git (pulling from each others’ remotes on a crontab, or sharing patches by listserv) is actually completely viable now.
I also wonder if agents will cause a shift from forking and contributing back upstream, to more like horizontal gene transfer where people or tight teams broadcast their repos and other projects borrow/steal whatever may be useful. You see this with the Claws where maintainers are simply swamped with contributions and no way to verify whether they are correct/positive. (Things like “first time install on a Mac mini breaks at step 7, due to some iMessage issue” are fiendishly difficult to automate”)
I am still so salty that Git won out for the average project over Fossil. Sure Git has some performance advantages for massive codebases like the Linux Kernel, but the vast majority of projects will never run into performance limits from their VCS. Fossil’s internal tools (wiki, forum, tickets<issues>, etc) are just so useful to have versioned with your code in one file.
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.
I wonder what tradeoffs make Git faster for large repository. Though for a long time that excluded large blobs.
Git has format dedicated for storing snapshots of trees and diffing them, fossil just uses SQLite and few tricks to keep size small
Of tree, or of sub-DAG?
"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.
None, it just received the help of the vast majority of well-payed SWE to make it that way
Now is a great time for somebody to buy fossilhub.com and create a new community.
I know someone[0] who is working on exactly this right now: https://fossilrepo.io/
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
There's also "Chisel - Fossil SCM Hosting".
"This service is completely free and run because a service like it should exist."
https://chiselapp.com/
"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.
This appears to be down.
It worked on ipv6 only for like a year, it seemed to be back this last month but it seems to be back down right now probably because of this whole github ragequit happening.
I already saw fossilhub.io mentioned in this thread, actually.
I feel like part of that was timing. IIRC, when git was already stable and usable as a daily-driver, Fossil was still sometimes requiring that you completely recreate your repo when updating to a new version.
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.
You can (and people did) do same kind of tooling based off git protocol and storage. Hell, even one for distributed code reviews.
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
Those screenshots and videos are taking up space SOMEWHERE, whether it be your inbox or your filesystem, why not have them as unversioned artifacts in your db? (Fossil supports this). Of course if you have multiple people working on it and many assets, other solutions would be better (shared cloud drives, etc). But for my use case of a storing textual information only (and perhaps a demo video, which many Git users often keep a video in their source and link it in the readme), Fossil works great to keep all my stuff together in the same context.
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.
> Those screenshots and videos are taking up space SOMEWHERE,
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.
I haven't checked but surely you can only check those out if you need them?
Not without having a degraded git experience like shallow clones, or using hacks like LFS or Xet, and then you're back at the initial problem of depending on "something else besides your repo".
as far as I can tell, fossil doesn't support that. but I could be wrong.
I tried out like five or six of those back when they were trendy, and they all had one or more of these issues that made them unusable:
* Changes being tied to a commit (akin to git notes) so issues could have different status and comments on different branches. No overall view of the project.
* Using their own branches to separate from code state, which made a huge mess when looking at your branches or git history.
* Using a separate space (like git notes does, I forget what this is called), which isn't included in the standard push/pull.
* All of the above being distributed, issues in your checkout could be very different than someone else's, and now you have to merge those too.
* No non-developer UI for project managers to see or comment on issues.
> 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.
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'm still using Mercurial whenever I can (including work!). The Tortoisehg GUI is good for doing reviews, and the command line is comfortable.
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.
You might like pijul if you like darcs
If it got proper tooling this would be true—but the community will need to build it. Darcs has more out of the box & more existing ecosystems to work with. Pijul is barebones by design, ready to be scripted, there’s just not much out there.
Yeah I've played around with pijul over the years but it's still not at a maturity level that I would like and at this point I'm not sure how the actual work behind patch theory is progressing.
My first distributed VCS was Tom Lord's Arch. I may have started early, but it took me a long time to understand distributed version control, thanks in no small part to Tom Lord, lol. GNU.
Same, then moved to bazaar which was really easy and nice.
Of course moved on to git but I still think bazaar did many things better.
When I tried Fossil it had things weirdly separated.
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.
This is a current architectural limitation, manifests (defining check-ins) and tickets are different types of artifacts and you cannot combine the card types into the same artifact. Changing this would likely break backwards compatibility with previous Fossil versions and I'd expect resistance. It may still be worth bringing up on the Fossil forum if you desire the feature.
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.
> I don't want things automagically closed GitHub-style based on parsing a check-in comment.
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 wanted to host our company wiki in Fossil, but there is no way to import it because Fossil completely separates versioned project docs and the built-in Wiki function. Our git-based wiki could be imported into Fossil as "docs" but would not receive the nice formatting, GUI editor or dedicated page that the Wiki function does. There is also no benefit to manually converting it all to Fossil Wiki as some of our wiki editors work on raw markdown.md files and commit changes by git which is not possible with the Fossil Wiki; everyone would be forced to use the online editor only, whereas currently we have a choice of markdown or Gitea's editor.
Found a link to the Fossil forum thread I opened about this very problem of the split between Fossil Wiki and docs:
https://fossil-scm.org/forum/forumpost/e19ed2bfea94fc91f544c...
You can link the commit with the ticket by including its hash in the commit message, and then mark the ticket as fixed. See here:
https://stackoverflow.com/questions/5761669/how-to-fix-a-tic...
Part of the problem is that fossil is very opinionated. It's great if your development flow is similar to that of the sqlite team. But it is very difficult to get it to work for other workflows. And in particular, fossil is designed for use by small teams and isn't really designed to be used by large organizations. This is even explicitly mentioned in the "Fossil versus Git" page (https://fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki)
Funny timing — I've been working on a hosted Fossil service to scratch this exact itch. The integrated wiki+forum+tickets+code is killer for small teams, but most people who'd pick Fossil don't actually want to babysit a server. So we host it.
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 should continue with a name which is related to fossils, fossillab.io, boneyard.dev and so on…
fossilised.dev .. maybe british spelling.
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?
> what fossils are stored in within a museum is referred to as a "repository"
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.
Yeah, museum sounds like dead and rot… However on my small site [1] that’s the name of the fossil repos page
[1]: https://hdrz.cc/museum
FYI your cert is expired.
The best know hosted Fossil service is https://chiselapp.com/
boneyard.dev evokes something dead but that name kinda goes hard
"countryclub.com" - ie, a bunch of fossils :)
Maybe something fossil-adjacent:
- 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.
Or, hear me out, we learn to host our own shit again and stop giving all our data to $megacorp after the inevitable buyout.
there's a host your own version thats available now https://fossilrepo.dev live server (demo) in fossilrepo.io which is a modern wrapper UI. There's also the standard https://fossil-scm.org/ which you can also host yourself on a $5/mo server on Hertzner or the like.
I trust more a megacorp to survive more than 5 years than a personal host, I can't tell you how many times I've gone to a personal server where something I used was hosted and its dead.
Fossil is very easy to self host. If you already have a web server it needs maybe 10 or 15 lines of server config. If you want to avoid start up you need something to autostart/restart the server process. If you point it at a directory you can add a new repo simply by adding a Fossil file to the directory.
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.
And backups. Sqlite makes it easier but no backup process is easy. You always have to backup and restore at least once to have the confidence to rely on it.
It's another (big) point towards paying someone else to host it.
Its less of a worry given ts distributed.
For the name: Use something with amber in the name.
a lot of other commenters point out the dead connotation, so you could pivot the semantics and go for something like fossil.fuel? has some "oomph" to it, and represents a high energy density carrier, a feedstock that can go in many directions, oils, plastics, ...
being a software project makes the environmental connotation less important (using a different project would also cost server energy etc...) so its more clearly tongue in cheek
I think this shows that you do not consider all build-up options here. Let me explain that.
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.
> in theory yes, in practice no
Why? I don’t see any practical reason.
For me it was Mercurial, but yeah, being done by Linus and adopted in the Linux kernel was the killer feature for Git's adoption.
If Git was created by a random dude, it would never taken off.
> 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.
Hmm that's interesting to hear. I'm starting up a very small business this year (one guy selling shit at a craft fair booth) and I'm using plaintext accounting files in a Git repo for it. I wonder if Fossil could keep me from re-inventing some note taking and record keeping approaches. I'll have to look into what it can do.
It has a wiki, forum and issues included. So it definitely can do that, what fossil allows by default is to not have a docs/ or bugs/todo file, because its all in the server part.
A key feature of github is you could bug report on many projects without registering an account for each one, this is not true of fossil. if fossil is to be taken seriously, then it needs a distributed auto id system, oauth or the like.
I am a sucker for underdog software (anyone else using Ur/Web in prod?) and I was instantly infatuated when I first came across Fossil. I wasted a week of my life trying to fall in love with it but actually realising all the little things that make Git awesome. Beautiful diff output. Staging changes in hunks. Fixup commits, interactive rebase with autosquash. Git lets you treat not just your code as art but also your code evolution. In Fossil you don't get to clean up your branch into a coherent story. No, every path to and from dead-end blood-soaked alleys stays with you forever, unless you just don't commit anything until you have smoothed over all the details. No committing and pushing your WIP code to keep it safe (I mean you can, but you cannot then ever undo that). I'm sure other people feel very differently and that's ok. But Git's UX is on a completely different planet, imho.
Yes, I am someone who, when my branch code-wise is ready to be merged, I will still take however long it needs to clean the history into a coherent, bisectable set of patches.
To be fair, Fossil is kinda cool in many ways, but it's a downgrade for my dev UX. Also the configuration interface for access controls and suchlike to the repo server, issue tracker, etc. is... eccentric. I wouldn't be surprised to find some incorrectly/unsafely configured repos in the wild.
> But maybe the most underappreciated thing GitHub did was archival work: GitHub became a library. It became an index of a huge part of the software commons because even abandoned projects remained findable.
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
Archival is easy but copyright and IP law gets in the way. If we removed obstacles to making information accessible, it would lead to less concentration of power.
I don't agree with this. Github has existed for years and one of the reasons developers trust it is that they never monetized their "archival" work yet (TBD with all the new Copilot features).
The alternative would be many sites, each one of them with their own DMCA rules.
What would be the better alternative?
Why are you thinking in terms of “sites”? I was imagining something more like a GitTorrent.
> something more like a GitTorrent
Still dependent on centralized trackers. Same story with every useful package manager, there's always a middleman.
BitTorrent has supported trackerless torrents for twenty entire years :p https://github.com/sparkslabs/kamaelia/blob/master/Sketches/...
Torrent doesn't magically find peers, even with DHT the torrent files have seed nodes baked in. A middelman required for both the centralized trackers and trackerless torrents.
DHT seed nodes are optional. A torrent node that's already connected to the DHT doesn't need them. Most torrent software has some default nodes baked in, from which it can discover the whole DHT.
> Having something that's centralized but helpful-99%-of-the-time atrophies our collective archival skills.
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.
Yeah first thing I do when I come across a repo I like is to clone it. I've seen a few reverse engineering projects disappear before my eyes.
> I definitely cringed when Zig moved to Codeberg!
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.
Codeberg's achilles heel for me is not supporting custom domains for repos.
>For a while, leaving GitHub felt like a symbolic move mostly made by smaller projects or by people with strong views about software freedom. I definitely cringed when Zig moved to Codeberg! But I now see people with real weight and signal talking about leaving GitHub. The most obvious one is Mitchell Hashimoto, who announced that Ghostty will move.
I didn't understand this. I perceive the Zig project and Mitchell Hashimoto / Ghostty to be at similar levels of "weight and signal." Especially because Ghostty is written in Zig.
It feels kind of like saying, "Oh, I didn't take this seriously when it was just Fabrice Bellard, but now that an actual influential person like Guido van Rossum is doing it, it's real."
It’s because the more visible people are, the stronger they have a pull on others. It’s not so much about person A vs person B but about what likelihood am I attributing to an individual or project to pull others along. For me projects moving off GitHub prior to Zig didn’t have that yet and even Zig itself didn’t feel that meaningful to me.
But you might think about it differently.
Their own example is an example of this. I've heard the name Fabrice Bellard but don't know who he is and don't know why I'd care, but Guido is a well-known name among python users and does hold weight. Looking up what Bellard is known for, I kind of expect this to be true of more people than not.
You don't care about the man, myth, and excellence himself who has created FFmpeg and QEMU, two of the most influential pieces of software ever made?
He's not as visible. I know those projects, not the people behind them. I don't know most of the people behind Python either, but I know Guido because his name keeps coming up when the Python project is talked about.
I agree with you. But I do see one crucial difference between the Zig and Ghostty announcements, namely that Ghostty did it purely for service degradation reasons while Zig did also mention ideological reasons such as GitHub’s relationship with ICE and their push for AI. Those were, naturally, much discussed points on HN. I can’t help but wonder if that contributed to the “cringing”.
Our announcement had plenty of examples of service degradation as well. People just become blind to all reason when somebody touches one of their political pet peeves (which sometimes might even be just referencing politics in the first place).
Zig catching strays
> Regardless of whether GitHub is here to stay or projects find new homes, what I would like to see is some public, boring, well-funded archive for Open Source software. Something with the power of an endowment or public funding to keep it afloat. Something whose job is not to win the developer productivity market but just to make sure that the most important things we create do not disappear.
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.
The top sponsors are quite telling: US tech companies and hyperscalers, Abu Dhabi, French Government and some french universities.
Codeberg?
The problem is GitHub spends on the order of $100m/year on providing free CI. Nobody else can compete with that. It's possible they could make it shit enough that a large number of projects will say "screw this we'll just pay for CI", but people really like free (and easy!) things so I think we are a long way from that point.
"Nobody else can compete with that"
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.
> make a WASM slave and thousands of developers can give their CPU/Memory/Disk for build slaves
WASM isn't a magic bullet for sandboxing. CI environments assume a full Linux. So you need to either ran a VM (with the attack surface that implies) or a write an x86 emulator in WASM (which would be very slow).
You also need anti-abuse to stop bitcoin miners from using your system. GitHub probably have full-time employees working on it.
> Like bitcoin mining, there could be some competition between 3 parallel builds to pick the winner if the output is the same.
It's a lot more complicated because many builds are not deterministic, you need to store artefacts, build secrets, etc.
Companies like golem.network or iex.ec have been working on this problem for a decade and they are still not easy to use.
It doesn't need to be thousands of developers. Whoever owns the project can use their machine for builds, or spend a few bucks a month on a VPS, or find a sponsor to pay a few bucks for them or provide their own machine (should be easy if the project is any size at all).
My theory is that we waste lots of resources on CI because it's invisible. If you can hear your fans spin up you might try to optimize more, even if the financial cost is still negligible. Back when every developer built the software and ran the tests on their own machine, slow-building projects were the exception not the norm. There was also a much faster feedback cycle for changes to the build and test processes.
Tooling around a self-hosted CI workflow really needs some work to make it as convenient as even the very difficult GitHub Actions.
And yet, GitHub Actions are notoriously broken, and serious customers are self-hosting their runners.
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 :-)
They are getting access to a supercomputer soon, and will be scanning all their archive for licensing information (using scancode and ort), security information, and other metadata.
I absolutely loved Trac. Getting a Trac setup as step 1 in starting a new open source project was just an unbelievable amount of friction.
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!)
Weirdly, I also have fond memories of Trac despite absolutely despising it at the time for “doing too much and excelling at nothing as a result”.
I guess that award goes to Gitlab now, which I will probably also remember fondly.
I like Gitlab fine by ignoring pretty much everything it does other than host the source code and let me view READMEs in the browser (and for work, also merge requests). In general the more I have to use anything other than those, the more frustrated I get, which was also how I felt about Github in the past. I'm not sure I've ever had a non-frustrating experience when trying to set up a CI pipeline on any platform, so I guess Gitlab's CI isn't any better or worse than others in that regard. There are an awful lot of tabs on the left any time I look for something through those menus though, most of which I don't know what they do and I would probably not be happy to have to learn.
> I'm not sure I've ever had a non-frustrating experience when trying to set up a CI pipeline on any platform, so I guess Gitlab's CI isn't any better or worse than others in that regard.
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..
I don't hate using Gitlab CI once it's set up; I just hate "put shell scripts in YAML to define how this should work". The least annoying experiences I've had with them are when every entry is literally just a single line that invokes an external script; shell scripting is already annoying enough without having to also spend the time to understand a YAML schema for what order they get invoked in and what environmental variables are in scope (not to mention what the implicit inputs are; a few months ago I tried to add a task to run some check on the commit message for an MR, and I found that even on repositories where the merge commit option is disabled in favor of squashing or fast-forwarding, the top commit message is still a merge commit).
Ah, super valid point.
I use the command invocation to run python scripts. I tend to believe that CI is just a controlled way to do things you would do locally.
> I guess that award goes to Gitlab now
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.
GitLab's chief problem isn't that it does too much, it's that they really need to work on UX.
Everything is deeply nested. Many things hard to find. And the UI can be strangely slow or awkward in spots.
I recently worked a job where the client migrated to GitLab from GitHub at my suggestion. And while I think there was on the whole satisfaction with that, it did some with its own frustrations as well.
Trac is in many ways what motivated me to build out an app in Python rather than in PHP for redistribution. It had a great plugin system!
I liked bitbucket, it did its job, it didn’t break for me and I preferred mercurial.
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.
Trac was great.
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”.
Bugzilla was relatively painless to setup but it already had a bit of the Jira going on - in that it had SO MANY OPTIONS!
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.
It's a bit fuzzy, but what I remember was getting it running was painless -- but there was a ton of effort in getting it configured.
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.
It's fun when you find these various things still in the wild - they're all still out there!
https://dwarffortressbugtracker.com/my_view_page.php
Bugzilla was too big/complex for pretty much every company I ever worked in :D
Trac was perfection. Self-hosted and just the right amount of features.
I've switched to GitHub from Trac because of spam. Despite using Akismet and bayesian filters, on a small instance, there were still several spam tickets if you didn't require an account (for the details, https://vincent.bernat.ch/en/blog/2011-migrating-to-github). I am a bit amazed that Trac still exists and is maintained today.
This got me thinking about code.google.com, I can't believe Google dropped the ball that hard.
…have you met Google?
Man what a blast from the past. I was on that team before it got shut down.
Memories...
To add salt to the wound: https://killedbygoogle.com/
Damn Tenor's run by Google? I was always afraid this day would come. Guess its time to be relegated to the awfulness that is Giphy for the built-in GIF picker in applications.
Has Google ever done a good job with anything, other than search? I don't want to count YouTube since they bought it, but least they haven't ruined it...
didn't they ? There is 4x more advertising for 4x less content and the recommendations are pretty crappy.
Reading this and mitchellh's post I was curious about code archival services, and found a few projects.
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.
An important part to me that gets overlooked is shared logins. Rust runs the tests of all known Rust projects in a tool called `crater`. I was analyzing a run identifying projects relying on internals of Cargo and opening issues. When making 200 issues by hand, it is a big help when the process is low friction: I had credentials for the site and allowing blank templates. Any time I came across a self-hosted instance, I usually ended up giving up.
This is something federation could help with: you would be able to use your account on, say, Codeberg to make issues on all self-hosted instances. Sadly, it’s still not in a great shape: https://forgefed.org/
(As a fallback, why not email the maintainers instead?)
I think I was one of the first people to try Flask. I learned Python so I could take advantage of AppEngine for free and easy modern hosting, which put me in the right spot when Flask launched. I've long been an admirer of Armin's, and recognized his domain before I clicked the link. As he points out, in those days, you didn't default to GitHub.
His post is a response to Mitchell's, from just a few hours ago. I'm impressed with how quickly he wrote a long-form, high-quality, well-reasoned post.
> His post is a response to Mitchell's, from just a few hours ago.
Is there a link to Mitchell's post somewhere? I can't find one in the article.
https://mitchellh.com/writing/ghostty-leaving-github
Thanks!
https://news.ycombinator.com/item?id=47939579
That’s because most of this post was hanging around as a draft. I originally wrote it after Zig left but I didn’t finish or publish it.
It's fun to read stuff like this and then reflect on the journeys of the projects I've been involved with. Most of my open source work has been done with self-hosted infra. My main example is Xfce: back when I started with them in 2004, we had a SVN server, using (I think) CVSweb's then-new SVN support for the web interface, and... maybe that was it?
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.
xfce is integral part of my life. Thank you for working on it
I use a self hosted Gitea instance and it's very simple. I was also surprised when Zig moved to Codeberg and had a big blog post about it, but now over time I start to see the reasons materialize in reality.
> We Need an Archive
This archival project already exists, it is funded by France computer science research agency Inria, by Europe, and maybe by the UN through UNESCO if I'm not mistaken, but I really think it should still receive much more attention and funding to really pursue its goal: Software Heritage.
https://www.softwareheritage.org/
What we need is gitlab to finally integrate ActiviyPub so we can fork, comment, open merge request on all gitlab instances from our personal instance. Git is already decentralized, this isn't that hard to do.
Forgejo is slowly working on federation
Funny connection here between the proliferation of easy-to-install but not-quite-dependable dependencies and the recent spate of supply chain attacks.
And, at the same time, we have these AI tools that make it super easy to roll your own version of something. Feels like there's a big push from both sides to start reducing external dependencies.
I remember this old thing called Bugs Everywhere -- it was a bug/issue tracker which actually lived inside your hg repository. I wonder if we could standardize on something like that? or git notes with an issues ref? or something magical like that?
Then it's BYOR -- bring your own renderer. Trivial CLI bugtrackers, agentic nonsense, pretty web stuff, whatever and the data lives in the repo.
I've often wondered why no one has built an issue tracker with Git notes, or if one exists, why it's not widespread.
https://github.com/git-bug/git-bug
And probably the network/black-hole effect of platforms like GitHub, Linkedin and the like are hard to achieve with fully distributed solutions, all the more when the other side is backed by huge capital which absolutely love concentration of power.
"We Need an Archive"
Before we had FTP, which made easy to mirror stuff with "lftp mirror -p".
HTML is not good for archiving.
We have to rethink those protocols so that mirroring is made easy, and "git clone" is not an answer sorry.
Smaller, decentralised forges actually make lots of sense from a digital sovereignty point of view. Over reliance on a single instance like GitHub is not healthy in the long run. The issue they would have to solve is federation.
Yeah, federation is really the sticky bit. It's very frustrating for people to have to create yet another account in order to file an issue or submit a pull request.
And on top of that, spam is a huge issue. We've progressively further and further locked down new accounts on gitlab.xfce.org because the spam situation has just gotten so bad. We actually don't allow new "native" account creation at this point, and ask people to come to our Matrix channel to ask for an account. We do allow SSO from Github and gitlab.com, but some spam still sneaks through that way too.
I have my own personal Gitea instance that just doesn't allow outside users at all. I'd love to move all my personal projects to it, but at some point I would actually like to try to start a community around one or two of them, and I don't want to have to deal with spam.
Oh we have a neat solution for that. Just give us your government issued id! I'm joking of course.
Thank you for maintaining Xfce! It's the best de around.
I really like the idea of distributed forges, but am not familiar with viable solutions for federation. Are there good options available right now? Or at least a not-terrible option?
(Edit: Turns out there’s a very obvious and widely used option. git format-patch + git send-email is used to develop major open source software such as Linux, GCC, and Git itself.)
Another way is to host your own fork on your own server, and send an email saying "hey please pull from this URL and merge if you like the changes"
> Turns out there’s a very obvious and widely used option. git format-patch + git send-email
That's fine for pull requests, perhaps, depending on your preferred UX, but what about a bug tracker? CI? Release artifacts?
We already had federation for decentralized forges: Email
But that wasn't hip enough so everyone moved to GitHub.
If you really think the UX of email is the same as the UX of a web-based forge, I'm not sure what to tell you.
You may prefer email over the latter, but I think these days you're in the minority. Your level of derision at this fact doesn't really change anything.
> But if projects move to something more akin to self-hosted forges, to their own self-hosted Mercurial or cgit servers, we run the risk of losing things that we don’t want to lose. The code might be distributed in theory, but the social context often is not. Issues, reviews, design discussions, release notes, security advisories, and old tarballs are fragile.
Thankfully, this doesn’t have to be the case – Forgejo imports pretty much everything mentioned. (1) Whether you decide to move to Codeberg or host your own instance, you won’t have to lose the context.
But I definitely agree we should also have a metadata archive of some sort, for both GitHub, Codeberg, and self-hosted projects.
(1): Not sure about code reviews, and you don’t get the security advisories, though I’m sure it can be replicated with a CI workflow somehow?
And not a single mention of GitLab. I remember it was a pretty serious contender, sometimes leader, strange that author doesn't mention it.
> The leaders there once cared a lot about keeping GitHub available even in countries that were sanctioned by the US.
The link leads to a blog post saying how they mercifully unblocked the users in Iran, but that was some time after they first suddenly blocked those users without any recourse and any way to even download their data and private repositories hosted there, without any advance warning…
If it wasn't for GitHub self-hosting and open-source development would be much more difficult. Like the article says open-source development was obviously still happening but it was a smaller space. I appreciate how many apps I've interacted with because of GitHub like OpenGOAL, IINA, and Ghostty along with the services running on my servers at home like Immich, Glance, Filebrowser, and audiobookshelf. I even used GitHub myself for some private repos, but I've since migrated them to a self-hosted Forgejo container.
This may be an unpopular opinion, but gatekeeping is sometimes good - in which case we call it by the more positively connotated term "curation".
A bigger space isn't necessarily a better one if it's flooded by low-quality content. Does a one-person project on GitHub have any advantage over one that uses a local git repo? I don't think so. It has a disadvantage because you're dependent on GitHub, and even worse, that first-year student learning development now thinks GitHub is an integral part of development.
If projects had to start with a local git repository and a local process, before being able to migrate to GitHub upon gaining minimal notability, developers would be more accustomed to the idea that a project isn't its hosting and that platforms like GitHub are optional. I think this would encourage more local-first attitudes instead of centralization, and that would be good. It wouldn't be seen as weird to send someone a zip file of the thing you're working on.
Plus (only tangentially related) imagine where the JavaScript ecosystem would be if packages like is-array and left-pad couldn't get accepted to npm.
I came from Perforce.
I always found Git to be liberating. I did use a self-hosted BitBucket server, for a while, but now use GitHub.
GitHub gave us pull requests, and a cloud-hosted repo that is managed by others.
I'm quite capable of managing my own repos, but I'm not as good at it as the GH people. If you think their uptime is bad, hold my ginger ale.
But I also don't work on very confidential stuff (anymore). I don't really care if my code gets indexed.
SF was exe + source code as zip file. And an admin that made all the decisions and had to for a project,
I do not agree with details, because it was for me before and after git.
So the hidden denominator here is and still is git, which sparked a tooling frenzy with reversing flow by being online server first (it wasn’t named cloud back then).
So even today, all splinters are doing something around git. That hasn’t changed.
What I really miss is the some sort of standardization that GitHub provided for a brief period of time. Projects would get no love aka stars when you couldn’t easily be used even for the experts. Some convenience as well as tooling evolved, devops became a thing.
I think of the future of a concept called cocooning. The JavaScript expert of today would be puzzled to write code on a notepad in a html file, because it has become so meta, being TypeScript essentially.
There is so much tooling going on that especially Python before AI already felt like I would miss something out if I would code more than 100 lines and that there must be libraries that abstract this all away and instead of coding I should google better.
AI is one thing, but the cluttered tech stacks aren’t really sparking any interest or joy in me, I think it is the not invented here syndrome or because I can story.
I miss the die hard coders, who stick to a tech stack which simply worked, not optimizing for weird use cases which are contrived at worst and rarely needed at best.
This became evident with the decline of data sheets, because Grunt, Gulp etc. as build tools were great but slow. We JavaScript devs couldn’t any longer joke about the compile times of the Backend dudes. And besides that, build times costs you focus, money, cpu time. But this was the main currency.
With AI I stopped trying out lots of tools because they feel like a weekend project by some dude who blasted his Claude budget.
Over are the fork and commit wars. Until AI battles itself this hard for quality source code I will stick to GitHub.
I'm going to throw out a really naive solution
Tangled supports hosting your own knots. Why wouldn't the current GitHub CEO choose to support self-hosted "databases". GH infra can protect you from all the traffic (ssh and http spam), while you keep the social aspect.
I don't need ~100 extra features, I need a reliable platform. If that means I need to self-host the storage, runners, etc. fine.
GitHub has offered an on prem enterprise option for a very long time
I really worry about a bunch of people going over to codeberg. Site's already super slow, but apparently it's quite nice when self-hosted
Anyone who is able to just plop a forgejo instance on their own machines... please do that if possible!
Can a small project do this and (cheaply) be robust to getting slashdotted?
Which is often the dream for a small project.
Probably yes, Codeberg are very transparent about their infra details and they don't seem wild:
https://codeberg.org/Codeberg-Infrastructure/meta
I was hoping that by now we would have an up and coming DVCS replacement that functioned as a "github in a box" (pretty sure fossil has been described as that, but it's too much on the cathedral side). Being able to mirror an entire project though version control would significantly help with mirroring if we go back to a decentralized world. Maybe going back to decentralized project hosting is just another pendulum swing similar to how compute moved to the cloud...
If it wasn’t for SourceForge I’m not sure my life would’ve ended up where it is! They use to promote projects they liked and ended up putting Waterfox on their front page a few times. Really sad when they started blasting people with ads and swapping out installers with adware for popular projects. By that time I moved to Microsoft’s CodePlex, if anyone else remembers that? Felt like I was the only one using it at the time! I remember the connection speeds to it were atrocious, but appreciated they’d share ad revenue from the downloads of a projects page which was nice. I remember it was actually super expensive to offer downloads [for binaries] back then, using these code hosting websites was the only way to do it for “free”
I also remember SourceForge fondly, before the ad infested thing.
Specially, I remember not "getting" Github at some point. Bitbucket had mercurial support, sourceforge had SVN, and all the Cool projects lived in SF (I'm talking mid/late 2000s).
The first time I navigated into a github project and just saw the code three I was puzzled. (SF was centered on the project/product while GH focused on the code.
Hey, I also remember Launchpad and Bazar, and adding an individual new source to my apt. Launchpad had something like CI before everyone from what I remember.
former CodePlex Product Manager here! I wondered if anyone would mention CodePlex in this discussion :)
What is GitHub’s decline? I’ve used it extensively since 2011 ish (to lazy to look up when) it’s only gotten better. What’s the issue?
Uptime and crappy GitHub actions are the main complaints.
I used ClearCase and Perforce too. Great for controlled environments, but not really built for open collaboration or community growth
Similar (904 comments): https://news.ycombinator.com/item?id=47939579
This “slowly dying” effect is what happens to every company that gets acquired by big monster slug companies like Microsoft.
What Microsoft acquisitions still have any of their original spark left in them? Or Oracle? Or IBM? Or Google? Etc…
Hell, some Microsoft originals from inside the company like Xbox have even lost their edge.
Money is great and I’m sure I’d take the big check, too, but I’m surprised more tech founders don’t think of their legacy in this way when they decide to sell out.
It’s considered a grand accomplishment to essentially lead the wonderful thing you created to its slow demise and hand it over to apathetic quarterly earnings zombies.
Up until about a year ago, GitHub was the example that would be given if you asked the question.
And now it’s gone.
We used bitbucket for years in our academic research group because GH didn't allow private repos. But otherwise it was better to use, so when they allowed that, we made the switch.
Great through-history write-up! Thank you.
> That is one of the great ironies of modern Open Source. The distributed version control system won, and then the world standardized on one enormous centralized service for hosting it.
Cycles everywhere indeed. Perhaps we should ->
> GitHub wrote a remarkable chapter of Open Source, and if that chapter is ending, the next one should learn from it and also from what came before.
Indeed! Try to learn from the inevitable iterations to make the next instance at least that slightly better.
... Where the stuff meets the metastuff it seems all works under very similar forces. My thinking is step-by-step - it works on the individual level, and it scales up.
Day to day is step by step and a step today funds the step tomorrow.
My first was this monster:
https://en.wikipedia.org/wiki/Microsoft_Visual_SourceSafe
"Hey can you check that file back in?"
Ha ha... yes... that brings back memories!
Or someone checks in the project file without checking in the new classes they added :facepalm:
I remember that. I've been writing code since the 70's, and have lost count of the number of source code management systems I have been forced to learn. Early on they were over engineered, and a pain in the ass to learn. Then they'd go "out of fashion" and the next pain-in-the-ass over engineered nonsense was forced and learned. I resisted git FOR FUCKING EVER because i was so tired of relearning how to do the same fucking thing slightly different in some other convoluted over engineered system. But it looked like Git was going to be the forever winner, so I finally gave in and learned git through and through. Fuck now its dying!?
A uni prof of mine insisted on hosting the work group's SourceSafe repo on his laptop. You could not commit changes when he was out of the building.
I think github is at a point that its too hard to ignore just like google is even though we might not like what they are doing now but we were the one made them this big.
I was posting on Planet Source Code before SourceForge existed.
Radicle is a good answer, coupled with a reborn Usenet, maybe Nostr. We have like never before the ability to communicate and cooperate yet most fails to understand and implement that.
Nearly any of us could run an XMPP/Matrix server and federate with friends or Nostr/{0xchat,whitenoise}, all with audio, video, text, file exchange etc, yet less than 1% do that.
Simply people, techies as well, have forgot the meaning of personal ownership and therefore are owned by someone else.
GitHub sooner or later will be only source of training data for the AI engine
Does github degradation gives boost to gitlab?
IMHO the problem is always the same. Social networks (and I consider Github as one in this discussion) tend toward centralization and hence monopolization. But monopolization tends towards enshittification. It happens again and again. There's a new cool player, it grows, it's not the cool player anymore. Rinse and repeat.
Unfortunately I don't have a clever solution (to the social aspect of the problem).
If everyone moves off GH, it'll just go back to normal again?
we let one company accidentally become the library of Alexandria for open source, and now we're shocked it's on fire - maybe don't do that again
Maybe something like https://fossil-scm.org/home/doc/trunk/www/index.wiki is worth another look. Although Forgejo is probably an easier switch from GitHub. If their federation ideas play out well, that could be a good outcome from all this
> That is why I find what is happening to GitHub today so sad and so disappointing. I do not look at it as just the folks at Microsoft making product decisions I dislike. GitHub was part of the social infrastructure of Open Source for a very long time.
Well ... sad or not sad ...
I remember I was very displeased when Microslop, 'xcuse me, Microsoft assimilated GitHub. But for some time it worked quite ok-ish, to some extent. Only more recently are things suddenly breaking down. I am not sure why they break down right now, but I suspect it has a lot to do with the new AI-focus Microslop pushes onto everything. The AI permeates everything like a virus and contages things (I just tried to create a new word from contagious ...). It seems as if this is the real new corporate identity. As Microslop proceeds to dive deeper into AI (they have no alternative anymore, they already sold their soul to AI), they forget that GitHub used to be about people, first and foremost. Steve Ballmer also had this with his fake antics aka "Developers developer developers" many years ago in 1999 (https://www.youtube.com/watch?v=8fcSviC7cRM - at the least Ballmer was entertaining, the current slop-CEO is boring to no ends).
> So when I think about GitHub’s decline, I also think about what came before it, and what might come after it.
Well - the decline happens largely because Microslop totally struggles. They could have decoupled departments and what not, but they decided the corporate strategy is AI-only now. And this creates a ton of downstream problems. So in many ways the current CEO is to be held responsible; he is in charge since 2014 after all. Fatigue kicks in. I am not saying a single person alone is responsible for failure, but it is clear that whatever the reasons for problems, this comes from Microslop first and foremost. The GitHub team contributes to this decline as well (services no longer working suddenly) but it really is induced from top, aka the overall corporate strategy here. And I also don't see Microslop being able to change course - they overcommitted already, so now the decline is indeed unstoppable.
> GitHub changed how Open Source feels, and later npm and other systems changed how dependencies feel. Put them together and you get a world in which publishing code is almost frictionless
Frictionless is a strange word. I retired from rubygems.org when shopify flooded the zone with ... corporate agenda. The final straw was the 100k download limit ("past that point we disallow you from removing old code you published to rubygems.org", which meant that people would download old code and assume that I would maintain that, which clearly was a lie, so thanks for that RubyCentral ... a year after that they went amok and mass-fired numerous devs; the whole story is a bit more complicated than that, but I can now wisely nod my head, since I retired about a year from that before that mass-fire devs event unfolding). I think if you have a source code hosting service in place, no matter what it is, you need to think about making publishing code super-easy at all times, including the UI. GitHub did this, sort of; I notice this when I compare it to gitlab. Perhaps gitlab has more features, but using it is soooooo much more annoying compared to GitHub. Codeberg lacks features on the other hand. Offering a good service here is actually difficult. It almost seems as if there are no clever UI designers anymore.
> My first Open Source projects lived on infrastructure I ran myself. There was a Trac installation, Subversion repositories
Well. I hated using Trac. Reporting issues is of course possible, but it feels so much more cumbersome than github issues. What could help would be to kind of make semi-universal IDs, e. g. I register once, but then I could use the same account on many different issue trackers. Right now I need to register for each instance and that is just tedious. I keep a password file (don't tell anyone) and I noticed that, say, after about 100 different websites and names and password, it just becomes unmanageable. Yes, I could use software to help me with that, but I decided that I simply no longer want to have a gazillion accounts. I almost never register for phpBB webforums (though discourse appears to be killing phpBB anyway).
> You could find forks, and old issues and discussions all stayed online.
That is true in general, but I would like to remind the blog author here that when the xz backdoors utils were found, Microslop took down the whole repository INCLUDING discussions. I remember that because I also discussed this on the xz utils github issue; and next day when I looked for more discussions, the whole thing was gone. Microslop censored here. Lateron the repository was back again, some days later, but if I recall correctly the whole discussion section was also gone. Microslop did not like the discussion; perhaps it was the author too, but the initial removal was from Microslop. So why was that bad? The whole discussion contained valuable information for people who were not yet familiar with this. Thus, Microslop deprived people of that information. Since then I am very wary about "trusting" Microslop or any private actor here when it comes to censorship. So I would not trust the "discussions stay online" claim here.
> Before GitHub, Open Source was a much smaller world.
Not that much smaller right-before GitHub and right-after it became available.
> but in the number of projects most of us could realistically depend on.
Most FOSS I realistically depend on I don't obtain from GitHub actually.
> There were well-known projects, maintained over long periods of time by a comparatively small number of people.
There were even more not-well-known projects, maintained for less time, by a larger number of people. They just weren't that many of them in one place.
> You knew the names.
You absolutely did not know the names. Post author is just thinking of the names they knew as though those were everybody.
> reputation mattered in a very direct way.
And now it doesn't?
> We took pride (and got frustrated) when the Debian folks came and told us our licensing stuff was murky or the copyright headers were not up to snuff, because they packaged things up.
RedHat was just as popular a distribution; and most users used Windows (like they do today); and the BSD distributions were a thing (although we didn't have Apple's BSD, i.e. MacOS)
Bottom line: Inaccurate description of history.
> You absolutely did not know the names. Post author is just thinking of the names they knew as though those were everybody.
I absolutely knew the names of the people I interacted with and whose projects I used. I even went to conferences with some of them. When I worked on my first web portal for Ubuntu we had a total of about ~4 dependencies and all was vendored. I knew the person who packaged my Python libraries for Debian.
You might call it an inaccurate description of history but it is very much my experience.
back in the day, I work in a web hosting company.
I know every name on mysql devel team.
The only reason i subscribe that mail list is: i reported some bugs and need to follows the release.
Signal to noise ratio on those mailing list was high. I can't say the same for github or discord
> I know every name on mysql devel team.
That's one project. You did not know every name, or most names, in FOSS generally. Today as well - a project which uses GitHub still needs a mailing list, web forum, chat channel (Matrix/IRC/discord/Telegram/whatever) to discuss and coordinate, and that hasn't changed.
As for whether signal to noise ratio on mailing lists was high - that really depends on the list. I don't see that much noise on GitHub repositories, to be honest - it's not easy to post noise that many people will see, so there's not much motivation for it.
Things Fall Apart
Turning and turning in the widening gyre
The falcon cannot hear the falconer;
Things fall apart; the centre cannot hold;
Mere anarchy is loosed upon the world,
The blood-dimmed tide is loosed, and everywhere
The ceremony of innocence is drowned
SVN (subversion) was working excellent for my team, about 20 yrs back. I never saw sufficient justification for the complexity brought in by Git.
But as I say, New tech invades the world and makes the perfectly working old tech as incompatible, just by changing the world around it. So git became a necessity imposed.
There was a big hype around it (you probably remember it), and around distributed version control, if you weren't using a DVCS you were suddenly seen as an inferior computer programmer and hence your employment opportunities were diminishing. That perspective when it comes to almost all-things programming-related has only accelerated ("if you're not quick to adapt to agentic AI you will lose your cushy job!"), with the recent AI craze the latest example of that.
I'm working pretty hard on building what comes after Github, but I'm going full-tilt boogie and trying to also work out what comes after Git.
I'd love to have a longer conversation with you about how we can seed a better system, because on the off chance I'm successful I have a once-in-a-generation opportunity to fix past mistakes.
Your username is con artist lol
Yes, Hi! I'm Conrad.
and also a con artist?
I'd say a code artist, more commonly called a hacker. https://paulgraham.com/hp.html
To be clear for the past five years I've done nothing but write OSS code (https://github.com/conartist6) while sharing pretty much all my engineering thoughts on a public Discord server (https://discord.gg/NfMNyYN6cX), so I'm not very worried at all that a person determined to find out would be unable to tell if I'm legit. You just can't fake 20,000 hours worth of public toil.
I'm not sure if your aware, but in American English, "con artist" is another term for a scammer. Someone who does "cons", short for "confidence tricks" (or "confidence schemes") where you gain someone's confidence in order to take advantage of them in some way, usually financial fraud.
Yes I'm aware, I grew up in a college town in rural Pennsylvania. I chose the name when I signed up for Neopets uhhhh 20 years ago now.
The best time to have chosen a new name was 20 years ago. The second best time to choose one is now.
¯\_(ツ)_/¯ I'm me. 's not likely to change is it? I could color inside the lines and hope it buys me a nice life, but if I was that kind of person I would never have tackled this insane of a project
Maybe he likes a challenge?
I guess I happily invite people to disrespect me for superficial reasons. Baseless disrespect keeps me motivated. Sorting out people who are only kicking tires also helps protect my time.
The ones who show real curiosity, those are the people I'll give my full attention to any day of the week.
Yours is an anagram of “emits wrong beers”.
Just as relevant a point…