A very important announcement.

Parsegate: The Case Against Proprietary Infrastructure

Parse’s sunset announcement has left millions of users unsure of the future of their mobile apps. One thing, however, is clear: by integrating proprietary software, they gave up control over their own infrastructure.

Ease of adoption masked the technical investment engineers made in Parse, a proprietary mobile backend tool. And this phenomenon isn’t isolated to Parse: the painful migration off Heroku, the paralysis when Github goes down, shows the cost of using proprietary elements that make up the core of our infrastructure.

The argument here isn’t #NoProprietaryInfrastructure. The argument is to fully consider the risk we take when using proprietary infrastructure.

Let’s consider an example. Imagine if Heroku didn’t shut down, but instead decided to raise its prices threefold (arguably, not an unrealistic scenario). What would its users do? Many would bite the bullet and stay on Heroku, while others would make the painful migration onto AWS, as so many have already done. In either scenario, they feel the cost of lack of control over their own software.

And this risk is more than just technical. Software is built by companies, and companies are affected by politics and markets. Implementing proprietary software as part of a technology stack is implementing market risk into our products, as many learned today with Parse.

We can mitigate this risk.

Our world is a far cry from the closed-off world of Richard Stallman’s essays in the early 1990s, when free software advocates were labeled as communistic radicals. Instead, the world of software is continuously trending toward more open. Today, there is an overwhelming expectation that server software be both open source and high caliber — for example, the entire Linux container market is based on prolific, open source contributions from Docker, Google, CoreOS, Red Hat, and more.

We already live in a world of free alternatives. Don’t want to pay for Slack? Use Mattermost. Don’t want to deal with Github outages? Self-host with Gitlab.

When building a product, the evaluation of third-party software tools should include more than considerations of ease of use — it must also include the risk associated with lack of control, both technically and politically, over our software infrastructure.

Enjoyed this? Hit recommend and check out more stories by Mackenzie, who is busy building Redspread, an open source tool to deploy Docker to production in one command.