Before you go all Stallman on me, I actually do mean Linux the kernel, not the whole operating system. I've mentioned problems with Linux on a few occasions in the fediverse, but for sake of posterity (or whatever) I'll summarise them here.

Also I'm not really an active kernel developer at this point, merely a user, observer, and maintainer of a book. So things might look different from other perspectives.

The development process is cumbersome

It probably isn't if you've been doing it for 20 years and your neomutt configuration is tweaked to perfection to handle all of the threading and patches, but for anyone who started kernel hacking in the last few years sending patch series to mailing lists is archaic and totally out of step with current software development practices.

Those Linux Foundation megacorps with their giant piles of cash should just set up a Gitlab (independently, not on gitlab.com) and start running the mainline development from that. Then all of that git format-patch stuff can go away.

The governance model is inadequate

The bad governance model makes the sort of toxicity for which LKML is legendary into an inevitability. When you're a small project, like the ones I maintain, then there isn't any alternative to BDFL. Linux is not a small project. In terms of numbers of developers and rate of development it's one of the biggest software projects there is.

It's time to admit that Linux has a governance problem and to move to something other than BDFL. I don't know exactly what the model should be, but that should be up for debate. Try to avoid having the same maintainers in the same positions for long periods of time.

People say "but it has worked for 20+ years, so it must be ok". This is just an old man argument. In reality, I think BDFL has held back innovation and helped to maintain poor working practices. The project continues despite these factors, not because of them, due to its overall usefulness.

Lack of up to date documentation

The kernel source ships with its own documentation, but the documentation is not always very helpful and is often a long way out of date. There doesn't seem to be a lot of maintenance effort on the documentation. I maintain a book called The Linux Kernel Module Programmer's Guide and as far as I can tell this is the most up to date documentation on how to make kernel modules. Other books out there are a decade or more behind. With all of the megabucks of the Linux Foundation's sponsors you'd think that they could do a top notch job of maintaining high quality and relevant documentation for practical engineering. But apparently not. This poses potential problems for training the next generation of hackers, and it might be that Linux continues for only as long as the old guard remain.