That’s because when technical debt kills a company, they attribute it to something irrelevant. Imagine Wikipedia, for example, and the great “Wikipedia has Cancer” post[1]. You might conclude, if Wikipedia fails, that it couldn’t secure enough funding, even if a significant amount of time and money was spent on dealing with operational issues that shouldn’t exist. In my experience with Mediawiki and scaling up a wiki, I feel that it suffers intolerably from technical debt, even being state of the art as far as wikis go.
Here’s a good example. Many modern websites have task queues to perform background tasks. So, too, does Mediawiki. You may assume it uses RabbitMQ or another queueing software, but nope, it stores the queue in MySQL (acceptable) and by default it runs cronjobs at the end of requests (less acceptable.) As your wiki grows, these jobs take longer and longer and happen more and more. Suddenly you are wondering why pages hang and you always run out of PHP FPM workers.
Then you look at the stack traces and it makes more sense... so you go to configure cronjobs. Except, there’s not really a great fix. You can tune the parameters so that the queue effectively never progresses, but then you have to run the jobs manually - which is fine, but there’s no task running daemon or anything. Actual cronjobs work but are catastrophic for responsiveness. So... one of the recommended solutions is a shell script that loops and runs the runJobs.php file repeatedly. This solution works, but from an operations standpoint it’s not a wonderful solution. You probably want at least some visibility into what’s going on, and bash scripting is hardly the best platform for that kind of thing.
Of course, this is just one microcosm of Mediawiki, you can run into one technical debt related issue per day and you’d not run out for years.
[1]: https://en.m.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost...