[koito17]

Yup. I think consumers of FOSS rarely understand the amount of effort that goes into maintaining code, whether that is keeping the test infrastructure up to date, fixing bugs, or adding new features.

In many cases, a large codebase like GNOME will undoubtedly have huge swaths of unmaintained code that doesn't have good test coverage and corresponds to rarely used features of the software. It also becomes a frustrating game of whack-a-mole when attempting to fix bugs in software with inadequate test coverage.

Another infrequently acknowledged point: writing tests isn't simple, it requires you to have thorough understanding of all the moving parts involved. If the current maintainers do not understand the architecture in some obscure corner of the software, then there is a significant upfront cost to expanding existing tests around that code -- time that can be spent improving frequently used parts of the software.

When nobody steps up for maintenance despite welcoming patches and calling for new maintainers, there is simply no reasonable option besides "remove this unmaintained source of bugs that none of the maintainers know how to properly test"

[JoshTriplett]

Exactly. Given the nature of Open Source, anyone is free to fork something and say "I'm going to keep maintaining the old thing forever". But that's often not feasible solely with the handful of people and energy of those people interested in a given older technology, especially in a world in which people expect pieces of the ecosystem to cooperate and interoperate with each other.

So, instead, the standard tactics are to 1) push people and projects to maintain the old thing for them as long as possible, 2) treat any new technology that doesn't give you free support as a threat, and respond to it with fear, disparaging and attacking the people and projects who are no longer willing to maintain the old thing forever, trying to rally others to pressure them, and 3) disparage and attack technologies that require integration/cooperation between projects, because it raises the bar for the amount of maintenance effort expected.

New projects should decide up front, and document very clearly, whether they're willing to offer substantial amounts of maintenance effort on behalf of older or more niche technologies.

[jeroenhd]

> New projects should decide up front, and document very clearly, whether they're willing to offer substantial amounts of maintenance effort on behalf of older or more niche technologies.

Not just new projects. Existing projects can do with a clearer roadmap in my opinion. "Gnome 48 will drop X11" is easier to communicate than a merge request titled "session: Remove x11 session targets".

[bandrami]

Except for the guy who tried to do that with Python2 and the Python Foundation threatened legal action

[jeroenhd]

When did they do that? All I can find is the Python foundation protecting their trademark. Someone launched "Python 2.8" without any affiliation to the Python Foundation, that's a silly move. Surely everyone in open source learned from the Iceweasel debacle.

Something called Tauthon is still being patched every few months for people who can't let go of Python 2.7, though I don't see many contributors to that fork.

[bandrami]

> without any affiliation to the Python Foundation

Sorry, no dice. The Python team said for years as the 2 to 3 rollout grew increasingly catastrophic "If you wan't to keep Python 2 all you have to do is maintain it" and then threatened to sue the guy who called their bluff. It was a real low point in free software.

[jeroenhd]

This guy wasn't maintaining Python, he as creating a new version incompatible with either Python 2.7 or Python 3.

Red Hat and other large companies have maintained Python for years after 2.7 died (EOL date was January 1st, 2020). IBM/Red Hat offer Python 2.7 including security fixes and bug fixes until 2024 (https://access.redhat.com/solutions/4455511).

Had he just provided patches to Python 2.7, nobody would've batted an eye. Instead, they created an alternative language that was completely different (https://web.archive.org/web/20161210161837/https://www.nafta...).

Founders and core devs indicated that the name was the only problem (https://github.com/naftaliharris/tauthon/issues/47#issuecomm...) and that even things like the header file names could continue to be named Python because of API compatibility.

You can fork any open source project you like, but you still need to stick follow trademark law. You can't just release Linux 2.7 because you disagree with breaking changes in 3.0 either, but you're free to take the Linux code and release Twonux if you really care.

[DangitBobby]

After reading your first link I'm having a very hard time understanding how it's a "new version incompatible with either Python 2.7 or Python 3" or how you can think "they created an alternative language that was completely different" is true in any sense.

> Python 2.8 is a backwards-compatible Python interpreter that runs Python 2 code and C-extensions exactly as-is, while also allowing Python 2 programmers to use the most exciting new language features from Python 3.

Really sounds like Python 2.8 to me!

[codetrotter]

> Someone launched "Python 2.8" without any affiliation to the Python Foundation, that's a silly move. […]

> Something called Tauthon is still being patched every few months for people who can't let go of Python 2.7

I was curious and did a search for Python 2.8 and found:

- https://news.ycombinator.com/item?id=13144713

- https://news.ycombinator.com/item?id=13159144

Clicking on the GitHub repo it seems that in fact the project making unauthorised use of the name “Python 2.8” was the one that ended up changing its name to Tauthon. Neat!

[bandrami]

Also "without any affiliation" is a stretch. He picked up a codebase they abandoned and they got pissy because he kept its name. It was really not a good look.

[adastra22]

This is more than a little ironic since Python stole its name from a British comedy show.

[jeroenhd]

Monty Python didn't register Python as a name for computer software was far as I know. Nobody was going to confuse the two.

Releasing Python 2.8 would definitely confuse people.

[adastra22]

What would be the confusion? It’s a continuation of a language interpreter compatible with the dialect known as Python2.

Renaming it is more confusing!

[bandrami]

I did in fact find it confusing that a very different language was released under the name "Python 3". They probably should have picked a new name rather than capitalizing on the original language's popularity to push their new idea.