The Curious Case of the Unpaid Labour and the Unwilling Payer (Or "Yes, Your Car Might Need a Subscription Model")

A few years ago a rather earnest automotive executive informed me, with a straight face, that customers would positively adore forking over $15 a month to activate a car’s pre-installed heated seats. I believe I snorted so hard scotch came out of my nose (it burned). Turns out, Cox Automotive’s research largely agrees with my assessment: only about a quarter of car buyers tolerate subscription features, and the term “money-grab” seems to be a popular choice in focus groups.

Now, here’s the kicker: these very same customers, the ones aghast at paying for BMW bum-warmers, also expect their infotainment and car comfort systems to rival the best in the industry with the stability of their personal devices. They demand seamless Over-The-Air (OTA) updates and a system that never -and I mean never- crashes during their terribly important podcasts.

Welcome to the SaaS Paradox, ladies and gentlemen. Everyone wants software to be free like FOSS, polished like Apple, and flexible enough to patch a leaky boat. But as soon as monetization is so much as discussed, suddenly capitalism is the root of all evil. Oh, and don’t forget how everyone wants developers and engineers to earn a ’living wage’ and be properly compensated for their skills and talent… as long as someone else is the one paying them their living wage. It’s a proper pickle, this, a genuine conundrum of perceived value in the software world.

The SaaS Reality: Servers Aren’t Powered by Good Vibes (or Unpaid Labour)

This isn’t just about car features, though the automotive industry does provide some rather egregious examples. It’s a microcosm of a much larger, more pervasive issue in software development.

Let’s be blunt about why carmakers (and indeed, every SaaS founder worth their salt) are scrambling for subscriptions:

Bug fixes cost money. Your darling “$0 forever” open-source media server (yes, Jellyfin, I’m looking at you) still requires dedicated developers to wrestle with ffmpeg’s eldritch horrors. Meanwhile, Toyota’s infotainment team is fielding 3 AM panic calls because Apple CarPlay decided to blue-ball a CEO mid-yacht rock playlist. Someone’s paying for those unfortunate souls.
Hardware isn’t the product anymore. Modern cars are essentially wheels with a cloud-computing side hustle. That “free” 5G hotspot? Someone’s paying AT&T/T-Mobile. That navigation map update? A cartographer didn’t trace highways for the sheer joy of it. When did you last upgrade your iPhone? A year ago? Maybe two? Maybe even more? How often do you demand software updates? Would you be happy using a 5 year old version of whatever killer app you use?
SaaS scales; one-time purchases don’t. The automotive industry’s profit margins are thinner than my patience for Docker’s finicky placement of the -d flag during a docker compose up <service> run. Subscriptions offset the inconvenient truth that you’ll never pay $5,000 for a software upgrade even if that’s what it genuinely costs to develop.

On one side, you have customers (consumers or businesses, it matters not) increasingly reticent to pay for Software as a Service. They want the functionality, the continuous updates, the bug fixes, the new features, but they balk at the subscription model. They’ve been conditioned by the old paradigm: buy it once, own it forever.

But here’s the rub: software isn’t a static widget you can put on a shelf. It’s a living, breathing entity that needs constant care and feeding. My Proxmox server, humming away in the corner, running Docker containers orchestrated with Docker Compose, serving up Jellyfin and a whole media stack (Sonarr, Radarr, Bazarr), or my Traefik reverse proxy handling TLS and PocketID authentication- every single one of those tools requires ongoing development, testing, and maintenance. New vulnerabilities are discovered, new hardware comes out, operating systems evolve, and user expectations shift.

If you ship a car with software that gets no updates, no bug fixes, and no feature enhancements for five years, it becomes a relic. It gets technically inferior. Users lament the lack of innovation. They’ll ditch your brand for the one that does offer those continuous improvements, and more importantly remind other potential buyers to avoid your stangant development like the plague. So, how do you expect continuous improvement without continuous payment for the engineers who make it happen? Do we expect them to live on goodwill and stale biscuits?

The FOSS Fallacy: Free as in Free Beer, Not Free as in No Effort

This is where the Open Source (FOSS) world enters the chat, looking quite sheepish. While commercial SaaS companies struggle to justify their recurrent charges, FOSS projects are facing an even more insidious problem: increasing demands from users who expect full-time development from people working for free.

The history of open source is rooted in the belief that shared code fosters innovation and reliability. And it absolutely does. Look at my homelab: it’s a veritable shrine to FOSS. Ollama running local LLMs with Open WebUI as a frontend, MinIO for S3-compatible storage experiments, Tailscale for mesh VPN across my motley collection of machines. I use Seafile for easy file access on MacOS/iOS (because who enjoys SCP on an iPhone?). My Git repos are overflowing with configuration files and documentation. Watchtower auto-updates my Docker images like some digital maid. It’s all fantastic, powerful, and overwhelmingly, free.

But “free” comes at a cost, usually borne by dedicated developers sacrificing their evenings, weekends, and sanity. Users, emboldened by the “free as in speech” (and, often, “free as in beer”) ethos, flock to these projects, enjoying the fruits of someone else’s labour. Then, they start demanding more: “Why isn’t feature X implemented yet?” “This bug has been open for three weeks!” “Can you add support for obscure hardware Y?” They forget that software doesn’t just magically exist. Someone had to sit down, write the code, test it, document it, and manage its deployment.

The open-source model thrives on feedback and community contributions, and the most successful FOSS companies contribute heavily back to the projects they use. But the economic realities are harsh. Building financially sustainable open source software ecosystems is incredibly challenging.

The Homelab Epiphany: Pay for What Matters

This hits close to home (literally). My Proxmox cluster runs:

Tailscale: Free for personal use, but I happily pay for teams. Because someone maintains those DERP servers, and they’re not doing it out of the goodness of their hearts. MinIO: Open-source, but if it corrupted my 12TB media archive, I’d want a support SLA; not a GitHub issue, and certainly not a shrug.

The lesson? People pay when the pain of not paying is worse. Automakers just picked the dumbest possible pain points. No one riots about paying for Slack or AWS. They riot when you nickel-and-dime them for steering wheel buttons or, heaven forbid, the ability to warm their posterior on a chilly morning. Shopify’s SaaS model thrives because merchants clearly see the ROI: hosting, PCI compliance, and not having to debug their own shopping cart [4]. It’s about demonstrating undeniable value, not just locking features.

Where Do We Go From Here?

This dichotomy of users expecting perfection for free while simultaneously refusing to pay for ongoing development is simply unsustainable.

Perhaps we’re heading towards a hybrid model, or maybe a market correction. Some open-source projects are successfully adopting “open core” models, offering a free, core version and paid features or support. Others are built by companies that offer SaaS versions of their FOSS products. But this requires clear communication on what’s free and what’s paid (a feature comparison table is usually a good idea), and transparency in roadmaps to maintain community trust.

Ultimately, something has to give. Developers, whether they’re labouring within a commercial SaaS firm or contributing to a FOSS project, need to be compensated for their time, effort, and expertise. If customers aren’t willing to pay for SaaS, and FOSS developers aren’t willing or able to work for free indefinitely, then the quality, security, and pace of software innovation will inevitably suffer. We’ll end up with technically stagnant systems, unpatched vulnerabilities, and a general malaise in the digital realm.

Now, if you’ll excuse me, I need to reboot my Jellyfin LXC because even “free” has its limits, especially when you’re faffing about with autofs configs and the intricacies of rclone’s mount capabilities.

Posts in this series

personal technology automotive software homelab FOSS SaaS open-source