Technological Sustentation 90: Open Source

Open Source, which not only gives us free software, but some of the best software out there, should be a great thing, and it is, but from a Procurement point of view, it’s a damnation. Why?

  • How do you cost it?

    There’s no free lunch when you have to wash the dishes — for the entire Bawabet Dimashq Restaurant — and there’s no free software. It has to be customized, maintained, and supported. This takes people, and that costs money.

  • How do you defend against it?

    Chances are you will find that the software doesn’t quite do what you need, and then you will need to augment it. But under open source terms, you have to release those modifications. And that will be helping your competitor, won’t it?

  • How do you defend your investment against it?

    When a purveyor of proprietary software comes through the door and offers you its SaaS platform for half of what IT thinks it will cost to maintain your platform, how do you convince the CEO the customized open source software you want is the right way to go?

Now, in our world, it’s not usually the case that open source is the way to go, as modern providers of SaaS platforms, or at least those that aren’t too greedy, have made them such that they can offer better, faster, and cheaper alternatives than in-house open source. But that doesn’t mean proprietary will solve all of your platforms. Every organization is unique, and while SI expects there is a proprietary platform that can be configured to meet the majority of your needs, there might be a situation where something custom is needed, and the best way to build it is on open source technology. So how do you deal with the organizational pushback?

1. Know Your Unique Needs.

The first question is, why do you need it. There has to be a reason besides you want it, you like it, you think it will be cheaper than the alternative, or you think it will be the most flexible. If you’re gravitating towards open source, there should be one or more unique requirements that only open source can meet, these should be well understood, and you should be able to clearly convey why.

2. Know the Risks … and Have a Game Plan to Address Them.

Open Source brings unique advantages, but it also brings unique risk. Who is going to support the platform day to day? Maintain it and fix the bugs? Add new functionality and integration capability as the organizational platforms change? And how can you be sure someone didn’t sneak something proprietary in there, either on purpose or by accident, and you won’t be accused of IP theft or a license infringement and have to tack legal costs onto the bill (as there is no provider to indemnify you)? All of this is addressable, and controllable, but you need to be aware of all the risks, and have a game plan to mitigate them up front, or getting any open source project approved in an organization that still wants a one vendor platform and “one neck to choke” (that is outside the organization) will be an uphill battle.

3. Know the Costs … and the Value of the benefits.

Make sure to understand all of the costs of the solution, both hard and soft, as well as an expected value of the unique benefits that the open source solution brings, and add those to the cost equation of the best non-open source alternative. If the open source will allow for a drastic reduction in the manpower required to complete a workflow, allow for the organization to harvest a lot of market insight without paying for costly, marked up, data subscriptions, or provide some other cost saving, that is extremely relevant and the value ratio of the solution could even out when compared against the best proprietary solution. And having these value models worked out can go a long way to mitigating the “but it costs more for IT to maintain” dissension.