As the team that runs the most external software, I was thinking about the tech stack at $work, wondering how do we decide which components to pay for and which we just run with the (free) open source versions.

getting started

So how does a new piece of software work its way into our jenga tower of a tech stack? Well step 1 is to recognize a need, or a point of improvement. This usually isn't too difficult.

Next step is to identify potential solutions. We're naturally biased towards things that we're familiar with (used before), and things that are free to try out in our own time (so not time limited trials). A lot of the time, this is good enough, but sometimes I do wonder if we value our time too little...

free stuff

So, (popular) open source stuff has quite a bit going for it: it's free to get started and gain experience with it, a wide userbase that will have run into most problems before (and hopefully fixed them or at least documented a workaround), visibility into code so you can patch it yourself if absolutely necessary, and occasionally there are companies supporting it so you can freeride (or pay them for support).

SaaS but we want to operate it ourselves....

Sometimes, with enough familiarity of the field, you know that nothing you can just run or buy will work. Now comes the delicate decision on whether to build something new. Sure it's fun, but now you're stuck with maintaining it for the foreseeable future, and, if you value continuity, knowledge transfer as your engineers come and go is something you have to take into account, after all, who writes docs?