1. 12

  2. 9

    He mischaracterized Beekums argument. What it really said was: given the choice between market leader and smaller competitor you should choose the latter but make sure you can easily switch away to the former if need be.

    1. 5

      Same technique I’ve always pushed. I liken it to an economic version of redundancy in hardware. We know it can go wrong in any number of ways. We make sure we can switch over without losing our data or computations. Should do choice of software similarly where possible. The prevalence of open API’s, formats, and code helps a lot with that these days.

      1. 3

        Thanks for the correction, I’ll go tweak the summary of Beekum’s argument.

        1. 2

          This easily leads to not using the features of the smaller competitor. The smaller competitor needs to give me a risk mitigation strategy, being able to switch away is just one, another one may be having the source available in some shape or form. Maybe there are even more that I cannot think of now.