59 lines
5.4 KiB
Markdown
59 lines
5.4 KiB
Markdown
+++
|
|
title = "Some thoughts on SaaS and business applications of Free Software"
|
|
publishDate = 2022-09-28T00:00:00+02:00
|
|
lastmod = 2024-12-08T03:27:00+01:00
|
|
tags = ["saas", "scam", "vendorlock", "interoperability"]
|
|
categories = ["business"]
|
|
draft = false
|
|
meta = true
|
|
type = "list"
|
|
[menu]
|
|
[menu.posts]
|
|
weight = 3006
|
|
identifier = "some-thoughts-on-saas-and-business-applications-of-free-software"
|
|
+++
|
|
|
|
SaaS is a pain in the rear for many reasons, which bother me a lot and which I can't help but vent about today.
|
|
|
|
<!--more-->
|
|
|
|
1. Vendor lock-in. If you use a SaaS solution, you have to keep on using it, with the cost consistently rising over time. Just the other day, Zapier announced they're multiplying the price of their plans. Had we (i.e. the company I work at) not looked for cheaper automation service vendors and migrated our automations, we would be unable to continue our normal course of business without unnecessarily increasing our expenses. Props to Zapier on giving early warning, but...
|
|
2. There is no standard. Migrating from Zapier to Make (formerly Integromat) was a hassle, and our IT guy had to go to great lengths to set things up, basically from scratch. We particularly had to contend with multiple services we use NOT having API options in Make, and had to rely on webhooks instead. Not impossible to work with, but certainly a hindrance to other tasks and projects that required attention at the same time.
|
|
3. Some features, which are _the exact same_ between two different services, carry different prices. The API calls between something like ClickUp and Trello, or Infinity, are not at all that different. They're not any more computationally expensive. But they cost different.
|
|
|
|
The point being, when we use SaaS, we're spending money on a solution to a problem that does not exist.
|
|
|
|
Of course, all of this is proprietary, and it is impossible to get any of these solutions to run on our own, company-owned server. Why should they want to share their source code, or even binaries, with us? It makes more sense to shear the sheep for years instead. I can't even count the number of times I asked vendors to let us run their software on our own servers, and gotten a 'no' back.
|
|
|
|
But then we have to ask ourselves... is it really a good idea to pay a monthly fee to a SaaS vendor, instead of running our own server (or, cheaper, a VPS) which can handle all that for cents on the dollar?
|
|
|
|
For the vast majority of API calls, a simple script will suffice - there are ample libraries to facilitate these things.
|
|
|
|
So then you can turn most automations into one-time expenses, by setting up a VPS (which is the only ongoing cost - and much cheaper than any SaaS will ever be, for these purposes).
|
|
|
|
Programmers who can set these things up are plentiful and easy to reach. They may not seem cheap, but compare spending $50/mth over a year ($600 total), and spending $200 one-time to set up some scripts, and $100 for the VPS. (And if something breaks, it's fixable in minutes 99% of the time.)
|
|
|
|
**No ongoing cost, full control over your data and processing, and NO vendor lock-in.** You can use the APIs any way you want (within contractual scope), and if something breaks - you can fix it because you KNOW what is going on in the first place.
|
|
|
|
Which is where Free Software comes in. It's literally free, and you're welcome to use it. All you have to do is supply the hardware (which for servers, is not at all costly).
|
|
|
|
A simple automation stack might look like this:
|
|
|
|
- VPS (I'm partial to EU vendors but if you're processing personal data, you will want to use one based in the US)
|
|
- Linux (Ubuntu for simplicity)
|
|
- A Python installation (You can also use Perl, Raku, Lisp, or any language - whatever is most comfortable.)
|
|
- A programmer that will write your scripts.
|
|
|
|
For APIs, you want to have an account with your services, and make sure to get an API key from them. Then your programmer (or you) plugs in the API key into their automation script, and everything is running.
|
|
|
|
For regular automations, which need to recur every once in a while, you can use [cron](https://man7.org/linux/man-pages/man8/cron.8.html) - it's a wonderful utility that ensures your scripts run when you want them to.
|
|
|
|
Webhooks are also easy - there is a wide variety of web server software built specifically for this purpose. One example is [Webhook](https://github.com/adnanh/webhook).
|
|
|
|
Fundamentally, the premise of SaaS solutions is to aid in efficiency, convenience, and collaboration - the latter being the most challenging to address with Free Software.
|
|
|
|
However, when we really look at the offering, it's poor and not really accomplishing most of what it claims. SaaS solutions are universally more expensive than a custom-built, purpose-made solution. Not only are they inefficient when it comes to migrating, but they're also subject to vendor lock-in, often relying on their _particular_ way of interfacing with the automation scripts, rather than giving actual, full access to what their servers can offer.
|
|
|
|
Because at the end of the day, **every SaaS solution is merely a front-end, an interface with which customers can avoid typing a few lines of code.** On its face, it seems simple and quick. But it's very expensive, and creates a reliance on a third party that not only creates security risks _(if you're running automations on customer data... that data is accessible by whatever service you're using)_, but is also much more expensive than doing it in-house.
|
|
|
|
Anyway. Rant over. [Join the FSF.](https://my.fsf.org/join)
|