Open source is a great way to solve problems. Mostly we focus on the open source project from a technical and architectural points of view. In this post, I’m going to talk about it from a business point of view.

Sometimes you’re look through 3-10 different open source projects on GitHub and/or Apache. If they all do about the same thing, how do you choose one?

Here are the ways I teach teams to evaluate technology from a business point of view:

• Does someone make money off it directly or indirectly?
• Is it used in production?
• How difficult would it be for the company to move off it?

Let me talk about each question in turn.

Does someone make money off it directly or indirectly?

Does the company make money off it? Better yet, do several companies make money off of it? This money could be made directly or indirectly.

A company that makes money directly could be a consulting company uses the software as part of its consulting. The company has a vested interest in maintaining and improving the product because that’s how they keep existing customers and attract new customers.

A company that makes money indirectly off software could be one that sells a service for the software. An example of this is Google’s use of Cloud Dataflow Model (now Apache Beam). Google doesn’t make money directly off Beam. They make money when people write code with Beam and then run it on Google Cloud. Google has a vested interest in maintaining and improving the product because that increases Google Cloud usage.

Is it used in production?

An open source project that is running in production has a higher probability of being maintained. There are inherent costs to moving to a brand new system. It’s far easier to patch or fix a program than to write a new one.

Companies are also risk averse on moving to new systems. They’ll usually prefer a system with more miles on the code than a brand new system.

There is an inherent stickiness to putting a system into production.

How difficult would it be for the company to move off it?

The third metric is how difficult a move would be. This an extension of the stickiness idea.

Let’s say a company wanted to move off their system. How much time and effort would it take to move to a new system?

I think an interesting example of this is Twitter’s move from Storm to Heron. To mitigate the issues of writing to a new API, Heron is compatible with Storm’s API. This removed the issues of programming rewrites and allowed them to change the operational framework.

Not every team can remain API compliant. This prevent a move to a new system and keeps the software maintained and used.