> Misplaced trust, in this case.
You trust teams, not individuals. The smallest possible team (1) to give some responsibility to is three people for this reason. Someone can quit or take a leave of absence and you still have technical accountability, code reviews, meaningful discussions, etc.
The fact that management made a mistake here is understandable. Management needs room to make mistakes, too. The fact that the developer was blamed and fired but the management wasn't held to a similar standard of accountability is the problem.
The code is the product. The management owns the code just as much as that developer did. So does everyone up the chain and anyone in parallel organizations (the business experts, the people that make the budgets, the QA department, etc.).
It's likely, at least implicitly, that the org structure sees some people owning 'the product' and other people owning 'the revenue' and other people owning 'the budget' and the developers owning 'the code'. As if we can separate those things.
If you work for a car manufacturer, everyone needs to know about cars, care about cars, drive cars, learn about cars, and expect good cars to be produced for a nice profit. I think shops that sell software, whether shrinkwrapped or through services, need to have the same attitude about software. If you are in the business of software, you are in the business of code, even if you can't write any yourself.
1) Team loosely defined here. It could be three people from different parts of the company, as long as they all understand the aspects of the system well enough to have a meaningful discussions about it.