It's important to understand the danger of critical systems having single points of failure because humans are fallible.

Responding to President Trump's saber rattling, North Korea's leader warned "The Button" is always on his desk. He was implying being able to launch nuclear missiles at the U.S. after deciding to press a button. Of course I hope that isn't the case as that would be a horrible example of a single point of failure, an opportunity to cause a catastrophic unintended action. Trump was quick to reply he too had a button, but it was much bigger and actually worked. Again, this makes sensationalist headlines, but it's thankfully not the truth.

I'm no expert but I can probably describe the procedure to launch U.S. nuclear weapons with 70% accuracy. First, the president has a card and secret code which changes daily. These work with a nuclear "football", which can't launch anything alone. Instead, the president uses the football with his card and code to establish a link with a guarded command center. Top officials verify the communication is correct, that it is the president and his credentials authorize the action. Next two different keys, which only highly trusted officials have, must be inserted and turned in different locations at the same time, arming the system. The president is asked to confirm the launch. Upon confirmation launch codes are entered to launch the missiles. Again, I've probably made errors, but this shouldn't be wildly off. The point is the system is clearly designed to not have any single point of failure. No single person can launch missiles, nor can the system be hacked to launch missiles since part of the process involves physical objects.

A horrible bug, CVE-2018-17144, was recently revealed in the Bitcoin community. The developer finding the bug, /u/awemany, who works on Bitcoin Unlimited for Bitcoin Cash, proposes in a disclosure article the course of action by Bitcoin Core devs including bug revelation was sub-par and likely based on a distrust of the "other side." Upon careful consideration I came to disagree with a different conclusion: Core devs took the least bad of several horrible possible actions. The scope of potential damage was immense. With some percent of the BTC network patched but a large portion still not patched Core published a pull request identifying the bug, leaving many scratching their head. Why? The BTC network and other bug-exposed networks certainly couldn't be considered safely patched, so why allow the vulnerability such glaring exposure?

They did so because they had little choice. It was disclosed to Core, with bug details, the information was simultaneously being sent to other potentially affected teams on other networks. Developers may have ad hoc communication with one another for a given project, but pretty much no communication channels exist between dev teams on different networks. Core devs facing a situation where the entire BTC network could be attacked and damn near destroyed couldn't be sure of the limits and risk of such sensitive information falling into the wrong hands. Anybody can join any open source project, including incompetent, loose lipped people, government plants, or any range of types in between. Core couldn't know the information would continue to be constrained several hours or days later, and the more time that passed the greater the risk of leakage. So they took the nuclear option: they made sure everybody knew about the bug, at least a milder version of it, one saying nodes could crash. In this way, the community could realize the urgency of taking action.

So I can't exactly fault Core for that course. Really the problem lies in the fact the network is growing too large for a single dev team to be able to protect. In times past lead devs like Gavin could basically contact a few heads of large mining pools and get a big portion of the network to take action or upgrade fairly quickly, rendering bugs harmless. Times have changed. There are more pools mining BTC and not all are on cordial terms with leading Core devs; not all operate in the same timezone or with the same language or with the same mental state of all things Bitcoin. Core dominates with over 95% node monopoly for BTC, but their "congregation" is increasingly diverse and less focused on a single Core message from the pulpit.

If we take two facts, that all humans are fallible and ALL software is vulnerable to bugs we end up with an obvious conclusion for Bitcoin: the system itself must be designed to be tolerant of bugs by avoiding single points of failure (e.g. one software package for an entire network). Bug discovery hero /u/awemany requested in his disclosure that node software be gone over with a fine-toothed comb, but that's only putting a band-aid on a fracture. The goal isn't some futile attempt at perfect software, because there is no such thing. If Bitcoin, whatever incarnation, is to truly support a world economy, now measured in the many trillions of dollars, it can't risk being taken down by a single pull request. Core developers may appreciate their current dominance for ideological purity, but being smart, politically neutral engineers, they'd have to agree building robustness into the system in the form of multiple node implementations, preferably written in different languages to ensure variance and bug containment, is something to strive for.