Should You Choose an Open Source Platform to Manage Your Data?

Almost every business in the world with an online presence is met with the decision to either use open source or proprietary solutions during development. Open source software has a lot of appeal and is going to be almost all of the time.

But some big questions surround how you’re allowed to use the software – do people leave their code online for anyone to use, or is this altruism just too good to be true? Is an open source solution always the best way to manage your data?

Control and Independence: Where Open Source Software Thrives

The main reason a person would choose open source software (OSS) rather than proprietary code is the amount of control the former of these guarantees. Configuration changes, deployment, and even personalization of the software is completely up to you. You are free to include or remove as many features as you wish.

An even more important aspect of control comes in the fact that you’re free to modify the underlying code and have it run as you wish. You can add as many features as possible or cut down on the number of libraries used in the code to make it easier to deploy.

If it happens that the project takes a completely new turn thanks to new leadership at the helm, for example, you’re free to make your own copy of the code, referred to as a fork.

However, control is going to be a factor some firms want to have in mind as compared to others. In particular, if the company relies on OSS as part of its main business model, having a say in what the codebase is like is going to be crucial.

For instance, consider a case where you rely on Hadoop vs Spark to crunch your data and present the visualized information to the user. If the Apache foundation decides to sunset the projects, you now have to provide support for the software on your own.

The location of your data is another matter that may lead people to prefer using OSS over proprietary solutions.

Imagine a new kind of database had been invented, and the company in charge offers it dirt cheap. The only catch: all the servers are in Russia. As you might guess, not too many people will be rushing to use such a solution.

Additionally, configuration is often an aspect of software that can differentiate how your solution runs from a competitors’, even if you’re relying on the same software. Consider a software such as Apache Hadoop that comes with all security features turned off by default. You may say it does not have any security at all. When using it yourself, you’re free to make configuration changes that encrypt all the data on-the-fly.

Another great example would be with databases like MySQL, where developers often don’t bother to secure the port the app is running from (SSL is off by default). This leaves plenty of room for the attacker to snoop on your connection. Changing or securing the port on an OSS might be as simple as changing a single line in a YAML file.

It’s not all sunshine and rainbows: the limitations of OSS

OSS isn’t the magic bullet that a lot of its proponents purport it to be. Just like proprietary solutions, it has its own fair share of drawbacks.

Using the MySQL example from above, misconfiguration is a common and often costly drawback of relying on OSS. Not changing the default root password, allowing access to the database from any IP address and not securing the access port with SSL encryption are good examples.

Every software has ‘best practices’ that many developers often overlook without thinking about the consequences of their decisions. A lot of problems with OSS can be solved by following these practices, but a lot of developers are ignorant about their existence, or just don’t understand their importance.

Restrictive licenses are another limitation that developers may have to work around when relying on OSS, too. For example, Telegram is an open source messaging software that relies on a modified version of the GNU GPL 2.0.

It’s pretty compatible with most business needs other than the fact that you have to open source your code if you’re building your app on top of it. Other licenses restrict commercial use while others prevent sublicensing or changing the license altogether.

Lesser issues that are faced by open source solutions include breaking changes, where a vendor makes changes that render newer versions incompatible with older ones; deprecation, so that the software no longer receives updates, despite your large-scale dependence on it; and lack of support – despite the availability of community help. These are usually inconvenient, but not enough to be dealbreakers for most folk.

The best of both worlds: hosted open source solutions

Despite all the advantages it offers, OSS isn’t going to be a magic bullet. When you need call support for an issue you’re having, don’t want to deal with maintaining and updating servers or risking messing with the wrong files, third-party hosts for the open source software may be just what you need.

Docker, Kubernetes, MongoDB and Postgres are all examples of open source solutions that you can choose to deploy on your own if you have the time and resources to set them up and maintain them. Some of them have switched over to their own open source license and some are in the queue. However, they all offer managed solutions, which can be advantageous for companies looking to bootstrap all their solutions quickly.

These work on essentially the same model as proprietary solutions, save for the fact that you know what’s running under the hood. They can be thought of as an abstraction to all the issues you’d have to deal with if you tried to use an OSS all on your own.

You get to enjoy some of the best things about OSS, such as fewer 0-day vulnerabilities while taking care of issues that would otherwise plague inexperienced developers, such as misconfiguration.