[zoogeny]

There is a quote: "When you stop growing you start dying" (William S. Burroughs). I am not sure I believe that the kind of governance that Apache is providing is helping to grow the projects under its supervision.

Your comparison to Terraform is also interesting. Apache Kafka, for example, has been absorbed by Amazon (MSK). Apache Spark is Amazon EMR. Just looking through Amazon's paid service offering I find several Apache projects rebranded and for sale. A cynical take could be that Apache is an org that helps companies like Amazon profit off of the work of open source developers.

[JohnFen]

But with software, sometimes there comes a time when it really should stop growing. When any further "enhancements" make the software worse.

It's something I've seen countless times in my life. A piece of software achieves something pretty close to perfection for its task, but the self-imposed "need" to continue development on it ruins it.

[rzzzt]

Does it read mail and/or contain a subset of Common Lisp?

[worthless-trash]

All software will eventually grow to send email. And lets be honest, if its not written in lisp, are you really trying ?

[systems_glitch]

Absolutely. Some things go into bugfix-only mode because their code has reached perfection for the 99% use case.

[broeng]

And then we fear it's a dead project, and move on in search for something else with active contributors.

[JohnFen]

Certainly not everyone. Personally, I pay little attention to that sort of thing at all. I don't care if it's a "dead" project or not -- as long as the software is meeting my needs, that's the only thing that matters. If/when it stops doing that, then I'll look for alternatives.

[systems_glitch]

Same here. I run Slackware on all of my engineering and development workstations. It does what I want, nothing gets hosed when running updates, and I don't feel like my main job is sysadmin.

But I keep getting told I need a "Slackware intervention" :P

[AlbertCory]

Hot take: Python 3.

Totally unnecessary.

[Master_Odin]

The move to python 3 helped shake loose a number of text processing bugs with library I work on, that was never caught in python 2 with its loose goosy text type handling.

[JohnFen]

But as an end user, it's made using applications based on (or even tangentially using, as I learned first-hand a couple of months ago) Python highly problematic due to extreme version incompatibility.

I now try my best to avoid anything that involves Python.

[janoc]

Sorry but that's nonsense. Python 3 has been released in 2008 - 15 years ago. And the last Python 2 version has been EOLed 1.1.2020, three years ago, after a decade of deprecation!

With your argument about compatibility no programming language would ever be able to evolve or deprecate/remove some features. Look at how many things changed e.g. between recent C++, Rust or C# major releases. Python had only one major revision in 15 years in comparison!

If you are using software that still requires Python 2 that's very much a problem of that application and not Python. Complain to the vendor responsible, not about Python. They had ample time to update their code.

End users had no business touching Python 2 for at least a decade now. And upward compatibility between the point releases of Python is (and has been) generally pretty good.

[JohnFen]

> Sorry but that's nonsense.

I'm not lying. This problem cost me a full weekend earlier this year. I may have misremembered the exact version numbers, though. Perhaps it wasn't between 2 and 3. Is there a Python 4?

The problem is that you can't have one Python interpreter that covers all versions of Python, and Python is very unforgiving about using the wrong interpreter version.

In any case, it was a serious problem that cost me a lot of time and really soured me on Python as an end user. I've not encountered a similar issue with any other language before, so this appears to be uniquely a Python thing.

But I don't know. I'm happy enough to just avoid Python-based anything whenever possible now.

[AlbertCory]

all arguably true, but it has no bearing on whether 3 was necessary in the first place.

> With your argument about compatibility no programming language would ever be able to evolve

"evolve" and "change" are not ends in themselves. If it was usable as it was, then there was no need to evolve or change in an incompatible way.

15 years ago: also irrelevant. World War One was unnecessary, and that was 109 years ago. Whatever issues existed are sorted out by now, but that doesn't mean it had to happen.

[rbowen]

I'm fascinated at your characterization of both Kafka and Spark as being absorbed by Amazon.

AWS offers hosted versions of each. They are not, as you say "rebranded and for sale", but rather are hosted services, running whatever upstream releases.

But to say that the project as been absorbed by AWS (in either case) is simply false. Spark is developed by a community of numerous companies, of which Databricks is usually most prominent. Kafka is likewise a community of several organizations, of which Confluent tends to be the most influential.

Yes, Apache is (and always has been) business-friendly. The license enables companies to profit on those projects. But, for the most part, companies that benefit from those project also contribute back to them, as a way to ensure sustainability. That's how it is supposed to work.

[toast0]

> A cynical take could be that Apache is an org that helps companies like Amazon profit off of the work of open source developers.

Apache httpd certainly helped tons of companies profit, so helping companies profit doesn't seem off-brand.

[znpy]

> "When you stop growing you start dying"

death is part of life though, and the only thing that grows without and end is cancer (quite literally).

I don't see why project can't just be considered "done": yeah you update dependencies and make it work with new/current formats, but essentially it's done. The use case is now clearly defined, implemented and tested.

[augustk]

Why do you think software needs to grow?

[kuchenbecker]

It needs at least a stable set of users, but maintaining a set of users is essentially managing the set of people onboarding and the set of people migrating off.

If you're shrinking then a competitor is providing better options, or your problem space has shifted.

[dale_glass]

Software as big as Open Office may not need to technically grow, but still needs a lot of work to stay current.

Various dependencies, like XML parsers, JPEG decoders, HTTP libraries, etc, change over time, drop deprecated APIs and need the main application to adapt. It'll also bump into the tech changing around it -- UTF8, year 2038, 64 bit CPUs, etc.

For a project this size it takes work just to stand still and keep it comfortably buildable on a modern Linux distro.