The Open Source Dilemma

As a technologist and technology leader, I am often presented with the question so many small organizations face when trying to decide what solutions to use... Do we invest in expensive "off the shelf" solutions? Or do we take a chance on free "open source" options in hopes that the cost savings will justify the less than stellar UX and limited functional capabilities?

I think the answer to this question varies greatly from one organization to another. With so many options, and so many factors that play into this decision and it can be dizzying to try and work through... "Will my team have the competency to use and maintain the tool? Will it actually do the job we need it to? What are the risks of implementing open source vs. the alternatives?", The list goes on and on, and if you aren't careful, can even lead to a state of no action... which is the last place any IT leader wants to find themself.

I should preface this post with the fact that I'm a huge advocate for open source tools. I have seen how powerful these tools can be and I've personally experienced a ton of value from those that are designed and developed well, and more importantly, have fantastic ongoing support. That being said, they are not the unicorns that they are sometimes made out to be... oh no... in fact, some of them will suck the life out of your IT org if you let them... one engineer at a time.

I've been learning this lesson the hard way recently. At the humble education non profit I work for, budget is always a consideration in any decision we make, and the technology department is no exception to this. The infrastructure has many open source aspects to it, including support for all of our phone systems both for the office and in support of our customer service / support call center using Asterisk/FreePBX supporting a bunch of Polycom SIP phones behind a PFSense firewall. This in and of itself isn't a problem, but it should be noted that the original engineers who originally set this environment up no longer work for the company (of course they don't!) and, being the stereotypical "IT guys", were great about building technology solutions that could only be recreated with a lot of prayer (way more prayer than I'm about to sign up for) and perhaps a little voodoo (no really), and in most all cases were never documented (because we all know that documentation is for sissies!).

In their defense... it worked. For a long time it worked... until it didn't. One patch upgrade and suddenly the entire thing started shitting the bed... and ya know what? It hasn't stopped since. One thing after another with high impact to our customers who rely on these tools to do their jobs. When I start thinking about the dollar amount each outage is costing us, on top of all of the time / effort that is going into trying to figure out the problems, well, as you can imagine... It's not a happy day in my world.

I know our situation isn't unique. It sounds like a classic IT tale and is the kind of stuff we IT peeps deal with on a fairly regular basis, with both open source and pay tools alike (Some would call us complete masochists... and perhaps we are to a small extent. I prefer to think of us as complex problem solvers who just love a good challenge, except when it cuts into my Silicon Valley binge watching time... that's when it really starts to piss me off), but one of the key things about running a successful IT organization, is learning and getting better over time so that we can continue to increase the value we add. With that in mind, here are a few things I've learned are absolutely crucial to consider when trying to decide whether open source is the way to go for your company...

"Free" Does Not Equal "Cost Free"

This is a tricky one and certainly a factor that has to be weighed on a case by case basis. Not all open source tools are created equal, and though there is a general rule that most will be slim on the overall "sexiness" factor, what that actually implies is vastly different from tool to tool. The biggest things to remember is that each tool is going to have its quirks and as leaders, we have to be able to look at any tool and make sure we are very clear on whether it's going to meet the needs/ requirements we've laid out, and even more importantly, HOW it will do that. This gets significantly more complex when using multiple open source tools in combination with one another like the example I gave above. After running some numbers associated with the issues we've been experiencing recently with our phone environments, we're looking at upwards of between 7 and 10 hours of actual phone outage for our call center since the beginning of the year (think of the costs associated with an entire call center of around 40 people whose entire purpose is to be on the phones talking to customers and cannot), and somewhere in the tens of thousands of dollars in the amount of time spent by my engineers this year along to resolve this problem. Yup... those outages and time spent troubleshooting add up quickly. You start looking at those numbers and suddenly that hefty price tag on the out of box solution isn't looking so bad now is it?

"Open Source" Competency

Just as all tools are not created equal, neither are all IT teams. It's easy to say that your team can pick up a tool and "figure it out" over time, but the reality is, "open source" tends to have a specific "out of the box" mentality associated with it and while some engineers have this nailed down, the greater majority don't. In fact, finding really great system engineers who have this mindset are pretty tough to find, and even when you do find them, they aren't going to know every single tool out there. Assuming that your team can just pick a tool up and figure it out, without really knowing for sure what their competency is can be dangerous business and is something best tested out before jumping into the deep end on this one. (One other note is that engineers that have these skills also come with a few other complex traits that need to be understood before this becomes the right decision and we'll talk about that a bit further down this post.)

Weighing the Risks

As I'm learning first hand from our adventures with Asterisk and PF Sense, using these tools can and most certainly will introduce a level of risk into your team as well as the greater organization. Each org has its own requirements and business operations that our technology choices have to support. Another less visible risk is associated with engineers themselves. As I've learned with my teams and environment, engineers like to build things. They love a good challenge and those who are "blessed" with the natural "open source" mentality of "let's think outside the box and build our own solution" often use the technical gaps that are often present with these types of solutions as an opportunity for them to flex their own technical prowess and design their own solutions. This can be a huge time waster and means they could be spending a lot of time / effort going down rabbit holes that could have easily been fixed by implementing a tool that already has the solutions in place. This also becomes a massive liability when those engineers decide to leave the organization. Take it from me... it really sucks when you are the one left picking up the pieces of solutions put together with chicken wire and sticky tape. This is an opportunity for us as leaders to remind ourselves and our teams that "just because we can, doesn't mean we should".

It would be foolish to choose a tool because of the price tag without understanding fully the implications. In our case, these tools were around long before I entered the picture, and looking back on it, I'm not sure that I would have made the decision to go this route knowing that we are supporting a growing call center as part of our business. Perhaps at the time when the decision was made to implement this, the organization was at a size where the level of risk to our customer service organization was worth the risk. I guess the point I'm trying to make here is that this is something that will be unique to each and every organization, and so it's best to make sure that risk analysis is an essential part of both the decision making process, as well as ongoing evaluation as the company evolves and grows. What may be the right solution at one time, may not be down the road.

At the end of the day, there is no one right answer for an organization deciding between open source vs. pay solutions. The right answer relies heavily on an organization, and a technology leader who is willing to evaluate all of the costs, both obvious and hidden, along with the implied risks.

********************

I'm very interested in hearing about what your experiences have been. I know that mine is by no means the only perspective and would love to hear your stories relating to adopting open source tools and tips / ideas you use when determining the right choice in tools. Feel free to comment and share!

Like what you are reading? Check out my blog at www.meanderingsofmine.com. I cover everything from technology to life, the arts, and even wax philosophical on occasion.