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.

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.

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.