When to Use Open Source (and When to Go Proprietary)

We hear a lot about the benefits of open source. As an evangelist myself, I am constantly reviewing and discussing the strengths of community-maintained software.



Slightly less often I see posts about proprietary software as a superior solution. What none of these articles address, is how a decision maker should approach the choice in their particular case. Open Source and proprietary development both produce plenty of great software, but making an optimal choice for your organization is more nuanced than picking a favorite  ideology.

When I do software selection with clients, I typically refuse to discuss licenses, open vs closed, or anything along those lines in the first meeting. The starting questions are all about the specific organizational need. What do you need the software to do? What attributes should it have? Where does it fit into the rest of your infrastructure, and plans? These questions guide the rest of the discovery and recommendation process. We’ll walk through some of them now.

Throughout this article I make a lot of broad generalizations. Some of them are wonderful – even traditional – topics for arguments over beers with your friends. Please try to hold yourself back from tripping on these details. The point of the post is the overall structure of how to think through these problems, focusing on the organizational needs in abstract terms before considering licensing or software trends.

What do you need the software to do?

There are Open Source alternatives for most any proprietary software product. But specific categories of functionality – seem to have strengths in one camp or the other.

Back-end applications that have “fire and forget” usage profiles, or that require interoperability with other products, generally lean towards Open Source options. OSS tends to be more reliable, less buggy, and have better support for open communication and file standards than their proprietary counterparts.

On the other hand, proprietary software is generally much better for user-facing tasks. Fantastic design and user interface depend upon a strong, single vision of how to work with a program. That lends itself well to a company with a single, dictatorial user interface czar who obsesses over every detail. It is much harder to manage in the typical open source group decision making environment.

This question gives the strongest indicator though, simply because every use case has a de facto standard software, and that is a powerful argument. Whatever your web hosting needs are, you should seriously consider the open source Apache project, simply because it runs more than 50% of active sites on the Internet. On the other hand, for document editing Microsoft Office gets this strong incumbent “bonus.” This doesn’t mean you should rule out alternatives, only that the market leader must always be considered, regardless of license.

What attributes should it have?

Beyond the basic functionality of the software, we have to consider the specific strong points that you need. We all need some level of security, but is yours a truly security-critical application? That indicates a strong preference for open source. On the other hand, if you need broad “it just works” support for a variety of hardware, proprietary solutions will tend to be better for you.

Open source software tends to be more stable and secure, and it always has a better up-front cost. Most of the time however, using an open source option means paying for maintenance and update labor costs yourself. Proprietary software in contrast, usually comes bundled with strong support options, but is never as secure as code which the world can inspect for problems.

How does it fit into your infrastructure and objectives?

This is an area where I often see large companies make mistakes. One of the most expensive problems with proprietary solutions is vendor lock-in: the fate of this organizational task becomes forever tied to the fate of the software vendor. That’s not a big deal for a temporary solution – a short term website, or a one-time expense. It is a terrible problem though, if the application is core to your entire business.

The example I always use is Salesforce, the enterprise-class CRM. is one of the world’s leading CRM systems, and one of the most profitable “cloud” based services, and it’s all built on Oracle’s database technology. This may not have been an issue when Salesforce was just getting started, but as it got bigger and bigger, the fact that Oracle’s own CRM software was a primary competitor looked increasingly like a risk. In 2013 Salesforce tried to make a jump to an open source alternative, PostgreSQL, specifically to break this dependence. They found it was just too expensive, and ultimately they backed into a nine year, uneasy contract with their biggest competitor. Salesforce would have had much more latitude if they’d chosen an Open Source product to begin with.

Similarly, if interfacing with many other applications in your stack is a core requirement, Open Source software tends to have much better support for open data and communication standards. A proprietary vendor can offer excellent integration between their own products (such as the microsoft office suite), but only if you use them consistently throughout your stack. If compatibility with many other applications is a requirement, you will often find that only the Open Source options support your needs.

Though these generalizations aren’t quite clear cut enough to make a simple matrix, we can look at a few illustrative examples.

Simple examples are dominated by a single need that overrides any other. A protest organization needs security above all else. It’s acceptable to have a poor user interface if the code is secure. This is why every privacy advocate recommends using open source encryption software, with an open source browser, on an open source operating system, and preferably on open source hardware. The same use case dictates open source for voting machines, banks, and private messaging.

Certain kinds of small businesses will prefer the “full stack” options they can get from proprietary vendors, specifically because of the predictable costs, full support, and easy internal integration. Almost anyone will want to go proprietary for secondary or incidental applications, like workplace chat. The infrastructure cost of running your own service is simply not worth it.

Websites are more complex, and need a case by case analysis. Most public-facing websites are better-off built on open source platforms, because the requirement that they “just work”, and interoperate with a thousand standards that haven’t been invented yet. When Facebook comes up with a new way to read websites, you want your site to be perfectly readable. Likewise when the next Facebook emerges, you want a community that supports your platform to help build integration.

Private CRMs on the other hand, tend towards proprietary code because of user-facing nature of the application. Non-technical users have to navigate through complex webs of data and reports, and they need a support fallback relatively frequently. That has “proprietary support” written all over it.

Note that internally, the proprietary CRM is probably best off using open source data storage and web services. The reliability, and especially security, of these internal components almost requires it.


Ultimately if you’re trying to make your software choices license-first, you will have some undesirable outcomes. Yet that’s the implication of so many articles around the web. My advice is to ignore the software entirely, at least at first. Focus on the real behaviors and attributes you need, and the place the solution must take in your organization. You’ll find your decision is already made. 


Still trying to decide?

If you're still weighing your software options and could use some advice, we're here to help. Get in touch today and we'll set up a time to talk.