Use third-party runtime dependencies


Last week I argued why you should minimize the number of runtime dependencies. Once you’ve done that, you’re left with the core necessary dependencies of your product. Let’s continue with the coffee machine example, since you like coffee, right? Right? Your next door neighbor has invested in a Nespresso machine. He really likes the Ristretto, but occasionally goes for a Lungo. He has to buy Nespresso coffee capsules, as that’s all his machine will accept. He heard the horror stories of people destroying their expensive machines with aftermarket capsules, so he won’t do that. He will drink Nespresso brand coffee, he has no choice. The price of the capsules is set, there are no cheaper alternatives for him. And if Nespresso ever stops with his favorite blend, he’ll be sad.

You on the other hand have this machine that needs actual coffee beans, and you can literally buy any brand of beans anywhere. Fancy a cup of cheap Dunkin Donuts’ coffee, or is Kopi Luwak more your thing? Whatever your motivations for buying certain coffee beans, your machine accepts all. You won’t be sad. You have a machine with third-party runtime dependencies, while your neighbor struggles with vendor lock-in.

In your products your should strive to use third-party runtime dependencies. A computer shouldn’t need a custom-built power supply, and you shouldn’t write your own database. When you use third-party dependencies, your product is suddenly more attractive to users that already have an preference for ATX power supplies or already know how to use a MySQL database. Additionally, users won’t feel as if they’re locking themselves into your products, and you don’t have to maintain those third-party dependencies.