Basically, around MINIX 3.2.0 (just before I stated contributing) the OS ditched its homegrown userland and adopted the NetBSD source tree + pkgsrc. While that boosted the software compatibility of MINIX3 in the short term, the maintenance burden of keeping up with upstream with such a large diff proved unsustainable in the long term, especially after the grant money dried up.
In hindsight, my opinion is that MINIX3 should've gone with NetBSD binary compatibility. The NetBSD syscall table would've been a far slower moving target to keep up with than the entire NetBSD source tree.
The OS also had a significant amount of tech debt, especially in the microkernel which was uniprocessor and 32-bit only, as well as outdated hardware support which meant nobody was daily-driving it anymore. It also was an aging design: while the system was divided up into user-mode servers with message-based communication, you couldn't containerize a process by spawning a parallel userland ecosystem for example because it wasn't capability-based or namespaceable.
It's too bad really, because the base system had really impressive capabilities. It could transparently survive crashes of stateless drivers, even when stress-testing it by injecting faults into the drivers at runtime. You could live-update the various system services at runtime without losing state or impacting clients. Some really good papers came out of MINIX3 [1].
I've ranted more in detail before, both on HN [2] as well on Google Groups [3]. I do not fault the maintainers for the current state of affairs because keeping up the MINIX3 userland against modern software standards was a major maintenance burden, so adopting NetBSD's one way or another was inevitable. At any rate, there are other micro-kernel based operating systems [4], some under active development, so MINIX's spirit lives on.
Still waiting for that Minix 3.3.0 release, after so many RCs.
I followed the project somewhat, and I understand the main issue has been lack of having someone at the helm, pursuing this 3.3.0 release.
The situation is such that the release blocking bugs were fixed, and yet the release hasn't happened, because nobody is willing to put the time and effort to make it happen.
Should the release happen, and somebody be willing to review and merge changes and organize a regular schedule of releases (even with a long period, such as yearly), the system would no doubt get some life back.
Basically, around MINIX 3.2.0 (just before I stated contributing) the OS ditched its homegrown userland and adopted the NetBSD source tree + pkgsrc. While that boosted the software compatibility of MINIX3 in the short term, the maintenance burden of keeping up with upstream with such a large diff proved unsustainable in the long term, especially after the grant money dried up.
In hindsight, my opinion is that MINIX3 should've gone with NetBSD binary compatibility. The NetBSD syscall table would've been a far slower moving target to keep up with than the entire NetBSD source tree.
The OS also had a significant amount of tech debt, especially in the microkernel which was uniprocessor and 32-bit only, as well as outdated hardware support which meant nobody was daily-driving it anymore. It also was an aging design: while the system was divided up into user-mode servers with message-based communication, you couldn't containerize a process by spawning a parallel userland ecosystem for example because it wasn't capability-based or namespaceable.
It's too bad really, because the base system had really impressive capabilities. It could transparently survive crashes of stateless drivers, even when stress-testing it by injecting faults into the drivers at runtime. You could live-update the various system services at runtime without losing state or impacting clients. Some really good papers came out of MINIX3 [1].
I've ranted more in detail before, both on HN [2] as well on Google Groups [3]. I do not fault the maintainers for the current state of affairs because keeping up the MINIX3 userland against modern software standards was a major maintenance burden, so adopting NetBSD's one way or another was inevitable. At any rate, there are other micro-kernel based operating systems [4], some under active development, so MINIX's spirit lives on.
[1] https://wiki.minix3.org/doku.php?id=publications
[2] https://news.ycombinator.com/item?id=34916261
[3] https://groups.google.com/g/minix3/c/qUdPZ0ansVw/m/7LuOv0YOA...
[4] http://www.microkernel.info/