Abolishing vendor lock-in

Vendor lock-in one of the saddest feelings when using software.

It should be a calculated risk but usually it isn’t and thus ends up becoming an unforeseen limitation. It is a feeling of entrapment, a prison of sorts. “If only we could move our database to X tomorrow, just like that”—with a finger snap.

But even if it is calculated from the beginning, there is a yet better scenario; to escape it completely.

One of the core ideas behind (the blogging platform I’m building) is that users should be able to leave as easy as possible and self-host their blog. The goal is to empower personal independent blogs in any case.

Two steps towards vendor independence

The first step for vendor independence is for a vendor-official exit to merely exist. For online platforms, it might be hard to do that well. Every platform is different and there is no interoperability. You can’t take all your Twitter tweets and transform them into Facebook posts, for example.

With blogging things are a bit easier. For example, you can import your WordPress blog posts into Medium.

With that in mind, we build export functionality in from the beginning. One can export their blog posts into simple markdown text files, or into Zola sources, or Hugo sources. Static site generators are one of the best ways to host a blog, which is also the reason of offering these export choices.

The second step after making it possible is to make it easy.

That’s why the “redirect to a new blog domain” feature exists. Suppose you decide to start a blog at After a few posts, you decide you want to move to your own domain and theme. You want Google and whoever comes across these old tweets that point to your old URL to be able to see what you wrote.

Third step

I realised recently what’s a good third step: minimise the risk of losing vendor independence.

It’s possible for users to leave mataroa using the export feature. And it is easier to do so with the redirect feature. But, what if these things stop working?

This is where a new feature comes in: monthly auto-exports via email.

Every month an email goes to all users that have it enabled. This email has one attachment: a zip archive of all your blog posts in markdown format.

Providing the ability to take backups is never enough. Users need to be convinced to store these backups too. If they are convinced to do that, then the risk of data loss is significantly mitigated.

In this way we don’t need to convince users! We can safely store a user’s blog on their side with the simple action of periodically emailing them the backup.

Surely, there is a limit on the amount of data that can fit in an email, though, right? There is, and it’s 50MB for Gmail. That’s pretty high for text though and is a text focused platform.

But whatever the case, a good first step.