Sounds to me like your CTOs should have been fired and the admins kept their jobs. If your company can be crippled by a single box being destroyed, it's probably not the individual devs or admins at fault. An errant 'rm' or damaging programming error is more of a risk than a disk failure or a building fire. If you don't plan for that, your company is making a scapegoat out of the person who made an honest mistake. At my last two companies I worked for, it would have taken multiple geographic regions being simultaneously affected by major catastrophes for 4 months of work to be destroyed, and I'm not even sure that would have done it with any degree of certainty.
Where were your redundant source control servers, local and offsite backups, iterative staging environments, etc? Hell, I have all of those at my current workplace and I still keep unofficial backups of everything critical on my workstation. These are all long-established best practices and relatively simple and cheap. The only way I'd fire someone over 'rm -rf /' was if it was done with malicious intent or was one of many examples of someone's ineptitude of negligence.
On an open-source project with low/no budget and less checks and balances, I think you have to be even more forgiving.
Where were your redundant source control servers, local and offsite backups, iterative staging environments, etc? Hell, I have all of those at my current workplace and I still keep unofficial backups of everything critical on my workstation. These are all long-established best practices and relatively simple and cheap. The only way I'd fire someone over 'rm -rf /' was if it was done with malicious intent or was one of many examples of someone's ineptitude of negligence.
On an open-source project with low/no budget and less checks and balances, I think you have to be even more forgiving.