Most recent update: 10th July 2022 - 23:19:04 - 6696 characters

Ease of use, open source, and SaaS

In a recent project I was setting up a Postgres database. I've done this many times over many projects. None of it is a surprise.

Well... One surprise... Surprise! Data loss. On my own personal project.

Even though I'd set up a production Postgres cluster a decade ago (with read replicas and continuous archiving such that even when I accidentally deleted the production database there was no data loss and only a few minutes downtime) making Postgres resilient to errors and data loss is still a challenge.

It's not Postgres at fault. This is still closer to the default than not for nearly ever database or data store.

How is that possible? Not "how was I an idiot this time" (as I promise you there will never be a lack of idiocy from me) but simply "how wasn't I saved by the tooling?"...

I'm certainly no genius at databases but I have actual production experience and was still caught out. Having a safe place to put your data such that it won't disappear is a foundational bedrock of modern computing.

The incident itself

docker compose up starts all containers. docker compose down removes containers - without asking. What I had intended to do was docker compose stop.

The Docker Postgres defaults aren't trivial. I did miss a key core default.

Backup script with cron job just outside of the daily backup window as continuous archiving is not trivial.

Deferred or ignored more resilient backup solutions as it's not trivial and I'd intended on making it more resilient over time.

The broader question

Open source and developer friendly

Good user interfaces, whether that means trivial to set up or resilient to user error, require careful work and design. Such a user interface generally also must be made by an expert with the specific intent on assisting and playing out the experience of a new user. Most of the time it also requires sacrificing flexibility and customizability (see: skill floor vs skill ceiling) to make the Pareto optimal workflow fully supported and debugged.

Self serve software creation and extension, as seen in open source, generally stands counter to that.

Open source is unpaid for the most part. Most projects are crafted to directly serve the creator's problems. The initial and default user for a tool is the creator themselves, then perhaps a few die-hard (and technical) users, and so on. This is brilliant. Worrying about everyone else, the general public, is an easy way to lose momentum and sanity - especially when you're not being paid for the inevitable deluge of customer support.

SaaS as both the solution and problem

Imagine you wanted to set up a database. It's an open source database. The majority of the tooling for reliably deploying and maintaining this database exist as open source. Yet most developers will suggest and/or default to paying for SaaS. Why is that?

Maintaining and backing up a database is not necessarily "difficult" but it can be complicated, and where there's complication there's potential error. When an error might lead to data loss an error prone approach is generally no longer deemed an option.

SaaS not only own the hardware but their proprietary tooling on top of open source libraries can make an unreliable and error prone process into a reliable one.

SaaS platforms are usually far more limited than the open source solution too. Such limitations can mean a cleaner experience and less unexpected hiccups. AWS aren't likely to support any S3 compatible data store, they'll support S3. Their promise is if you can live within the limitations that we set, be they platform / technical / financial, you'll not lose your mind trying to keep this alive. You won't be deliriously searching through forums at 3am trying to work out why replication fails on a batch over 1024 as your pager screams at you in the dark.

As we lean on SaaS overarching layers to provide the seamless experience however the underlying open source layers and process become less and less well exercised. The experience of using the open source database with and without SaaS may no longer even be comparable. Those installing and running their own system, away from the SaaS seamless experience, likely have very particular issues or needs. The default "new user" for the open source project is now far and away from the novice user.

We now have a funnel of money that's no longer going to the open source process to deal with the most complicated piece of the puzzle for new users: ease of use.

The open source monetization valley

Open source solutions exist but are not trivial and/or not resilient. No-one is willing to pay before such a solution exists and there's no guarantee money given to the project or creators will result in this (assuming the creators have the time to do this at all).

If an improved solution is made in open source the money is likely to fall away. This isn't an enforced recurring payment. The default for open source is still "no money exchanged hands".

SaaS will charge for and (hopefully) produce a resilient solution. The SaaS business will likely maintain high margins regardless of the exact overhead. As the tooling exists a layer above open source it can remain proprietary and the monetization has no guarantee it'll be used to improve the product and definitively no guarantee it'll be used to improve the resiliency / simplicity of the open source (as that's now direct competition).

Open source core and paid management tools

Perhaps the best of both worlds except they're still closer to SaaS than not.

The company is likely focused entirely on the product which means money will likely go back in to improving the open source product. The "ease of use" / "resiliency" will be kept limited and/or behind a paywall.

As it's a smaller entity there is a risk they may die, especially if their only revenue is from the product itself. This is made all the more complex when the compute platforms themselves have better established brands (should they offer equivalent services), are the likely destination for most self deployed instances, and already have the payment information for potential customers.

Conclusion

Saying "open source should X" is nonsensical. There isn't a single driving force behind open source. It's a self organized and chaotic mass of

What we can say however is that SaaS is far ahead of the open source community on this front.

SaaS takes on the problem of "ease of use" and "resiliency" and funnel resources directly towards fixing it.