What Do You Do When a Piece of Your Stack Goes Bad?

Technical leaders need a repeatable way to treat SaaS and open-source components as part of their supply chain. Dorian describes a "Supply Chain Stress Test" that inventories each vendor, the product, contact reps, service tier, capability assessment (e.g., localization), recommendations, and links to documentation or competitors. The checklist repeats for every dependency, turning a vague notion of risk into a concrete inventory.

The piece then enumerates the concrete dangers: vendors can experience outages, be hacked, lose or delete data, go out of business, change contract terms, or be acquired. Beyond operational risk, the author argues that a vendor's cultural or political associations become a liability, affecting brand safety and influence over open-source projects. Recent examples include RubyGems controversy and Vercel's leadership photo, showing how personal conduct can ripple into technical decisions.

Finally, Dorian stresses that leaders should evaluate both the technical and governance aspects before committing. Open-source projects with strong community governance, like Rust, reduce the personal risk of any single maintainer. By applying the stress-test checklist early, teams can avoid costly migrations later and maintain control over security, compliance, and brand reputation.