Finding the Perfect Solution: Build vs. Buy vs. Open Source

In software, there’s an eternal question of build vs. buy vs. open source. I’m sure there are other variations on these, but these options highlight what we considered while deciding what to use for our new permissions system. Which option is best is going to depend on your specific situation but there are some general things to keep in mind.

The way I’ve come to think about some of these considerations is rooted in the concepts of Domain Driven Design (DDD). In DDD, there is a concept of types of subdomains — core, supporting and generic. Core subdomains are what make your product special and should be your core competencies, i.e. your money makers. Supporting subdomains, meanwhile, are all of those pieces of functionality that don’t make your product special, but are needed in order for your core subdomains to function or be meaningful. Meanwhile, generic subdomains are all of the things that are needed, but aren’t in any way specific to your system.

So, with these subdomain types in mind, typically, you should build anything that’s a core subdomain. If you’re buying your special sauce, then either it’s not actually special, or anyone else out there can easily replicate it. A supporting subdomain will also typically be built in house since these are usually fairly tailored to your core subdomains. Generic subdomains are where things get interesting. In most cases, you actually shouldn’t be building your own generic subdomains and if you find that you are, you should probably think long and hard about why (or if it truly is a generic subdomain).

In our case, we classified our permissions framework as a generic subdomain. This isn’t to say that it isn’t important. It’s actually deeply important to our product — without fine grained access control to files/folders (and really, all other objects in our system), I’m not sure how we advertise ourselves as a secure enterprise file sharing and collaboration solution. However, there’s nothing particularly special about our permissions needs — sure, they have nuances specific to our problem, but there’s no reason that we couldn’t be solving a totally different problem and still have the exact same permissions needs and solution.

Since we considered it a generic subdomain, as we went to replace our old (built in-house) permissioning system, the first thing we did was look for an existing industry standard to use. As I’ve previously discussed, we explored several of the industry standards and settled on ABAC (which I further explain in this post). Once we decided to use ABAC however, we were still faced with the question of build vs. buy vs. open source. Since our permissions system is important to us, build was not out of the question. However, we all agreed that it should be our last option if the other two didn’t work out.

The Case for Buy

It can often seem like buying is going to be the most expensive option since you are literally paying to use someone else’s software. However, it’s important to remember that even though both build and open source don’t clearly have you paying someone else, they do still have a cost to your company. When you buy a product, you’re paying someone else for their core competency. Even though this is your generic subdomain, it’s that other company’s core subdomain. This means that their product should work well, be feature rich and ideally come with technical support should you run into problems. Even though it can feel like engineering time within your company is free, it’s actually very expensive and every hour that I spend trying to get something to work is an hour less that I’m spending on a feature in our own core subdomain. Additionally, it is unlikely that our company will (or should) put very many people on solving a generic subdomain. As such, there is little or no chance that we will be able to build a solution that is as feature rich or as battle tested as a company that, in some cases, is throwing hundreds or more people at that same problem. It’s also possible that buying may actually be cheaper since the other company has the advantage of economies of scale.

The Case for Open Source

Open source can seem like the win-win best solution. In some cases you can find a battle tested solution that has a very large number of contributing engineers. At the same time, you don’t have to pay for it. In some cases, open source projects are even supported or actively worked on by extremely reputable companies. There’s also potentially an army of engineers from a variety of companies finding and fixing bugs in the solution. Additionally, if you want to add on additional functionality, you have the ability to do so and you have the source code, so if you want to fork that and take it in a totally new direction, that’s also an option.

The Case for Build

Even though in our case we largely weren’t considering build, it’s worth at least mentioning a bit more about some of the reasons why it might be a good choice. Building allows you to have exactly the solution you need. You won’t have to worry about trying to fit a square peg in a round hole because you built both the peg and the hole. If you find an issue or need an enhancement, you can fix it immediately and don’t have to make a case to someone else to fix it or in the case of open source, submit the fix and hope it gets accepted in a timely manner. You have insight into and control over the quality of the solution and know exactly how well it was tested. You also won’t end up with super complex software that supports 200 use cases that you don’t need and if integration doesn’t go as expected, you can hopefully just walk over and talk to the developer who built it.

Evaluating the Options

Ultimately, in order to make any sort of decision, you need to look at your specific problem and the specific solutions available to either buy or available through open source. It’s also important to know your priorities and what trade offs you may or may not be willing to make. There are also a lot of additional questions you should spend some time thinking about (including but not limited to the following):

• What capabilities or features are needed vs nice-to-have? Which of these does each solution support?
• How well does each solution solve your problems? Is your use-case their target use-case or is it more just something that could be made to work?
• What sort of short term and ongoing support will you have for the solution both in-house but also from whoever is supporting the solution?
• In the case of buy, if the company were to go under or raise their prices too much, would you be able to easily switch out for a different solution?
• Is the solution use-able? Is the documentation or support good enough that you’ll be able to get it up and running?
• How well does the solution fit into your existing infrastructure? How easy will it be to implement?
• In the case of open source, is it actively maintained? How reputable is the company or person that originally released it? Are these things you care about?
• How good is the quality of the solution? It may be important to run a pen test on it.
• If it’s an open source solution, what sort of licensing does it have? Are you willing to comply with it?
• If you need additional features, will you be able to add them on top of the solution? If not, can you convince the company to add them (in the case of buy) or can you get a PR approved to contribute back (in the case of open source)?
• Do you have specific scale, performance or security requirements? If so, how do the various solutions perform against them? Is there something specific impacting one of these three that you don’t need (and can get rid of if you build your own)?
• How much do the buy solutions cost? What will (roughly) be the support cost of any open source or build solutions?

Our Decision

We started by trying to find out what was available. We were a little lucky in that ABAC is not super heavily used, so there weren’t too many options for us to evaluate. That said, we found what was available by talking to various contacts and resources from members of the team and by doing some internet searches. Once we had a list, we immediately eliminated the options that we felt either wouldn’t solve our problem or were too lightly supported to make us comfortable. In the end, we narrowed it down to two main products, one buy and one open source. We did a more in-depth evaluation and comparison of each of these projects — doing at least a small POC on each and in the case of the buy option, talking with the company and getting a demo.

I’m confident that either one could have been made to work so we compared the two on a number of the questions above. Overall, the buy option was more feature-rich. However, their target market was not engineering organizations (but rather IT teams), so many of their main differentiators were around GUIs and customer support packages that we largely didn’t care much about. There were missing features that we needed, but in most cases these features were missing from both solutions, so the amount of engineering support that we’d need on our side to get things running was roughly the same. Additionally, while we don’t intend to fork the open source option, it is nice to have that option in our back pocket in case we need it. The open source option isn’t very active currently, which makes it a bit of a risk, but it seemed to have most of what we needed and it was originally built by a reputable organization. In the end, when it came down to it, the buy option was slightly better, but mostly in ways that we didn’t care about, so in the interest of saving money, we went with the open source option.

I’m not sure that this exact decision is all that interesting. I’m sure the company we didn’t choose cares about why we went with something else, but our choice while right for us, could easily be the wrong choice for someone else evaluating the exact same options. What I do think is interesting is what we considered to make our decision. It’s rare that there’s a single correct answer, so finding the best answer is very situational and requires careful consideration and evaluation of the available options.