I have a modification to many eyes that makes it relevant, which is many eyes make bugs shallow when the code is simple enough. I think over-complexity is at the heart of the issue here, and the path forward in the future will be in reducing complexity of codebases and increasing readability.
The comparison I like to use, though not completely fair, is that the linux kernel is now at what... 14mil+ loc, while minix is at more like 14k loc. As we have seen with the intel ME debacle... minix is production ready. This is also why I still think a microkernel is going to be the future.
GNU+HURD and half-life 3 release on the same day I think though.
> I have a modification to many eyes that makes it relevant, which is many eyes make bugs shallow when the code is simple enough.
Many eyes would make many bugs shallow if there only were said eyes.
The problem is that very few people lift a pinky to help audit & secure the software they use. Nobody reads the code. And then when disaster strikes a particular well known & widely used project and people start paying attention, they notice the code is full of low-hanging fruit that anyone could've fixed (nobody did).
Even when people read code and find bugs (as I often do), they're too busy to actually report let alone fix them.
It's so comfortable to pretend that someone else must've audited the code for you because it's open sauce. So you don't have to :-)
They can be protected after the fact with "You thought there were enough eyes, but there actually weren't." and "You thought the code was simple, but it actually wasn't."
The comparison I like to use, though not completely fair, is that the linux kernel is now at what... 14mil+ loc, while minix is at more like 14k loc. As we have seen with the intel ME debacle... minix is production ready. This is also why I still think a microkernel is going to be the future.
GNU+HURD and half-life 3 release on the same day I think though.