Jesus Michał "Le Sigh" 🏔 (he)

There's a new piece explaining "The Slow Collapse of #MkDocs": "How personality clashes, an absent founder, and a controversial redesign fractured one of Python's most popular projects."

https://fpgmaas.com/blog/collapse-of-mkdocs/

Well, that says a lot. But what's really interesting is that MkDocs 2.x is being developed as part of the "encode" organization. That's great, right? The people who gave us such great libraries as #httpx?

Well, turns out no, not at all. It looks like encode has already crumbled and became immensely toxic.

httpx is not allowing bug reports anymore, apparently because of "absurdly skewed gender representation", whatever that means.

https://web.archive.org/web/20260228113715/https://github.com/encode/httpx/discussions/3784

That also explained why starlette moved out of the organization a while back:

https://web.archive.org/web/20260323042730/https://github.com/Kludex/starlette/issues/3180

There's a great rot in #OpenSource.

#FreeSoftware #Python

The Slow Collapse of MkDocs

How personality clashes, an absent founder, and a controversial redesign fractured one of Python's most popular projects.

4:40amWeb
Show threadstfn6h ago
@mgorny what the actual duck is happening to once great projects?
Show threadJesus Michał "Le Sigh" 🏔 (he)6h ago
@stfn, corporate brainrot?
Show threadi’m Mi5h ago
@mgorny The “absurdly skewed gender representation” sounds reasonable. That must have aggravated there with the exodus of the community from GitHub. Nobody can comment there without an account. This is similar to calling GitHub Issues & Discussions to be full of spam, which they are. Whether bug tracking discussion should happen in the open is an open point in general I think. What should however happen is accepting bug reports *somehow* and publishing details of known bugs *somehow*. And uh wasn’t MkDocs supposed to be a SSG  

I wish we could somehow transition into a distributed model, perhaps dropping Git, of just shuffling patches and patch series around on individuals’ websites and devising some ways of maintaining that at scale (perhaps darcs/pijul remedy some of the same pain points, but they still keep the repository as a whole and not as subdirectories iirc), and also perhaps considering bug report tickets to be preserved documentation kept as files in a distributed manner.
Show threadΈλλεν Εμίλια Ά.ζ.5h ago

@mi @mgorny Actually, one could just continue to use git and distribute patches via other ways supported by git.

In a sense, git actually is more flexible (e.g. in the supported transport mechanisms and patch communication workflows) than e.g. pijul in regards to that.

On the other hand, with smaller-scale git forges becoming more common, there isn't really a need to return to much older ways, "just" forge federation might be sufficient (and many work on that rn).

Show threadi’m Mi4h ago
@fogti @mgorny this is good thinking, but Git 1) makes it problematic to work on a single directory when your project gets merged/turned into a monorepo by a current authoritative owner and 2) every non-authoritative patches application is going to result in rewrites — we only can have a hell of revert commits and cherry-pick commits. Git also does allow some things but its philosophy makes us reluctant to do them all the time
Show threadΈλλεν Εμίλια Ά.ζ.4h ago

@mi (1) is something I overlooked. I accept it's a problem, in particular because I also know that managed dozens of small single-purpose repos isn't that nice to work with, either.

(2) is something one has to work with anyways, pull requests run into that problem regularly, as soon as they lay around long enough.

Something which I'd like to add is that basically no version-control system I've seen yet tries to make it easier to rebase "mechanical commits/patches".

Show threadΈλλεν Εμίλια Ά.ζ.4h ago
@mi Whereby "mechanical commits" are those that are basically just one or two command line invocations of `sed`, `awk` or such nested in `find` to iterate over the entire repository for systematic search-and-replace during refactoring. One might think of them as "migrations" for code instead of data (to summarize refactorings).
Show threadLuis Guzman5h ago

@mgorny but isn't this the special super power of FLOSS?

Fork and go on with your life?
They seem to have gone through some ego fight, where they could have just split and made their own forks.

Of course once you fork, you find out how really important your work is. Maybe we are more afraid to learn that more than other things.

Show threadJesus Michał "Le Sigh" 🏔 (he)5h ago

@ark74, no, it's not. That's the brainrot #GitHub is spreading.

The power of #FLOSS is the community. It's about people working together to create a better world.

The "fork and forget" ideology doesn't help people. Competition is killing volunteer-run projects. The "prize" isn't worth it.

How does the user benefit from having half a dozen incomplete forks, requires and reboots? In the best case, they waste their energy and find one that suits them best. And then hope it'll be up-to-date on #security fixes, and that it won't be abandoned in a few months.

Because when it is, you need to waste your energy finding and transitioning to another fork. Or maybe forking the fork to keep it alive. Before you know it, there is no community and no users; just a bunch of developers maintaining their duplicate software stacks full-time.

Downstream this is a nightmare. You suddenly need to figure out what to do when a dozen packages require different forks of the same thing, most of them mutually exclusive and some incompatible by design. And if you find a vulnerability and want to be a good guy, you now need to figure the dozen different projects to report it to.

The only people benefiting from this are #BigTech companies. They have the resources to follow these forks, copy their work and sell it as a working product. Maybe even #OpenSource, but with all the strings.

#FreeSoftware

Show threadViolet Madder4h ago

@mgorny @ark74

A community's survival depends on being VERY GOOD at knowing when to break ties and when to keep hashing it out.

A big problem in our culture today is people just ghosting each other at the smallest inconvenience (while simultaneously sticking with the worst possible jerks, for some damned reason).

Show threadTionisla4h ago

@violetmadder @mgorny @ark74

well underated post imo.

Show threadstfn4h ago
@mgorny @ark74 exactly this. I remember digging through different forks of a commenting system for my blog and having a hard time finding one that has been actually maintained.
Show threadJesus Michał "Le Sigh" 🏔 (he)5h ago

@ark74, no, it's not. That's the brainrot #GitHub is spreading.

The power of #FLOSS is the community. It's about people working together to create a better world.

The "fork and forget" ideology doesn't help people. Competition is killing volunteer-run projects. The "prize" isn't worth it.

How does the user benefit from having half a dozen incomplete forks, requires and reboots? In the best case, they waste their energy and find one that suits them best. And then hope it'll be up-to-date on security fixes, and that it won't be abandoned in a few months.