> A service has constant administration costs which are paid by the service provider. A properly designed library instead moves these costs to the users of the library.
I agree with the articles point, but this introduction, right there, is why it's not happening. SaaS turns your startup into a unicorn and yourself into a rich person. Or at least that's what you are hoping/aiming for. A library is not going to make you a billionaire. Sad but reality.
You're right. The fact that people can make outsize rewards from subscription services are the reason that even small single use tools are now 'services'.
I have a piece of software that removes the background from my video feed. It's a subscription, and it regularly phones home.
I have a piece of software that lets me visually combine, rotate and reorder pdfs. It's a subscription.
Even the simplest things, like a 'torch' are ad-supported on android these days.
It's miserable fighting off a million people who want to help me for 'less than the daily price of your coffee'.
And that's ignoring the fact that so many of these subscriptions are really quite expensive - they adopt the standard cloud pricing of 9.99 per month, even when the service they're offering is not much difference than what a $5 piece of shareware would have provided in the distant past.
I don't think either of those subscription services are unicorns or making billionaires. If anything I'm happy to see indie developers able to maintain a decent income making useful (but often niche) tools that other people can use. Of all the SaaS services I pay for, it's one like these that I'm the least apprehensive spending money on.
Video codecs are hard. PDFs are a labyrinth of a file format with traps everywhere. I bet whatever open source equivalent you'd find of these services either require some serious additional tooling to get what you want or are too outdated to be useful anymore because the maintainer moved on from the project.
Video codecs are hard, but the reason video utils become services is because the best (by a mile) video codec libraries are (L)GPLed. I suspect the same is true for the best PDF libraries that would be integrated into desktop applications (meaning compiled like SumatraPDF's library, since there are plenty of JS/Python permissive licensed libraries).
All the developers I know immediately jump down a level to ffmpeg command line utils or up a level to proper video editing software (often pirated, no less), so there's no incentive to develop a high quality simple video editor.
Yeah, I wonder if things like ffmpeg would have been created in the current culture, or if it would have been a VC funded webservice paid for with a monthly subscription, and when the company eventually failed, all the code would have vanished with it, rather than being progressively improved by a large number of people through the years and having a phenomenal positive impact on the world.
> It's miserable fighting off a million people who want to help me for 'less than the daily price of your coffee'.
Is it also miserable "fighting off" a million companies who want to sell you stuff for the daily price of a coffee? Stuff like T-Shirts, books, newspapers, candy, etc?
You seem to have a patronizing attitude towards software products/services. You seem to think that they are so simple, that they should be free. And you seem to be upset that the software's author would dare to charge money for their work.
I would never begrudge someone wanting to get paid for their labor. I probably wouldn't hire them... just like I don't buy the vast majority of things that people try to sell to me. But I would never begrudge someone for wanting to get paid for their time either. If you don't think a piece of software is deserving of its subscription fee, you can always... not buy it.
Complaining that subscriptions are a bad deal for me as a user is a valid, if weak, market signalling mechanism.
And they are a bad deal, because with each subscription comes a business relationship you have to manage, which is annoying and prone to being forgotten (which is what many companies offering subscriptions, particularly the "less than coffee" types, are very much counting on).
> Is it also miserable "fighting off" a million companies who want to sell you stuff for the daily price of a coffee? Stuff like T-Shirts, books, newspapers, candy, etc?
Yes, it is. Advertising is cancer, and quality of life improvements can be measured in your ability to limit your exposure to it.
Also, like other commenter mentioned, that stuff isn't subscription-based. It's either consumables, or usable until it wears down - which is something I can control. And most importantly, none of these examples involve me having to manage relationships with any of the vendors.
(Technically I have a relationship with each of the vendors, but it's entirely mediated by consumer protection laws. I have nothing to actively manage here, except saving receipts - I only need to know which government agency to write to if the vendor fucks up and doesn't want to reimburse me for it.)
> with each subscription comes a business relationship you have to manage, which is annoying and prone to being forgotten
Though, this is one advantage of centralized services like Paypal and the iOS ecosystem.
At any time, I can see the iOS apps that are auto-billing me and I can rescind the contract from that UI. I don't need to call anyone or hope their <button>Cancel</button> actually does anything. I don't need to watch my statement like a hawk just to make sure they actually stopped billing me or that the 7-day trial that I canceled actually canceled.
Anyone can complain about yet another subscription. But tools that help us stay on top of our subscriptions are essential for subscriptions that aren't a bad deal. The banking/financial industry stopped evolving long ago and should have built ubiquitous tools for this.
Finally, the complaints about subscription services in this thread aren't very compelling. Nobody wants to buy a subscription yet the app transaction they want on their terms (e.g. buy once, never expire) presumably doesn't exist. It's a pebble's throw from just complaining that you'd prefer if everything was free so that you could keep your hard earned money.
Aside, iOS doesn't go far enough. Just so I don't seem like I'm too kind to Apple and subscription services here, they still have a long way to go. If they cared more about consumer protection, they would enact these changes:
1) iOS notification every time we get auto-billed. Every time we get charged, we should get reminded to consider if we actually want the subscription and that people aren't just getting taken advantage of by forgetting. iOS does nicely show you your auto-renewing subscriptions, but my parents don't know how to access it.
2) nuke the ability for weekly charges. A monthly billing cycle should be the minimum because that's what people are used to. It's kinda disgusting that an app can charge $7/wk when 99.9% of auto-renew cycles are monthly, and the user has to happen to notice the "wk" when they agree to it. And if weekly billing is allowed, then the iOS pricing page should standardize it showing you how much that costs per month to make it clear that it's not $7/mo.
3) An app shouldn't be able to default to the yearly billing cycle, it should default to monthly and the user can choose a yearly cycle if they want to, ugh. So many apps will default to the yearly cycle (so, 12*fee upfront) and even require you to pick that one if you want the 7-day free trial. It's hard to see how Apple could design the system to allow this behavior without knowing it's going to make people commit to a billing cycle they don't actually want.
4) You shouldn't be able to display a full-screen interstitial that makes it seem like you have to subscribe to use the app. I was just looking for a good daily workout iPhone app this week and every app had a full-screen splash page where you had to notice the tiny "X" to skip.
That said, still better than the US system where giving someone your debit card number in 2021 lets them pull money from your account for years just because you bought a $3 hotdog from them once.
> Nobody wants to buy a subscription yet the app transaction they want on their terms (e.g. buy once, never expire) presumably doesn't exist
It used to. The subscription model is pretty new and has only become common in the last decade or so (generously; it's probably even more recent). Buying a perpetual license to use a copy of software was the way to buy software up until fairly recently.
You can characterize this shift as malicious, as a result of corporate greed and a desire to protect IP. Or you can characterize it as simply companies struggling to generate stable, predictable revenue with the old model, and finding subscription revenue to be more healthy. Regardless, subscription models are new, not the long-time status quo.
> It's a pebble's throw from just complaining that you'd prefer if everything was free so that you could keep your hard earned money.
No, it's not, and it's disingenuous of you to suggest that's where people are going with this.
It’s not hard to find a T-shirt I can wear over and over again without having to keep paying for it. Nowadays it’s nearly impossible to find software that lets you pay once at a reasonable price. So yeah, it is very frustrating to fight off subscriptions.
I think the problem is that people are overestimating the benefits of subscriptions.
Yes, subscriptions make recurring revenue. But so does pay-once software, as long as you don't stop getting new users. But your SaaS subscribers also churn, so you can't stop getting new customers there either.
Pay-once has the huge advantage that the barrier to entry is much lower. I'm pretty sure that it's much easier to sell a 50€ app than a 10€ subscription. And that 10€ subscription means you need to keep your customers for at least 5 months. If they don't need your app anymore for some reason before that, you would have made more with the pay once app.
I mean, if you have recurring costs per user, please go for a subscription. But folks shouldn't assume that pay once is unsustainable. You just get the full lifetime value of the customer up front and you don't have to worry about them churning!
There is a hidden problem here, which is app store policy (all of them, afaik).
Setting up a subscription? Easy. Selling software once.. and just once? Also easy.
But if you want to follow the classic version model, where users pay for upgrades? Now you have problems. The app stores see a new version as a completely new piece of software, so you have to build up reputation for it from the ground up, and if you want to overlap the old and new version for awhile, which is usually a good idea, you run the risk of people buying the old one by accident and getting mad at you.
It's just not a use case which is supported anymore, and it should be.
This, a million times this! The app stores made the most sensible model extremely cumberstone! I want to buy a software and own it forever. On the other hand, forcing the developer to provide upgrades for free forever is not sustainable.
Maybe there is a clever way to work around this issue using in app purchases ...
You are overthinking it. A lot of software just doesn't need elaborate updates.
For one utility app that I sell, I just build a new version every couple of years when it's no longer compatible with the latest OS, and people still buy it. There really is no need for updates for some apps.
If there is demand for updates (eg. because customers want new features), then you can just sell it as a new app. People who want to upgrade can get the new version. And people who are happy with the old version can just continue using that.
The folks who complain that they can't sell yearly updates on the app store are basically just trying to sell subscriptions without calling them subscriptions. They should just sell their apps as a subscription instead. It's not really pay-once if users have to buy an upgrade every year.
I don't think that's really the same concept, though.
Yes, a utility app might be "done" at some point and only need updates when the App Store requires you to build against a newer iOS SDK. Fine. But many apps go through large changes over time and accumulate large improvements that might be worth paying more for.
Selling a new major version as a new app is a clumsy experience for users. They need to find the new app, install it, somehow transfer all the data and settings from the old app to the new, and then delete the old app. Most of that isn't something the app author can automate or do for the user.
I agree that some people might "abuse" this sort of functionality to sell subscriptions without selling subscriptions. But so what? Under this imaginary App Store upgrade flow, the user could also choose to keep using the old version and not upgrade. That gives the user more choices, not less.
> Pay-once has the huge advantage that the barrier to entry is much lower. I'm pretty sure that it's much easier to sell a 50€ app than a 10€ subscription.
I think you've got it backwards. I can't think of many examples that suggest that this is true.
The iOS app store is a very hard place to sell an expensive $50 app, yet it's a very easy place to sell 7-day trials that turn into $10/month subscriptions. Immediate cash outlays are always harder to sell than pay-over-time deals for various reasons.
One reason being the customer's attempt to avoid the feeling of overspend: that you can always stop subscribing when you're done rather than getting "stuck" with the product, even if the one-time cost is a better deal. Another reason just being that you're asking for less money upfront which is always easier.
In my own experience, people will even stick with a pricier monthly billing option over the yearly billing option just to avoid the larger hit, even when they've been a customer for five years and know they'll still be subscribing a year from now.
I certainly appreciate how us HNers might prefer a one-time cost over a subscription, but I wouldn't try to generalize that to customer behavior.
>I'm pretty sure that it's much easier to sell a 50€ app than a 10€ subscription.
Very much this for me, I will go to great lengths to avoid using software with subscription fees. For example, I was fine with paying several thousand for the Adobe suite and upgrades in CS4-6.5 days but no way will I pay $50/month for the same software. The cost may be less upfront but I have an easier time justifying a single one time purchase than a continual unending string of fees. I don't use the software enough to justify the expense month after month so seeing the bill again and again wears on me until I cancel.
> I mean, if you have recurring costs per user, please go for a subscription.
I sometimes see software that is running 'in the cloud' for no discernable reason. Yes, those companies have recurring costs per user, but that's entirely their choice, the more natural way of writing a simple file transformation tool is as an application, not a webpage.
So write your own software for your needs and sell it for a one off price?
But you presumably won't because the incentive isn't great enough. Which is exactly why people milk subs. And if you're not willing to do it for the incentive of a one off price, why should anyone else be?
> So write your own software for your needs and sell it for a one off price?
Should he tailor his tshirt too? It is totaly fine to whine about something without fixing the industry by yourself.
I for one don't like the movement of commercial software to forced cloud integration. Big or small business. What would have been shareware or naggware would today be SaaS and be gone the day the server shuts down.
No, because t-shirts are already available for one-off prices. He's already willing to pay enough to motivate people to make them for him. He and/or wider society are not willing to pay enough to motivate people to make him one-time-purchase software, apparently.
And the end result of this whole thing is too-expensive software that no one is willing to pay for and doesn't get used, and no one's problem is actually solved. And then when the "startup" fails, the code is of course not turned into a library, and it all starts again.
If you think an $x one-time payment is a great reward for making y, then make y and charge $x. Seems like a free opportunity to me. If it's really so simple, you can easily undercut those doing the subscription model.
Unless, of course, $x is not actually that motivating a fee for the work. In which case, it's a bit entitled to expect others to work for a fee that doesn't spur you into action either.
Fells like the reason one off pricing is less common is because the model has felt broken since the time of Kazaa (file sharing app from way back), Napster etc. For some reason software is almost exclusively sold through app stores. I don't remember the last time I bought software that wasn't subscription based for a non mobile device. Ok, maybe one app.
Well that and probably the pricing psychology of paying what would be your LTV as a subscriber up front.
That’s also why I don’t agree subscription software is categorically detrimental but more of a trade off. The benefit is there for both parties: for the seller it’s easier to convert people because you’re only asking for the one month or one year price, for the buyer you’re at most out that same reduced price if the service doesn’t work out.
The negative is of course that you don’t own it outright, but it seems a lot of people are happy with the trade off. Apart from HN.
The parent isn't arguing against paying for software, they're arguing against the subscription model.
I was a professional designer once. I happily purchased Adobe software to do my job; it was the best out there. Adobe switched to a subscription model and I no longer use their products. Thankfully, alternatives have presented themselves, and there are now capable software suites that I can pay a fair price for.
That's fair - but if you tear that shirt through your own usage or because it was poorly made - that's on you.
There is a very fair expectation of continued support when it comes to software, this doesn't need to include new features, but security issues in libraries should continue to be fixed. That implies an ongoing cost that might not have an ongoing revenue stream to sustain it.
When it comes to shirts there is no similar expectation of ongoing maintenance - Nike isn't going to come to your house and resew a seam because they did a shoddy job the first time.
This was the attitude that made me not use the graphic design degree that I got and move into software development (other than the fact that I had been building and using computers since I was 12). People look at the arts as a "thing you should just do because you enjoy it". Can you make me a logo in your spare time is a common refrain. It seems to have trickled down to software development.
Anything anyone has a true passion for, eventually, will be seen as a free commodity by interested parties, unfortunately. I wish it weren't so, but business acumen and true passion are often enemies.
This. However, the burden of dealing with dozens of not only subscriptions, but change in subscription models (none->monthly, annual only like Prime, or per-usage) is daunting to many.
In particular, if I can't get family subscription for services like VPN, video, etc, I simply don't bother - because I'm not maintain 2-3x subs and I'm not going request close family to pay for something they may not need.
So I choose not to pay and look for simpler alternatives in that case.
It's not about "getting paid for labour" It's the attitude and environment a whole generation of devs is brought up in.
In the olden days, if you encountered a problem and had an idea how to solve it, you sat down and hacked a solution. No matter at work or in the evening at home. You had fun doing it, it improved your life, you open sourced it to share it with the community with the goal of having other people help you improve it or even helping your peers. That's how most of the small tools in the GNU toolchain were created as well as even Linux etc. And many of them live on today even as the original maintainers left or didn't keep improving by way of forks.
Today, if somebody has such an idea, they sit down make a MVP, find a cofounder, apply for YC, move to the valley, wonder about seed funding and product/market fit of their SaaS. And hope for getting acquired for big money. And most don't, they just fail and die. It's about money first and making it big.
> You seem to think that they are so simple, that they should be free.
I don't think anyone is claiming that; the opposite of subscription SaaS is not freeware. At some point companies realized that they could have more predictable, long-term, higher revenue streams if instead of selling you a bit of client-side software a single time (with uncertain future business from upgrades), they sold you a subscription to their software, which is often (unnecessarily?) cloud-based. This all feels weird to those of us who have been around for a while and got used to buying software the "old way".
Building a cloud/web-based app means it's (mostly) effortlessly multi-platform. You don't have to build separate apps for Windows, Mac, and (occasionally) Linux. (But there's also the e.g. Electron option.) And meanwhile, you can push bugfixes and new features out to your customers near-instantly. Your release cycles are small, and are often measured in days or weeks, not quarters or years. You can justify charging on a subscription model because you are constantly working for your customers. On the flip side, if a customer wants to cancel their subscription, what happens to any data generated with your app? If it's in a proprietary format, IMO it's unethical to hold a user's data hostage like that.
Selling software by the download is a hard business to be in, and the incentives are not always aligned well. You're expected to fix bugs and release patch versions for "free". But usually you can charge for new major version upgrades. So the incentive is to skimp on bugfixes and instead work on new, big features. Beyond that, there's an incentive to make big, sweeping changes to your app so you can justify calling it a new major release, which triggers an upgrade fee, even if those changes don't actually benefit users. (Then again, this phenomenon, for some reason, exists with subscription apps too.)
But many people just see it as a money grab, especially for products that used to not require a subscription. In 1998 I could go and buy a copy of MS Office in a box from my local store, and it was then mine. I could use it as long as I could find an OS that would run it. Likely I could still run it today under wine or something if I still had a copy. But now we have Office 365. I have to sign up for a subscription. If at any point I want to cancel, I can't use the software anymore. The data I've created with it is still mine, but I have to deal with imperfect format conversions done by other office apps. You could perhaps draw a similar parallel with Adobe's creative software.
Regarding money, I think there's also an aversion to having to pay indefinitely. Sure, MS Office was expensive to buy, at several hundred dollars or whatever it was. But when I forked over that cash, I knew I was done paying for that version. Even if the SaaS version is priced at a few dollars a month, and I'm unlikely to ever subscribe long enough to pay the old "full price", there's still an irrational feeling of getting a raw deal. I think most people are more comfortable with known, one-time costs than with recurring costs, which may change if the company later decides to charge more.
Is there a standard way to get at "turn the screen white and the brightness up"? I used to have a torch app that had that mode (presumably, lower power than driving the flash LED), along with a few others (like a night-vision-preserving red screen).
Hardly the most challenging app in the world, but it was worth the $.99 I paid for it. I probably could have written it myself, and while I personally would likely have made it free, I felt ok giving somebody a tiny tip for it.
App store monopoly and monopsony status is a seperate (albeit related) problem from app stores having no or shitty quality control. If a non-monop'y app store wants to control peoples' business... well, they can't; people will just use a different app store; that's the point.
MS Office is a great example of this because they squeeze money out of folks when it seems the features added are minimal. The only interesting aspect is cloud-collaboration, but that could be P2P instead. I'm willing to wager most folks still use the same subset of office functionality: page layouts and fonts and such have been around for a while; financial formulas rarely change; etc. But yet, they are charged an arm-and-a-leg for the "cloud."
And then there's Amazon with their lambdas—trying to convince people that they should forget how to program and rely on a plethora of beautiful, shiny one-liners.
MS Office is a good example, and like you mentioned Word is pretty much Word from 10 years ago.
But you know who else does this? Book publishers. Specifically, textbook publishers. Every year there is a new edition of a calculus or algebra book. So this is a business model that has been around for awhile, and takes a variety of shapes. Such as planned obsolescence.
Software has it easy today, though. They can just cry "security updates" and instantly have a solid case for the subscription model. Even if it is nonsense.
> They can just cry "security updates" and instantly have a solid case for the subscription model
or they can cry "changes in browser and OS!" stuff that worked 5 years ago may not work the same today, or at all. Having a business model around it to help keep up with changes that are largely outside the control of that vendor helps ensure the value still stands. Or... new value can be unlocked - want your useful service to be able to handle that new video format, or compression, or audio format? I seem to remember something as 'trivial' as Apple moving MacBooks to "retina" displays caused a lot of problems and non-trivial amount of work for a lot of tools and services to be able to work 'correctly' with the new formats.
Lambda is absolutely the worst thing to happen to software engineering in recent memory, IMO. I've seen it used well, but only a tiny percentage of the time. The rest of the time it's tortured and abused and the project turns into a sadistic exercise in forcing the problem to fit the desired solution, instead of the other way around.
I think this is especially annoying on the app stores, as there is no way to filter for a specific price (range) or in apple's case for apps that don't sell your data to everyone and your neighbor
Pretty sure there is normal software for those uses, and you can get free/open source apps with no ads from F-Droid for all basic needs (such as a "torch").
There's a bible app called YouVersion that's by far the most popular app on both iOS and Android.
"YouVersion Bible is notorious for privacy violations and dangerous data collection. Yet, here it is: still seated firmly in the Play Store, racking up over 100 million installs with a whopping 22 permission requests."
Great comment about SaaS, ganafagol. It's running software that you make money from, not code. Code is just the leverage you have over changing the running software. The running service itself is the ultimate "concrete object" that, for generations, software has been moving away from. There has never been a "compute fabric" as robust as the modern cloud, so long-lived mutable data-structures are becoming more common, and will be even more so.
(We try to have our cake and eat it too in an iterated game where the unit of deployment is immutable and reproducible. That game is called devops and more specifically, continuous delivery.)
A few libraries in the Java world have this model. They haven't produced unicorns but seem to be pretty stable businesses - jOOQ(1), hibernate(2) etc. I'm researching DB libraries for work and so those are the ones I recalled immediately, but I think there are some commercial UI ones too.
I'm very happy that alternate universe doesn't exist. Libraries outnumber SaaS products 100 to 1 and I remember wrangling with software licenses on library implementations in the early 2000s. It sucked.
Distribution (the internet) and open source disrupted that business out of existence.
I think we need something like that for the cloud. Pay an interchangeable cloud provider a monthly pittance, and they host your choice of services as turnkey solutions. No more centralization of data, and no more paying $5/mo for a service wrapper around some FOSS CLI tool.
Why do you think it's limited to the FOSS world? Surely most SaaS companies (and certainly the most profitable) are business-to-business companies, and presumably they're quite a lot more valuable than the average library vendor. I would also hazard a guess that onprem services occupy an intermediate tier both in terms of profitability and in terms of integration model: they're a whole service (as opposed to a lib) but the customer is on the hook for integrating and operating (as opposed to SaaS).
> Only on the FOSS world, because it is the only way to force devs to pay.
What about the approach that the Qt library uses, where they have a free GPL version and a paid commercial license? People might pay to avoid GPL obligations while using the library.
The Qt Company recently changed their publishing model and they provide only recent versions as (L)GPL. Thus Open source users have to migrate to Qt 6 or run an outdated version of 5.7, missing bugfix releases. Migrating to Qt 6 however isn't easy as some components aren't available for Qt 6, yet. Thus Open Source users requiring those modules can't go anywhere.
Aside from that the Qt company restricted access to their builds behind a registration wall.
And if you are willing to pay they created a pricing model, which isn't easy to understand and can become quite expensive, (233$/month/developer) and as it's a subscription you can't simply pay a license and go from there, but you have to subscribe and the moment you terminate the agreement you are forbidden from distributing your application any further with Qt.
Thus unhappy open source users and many users who at least claim they would like to buy for sensible cost, but can't afford.
There is another alternative universe where commercial software, including libraries, gets sold
I remember old issues of Doctor Dobb’s Journal with full-page ads for libraries you could buy to add features to your shrink wrap desktop application. It was a viable business model once.
They certainly exist, but I don't think they are remotely as common. I can think of dozens of paid services that I use at work but one paid library. Maybe 5 if you include things like database SDKs where we paid for the database.
A lot of stuff in the automotive world has paid libraries. They can't be services because they need to be real-time, but they're not free because implementing a complex IEEE standard as software is not trivial.
>SaaS turns your startup into a unicorn and yourself into a rich person. Or at least that's what you are hoping/aiming for. A library is not going to make you a billionaire.
The article's author seems to be making an indirect reference to Moxie Marlinspike (Signal) "ecosystem is moving" essay[0].
If so, Moxie Marlinspike's method for becoming a billionaire by creating non-profit 501(c)(3) organization and providing Signal's source code is a very strange way to cash out of a unicorn.
And btw... even though users/developers have the Signal source[1] which enables them to create an alternate chat universe that's not dependent on Signal's official service/servers, that isn't good enough. They still want to federate[2] with Moxie's servers. This aspect isn't addressed by op's (catern) article.
In other words, having a library (or even the full client+server source code) doesn't really solve the users end needs. It turns out that many place more importance on the service than the library.
EDIT to reply: The first IKEA business in 1943 was for-profit. The non-profit foundation (Stichting Ingka Foundation) was formed later in 1982 so the owner could take advantage of tax efficiencies. I don't see how IKEA's opposite timeline has any relevance to Marlin's playbook to become a billionaire. Is there a real case study of a 501(c)(3) non-profit entity tricking everyone into a bait & switch and minting a new billionaire?
> If so, Moxie Marlinspike's method for becoming a billionaire by creating non-profit 501(c)(3) organization and providing Signal's source code is a very strange way to cash out of a unicorn.
On the contrary:
Step 1: The service is already centralized
Step 2: Make the central service closed source: happening now.
Step 3: A no profit can be turned for-profit or used together with a for-profit (e.g. IKEA)
Signal can become a perfect example of bait-and-switch market capture.
It doesn't even take oodles of money from a SaaS platform to motivate turning a library into a service.
Even in in-house development, developers are often motivated to build services and have internal customers take dependencies on them so that they can expand influence and demonstrate ownership in a way that gets noticed by senior leadership and put them in line for promo. It also opens up the possibility for stakeholders to build their own little fiefdoms with access controls, intake processes, and a justifiable source of funding.
That seems like an overly cynical explanation. There are many reasons why you would want a service instead of a library:
1. Even if the service is just a CRUD API, then you can isolate the storage layer from external users. If you just a have a library then every application needs to be able to connect to the DB.
2. You can protect mission critical resources through rate-limiting in a way that is way harder with a library.
3. Even if those are not problems, if someone has a DB connection then there is nothing really stopping them from just going around your library entirely. So random service X gets popped by an attacker. Now they can execute arbitrary queries against your DB. With a service they are still constrained to the operations exposed through the API.
4. You have a lot more freedom to change internal implementation details for a service. Need to change your DB schema (or migrate between postgres and mysql) then you can hide that behind the service interface. If you have a library out there then you have limited control over when people take version updates and it is virtually impossible to synchronize the update across all consumer of said library.
You've just described requirements that belong to a service. Congratulations, you made the right (obvious) decision.
I'm talking about writing entire services that are just wrappers around ffmpeg, pdf2html, parquet-tools, Olson tzdata, or a 10-parameter logistic regression. No stateful behavior, storage, or authoritative source of truth involved. The worst case I've seen was a service that just enumerates a bunch of values of constants (that actually never change).
There may have been some future-proofing in mind at the time, but more likely it was a solution in search of a problem.
Fair enough, but that is why the question of service vs library is not really a question that has ONE answer. It depends on the use case.
But to push back (slightly) on your chosen examples. Dealing with binary codecs is actually something where it can make a lot of sense to wrap it in a service (even if you're just using the open source tools under the hood). It is a space that is notoriously prone to security vulnerabilities up to and including RCE vulns (https://www.cvedetails.com/vulnerability-list/vendor_id-3611...). So doing it in it's own sandbox can be a smart move. Maybe not a SaaS product per se but still something you might want to isolate as a service separated from your application server.
It is a reality. Another point is that piece of code does not mean everything. When it run on an optimised platform, it will give much value. For example, a multi-core algorithm. When it is a service, that can be ensured. Also, the Library and the beneficiary application run on same memory space (normally). So the lib code can cause crashes or can hack privacy. Another thing is your secret-sauce is public now. So it can be copied or reverse engineered.
I detest that people have accepted this business model as being the norm. I think the bar has been lowered drastically in terms of what people are willing to pay for. If somebody launched Notepad as a Service with premium backgrounds instead of that boring, conventional white color, then you'd probably find enough people willing to pay $9.99/month for it. It's just absurd.
It is a possibility that could happen, but it is not very probable.
I am certain taht millions of services are written and dies in lonely obscurity.
According to a Hulu documentary I watched recently some woman makes over 150K a month from OnlyFans.
Lots of people want that and sign up and the vast majority will not make anything.
Or the more classic moving to Hollywood to become a
famous actor making $$$$, or be a rock star.
The chances your services will make billions is slim,
If you write a good library, you can sell it.
I would much rather buy a library than a service.
(I may be in the minority for sure).
If you give it away, and if it does prove highly popular then wrapping it in a service and offering it that way will create some income.
With that strategy you can iterate over functionality and find out what the market wants the most and create a product that is more mature as a service.
It still applies for internal usage. You can have 18 microservices, but if you're strict about versioning and start treating them like libraries when possible, you're going to save yourself a lot of headache.
Recurring revenue is much more stable than license purchases and also less prone to piracy. Adobe's incredibly successful transition (from a share price perspective) is a testament to the value ascribed to recurring revenue models.
In fact, companies that sell services with a recurring revenue component are generally seen as higher margin and more stable across industries. For instance, Aerospace & Defense companies that have a strong "Aftermarket" presence (which really means maintenance, spares, repairs, etc.) generally command higher valuations.
The SaaS hype just takes this to the ultimate level. Digital services have very little costs (relative to their physical counterparts). Recurring digital revenue equates to mind-boggling numbers like Salesforce having >70% gross margins, which is probably the most prominent reason why Tech valuations have skyrocketed in the cloud era
> For instance, Aerospace & Defense companies that have a strong "Aftermarket" presence (which really means maintenance, spares, repairs, etc.) generally command higher valuations.
Not sure whether that's a good example, because that might just be exploiting some weirdness in how government projects get funding approval, and might not be relevant to the wider (and software) world?
I suspect it's the same reason game devs are hot for streaming. When the code only runs on machines you control, piracy becomes impossible. By contrast, trusting people to respect licenses on code on their computers is how piracy happens.
In my opinion this is a feature, not a bug, but the business reason is clear for why all commercial software is moving towards the SaaS model.
How much game piracy happens these days? Since steam became such a good distribution platform and my internet connection got fast I haven’t even thought about pirating a game. AAA titles are expensive, but there aren’t a ton of them released every year, and downloading cracked installers is a huge security risk.
Been a while since I saw a license without recurring payment, particularly for code components. B2B, all libraries I've dealt with were paid per-developer-seat-year.
> SaaS turns your startup into a unicorn and yourself into a rich person
If the function could be served by a library? Probably not. Because someone else will write the library, and then your high-latency, internet-required, for-pay service will be competing against a free (presuming the library is available that way, which if the first one isn't is still likely eventually), low-latency, offline-capable library.
wrong, you can have both, several successful open source projects have libraries that are released under friendly open source license. SaaS comes in to provide added benefits over DIY approach, both realities can happily exist and in fact open source growth drives SaaS business models.
Don't worry. If the functionality is useful, then eventually there will be a free open source library that will prevent the original author from becoming a billionaire.
there is also the fact that companies might see a smaller operating expenditure vs a larger capital expenditure as a benefit as well. depends on the situation of the company but it could be an easier sell.
I agree with the articles point, but this introduction, right there, is why it's not happening. SaaS turns your startup into a unicorn and yourself into a rich person. Or at least that's what you are hoping/aiming for. A library is not going to make you a billionaire. Sad but reality.