Not really. Your market is different. Instead of selling to business managers seeking to solve a problem, you're selling to developers. Developers tend to like solving problems themselves, and you're competing versus free.
The definition being used here for libraries and services has both being marketed to developers. We're talking about APIs, not a web product with a UI etc.
Services, in this article, doesn't refer to things that can only be built as services (e.g. because it queries a proprietary dataset) but those that might optionally be built as services (e.g. fetching and processing otherwise accessible data) and could, as easily, be built as a library.
There's an ecosystem of paid libraries and tools around Java and C#. While developers might like to solve problems of their own, standards compliance is one place that they likely wouldn't want to tread their own path if they can help it. They've got work to do, and deadlines.
You can totally sell libraries to business managers. You can sell sauteed rat's assholes on a stick to business managers, you just need the right sales pitch.
One example of this is computer games. There are games like StarCraft 2, Diablo 3, where server is required even for solo-playing and it's not possible to play offline. I think that one of the reasons is to make it harder to crack a game (as you would need to re-implement server) and to make a cracked game objectively worse (as your implementation will not be as polished).
Including a stolen library you in commercial software that you distribute is easy to do but also easy to detect, so it only means that you're willing to pay a triple of the price in damages.
For example gamedev middleware is an example of that - be it individual library, for example audio: fmod, criware, wwise, miles, etc., or full blown game enines (unity, unreal, etc.). Just few examples.
The communist party was pretty successful in helping to overthrow the Portugese dicatorship in the early '70s, but they were also democrats. They're still one of the major political parties in Portugal, and you see ads for the communist party everywhere.
The Indian state of Kerala is the most advanced, well run, and successful region of the country. On development indexes it ranks with the poorer regions of the EU. It's also largely a communist state, but once again the communists are democrats.
What I was alluding to is that one of the first comments on this thread was "how do I make money out of this?" That indicates the priorities of the commenter, if nothing else.
All aspects of life in the US seem to be increasingly money focused, driven, or dictated by. It's not just tech but wherever there is more money to be had, there is more focus on money.
At some point, I wonder if our social and economic system becomes a close enough proxy to darwinistic survival of the fittest through capital ownership that a large enough portion of the population realize they would do better outside this construct rather than inside our societies and will begin to reject the system at large.
Right now we are able to provide stable food, housing, and ERs can't refuse people for medical care but stable housing is in the downturn and Healthcare costs that lead to bankruptcy conditions are on the rise. I feel like we're really testing how low many will go before they reject the system at hand and at what point is that number of people large enough to be critical to the existing system's stability.
At some point the effort for comfortable success may become so high people just abandon it entirely.
We have voluntarily destroyed lots of economic growth and plunged millions into extreme poverty because of a virus that is not especially bad when compared to historical pandemics.
It basically allows you to share your code to others in exchange for a fee. If someone builds an app or service that uses your library, and it is paid within Fluence, you will receive a fee. This works transitively.
Oh that's a burning question for me. I'm finishing a C lib that - if all goes well - will be very useful.
I worked hard on it and now I don't know how to license it.
I'm okay with non-profit OSS projects to use it freely, but I need others to pay for it. How ? How do you express such a dual license ? And how do you ensure for-profit users reward you ?
GPLv3 with a commercial exception. Corporate suits don't like the GPL, so if they buy a commercial licence they support the project without having to redistribute (You can also offer support)
Notably, the FSF recommends against[1] modifying the GPL. And, you'd want to hire a lawyer to go over whatever scheme you're thinking of.
It's easier to draft a separate license agreement if you're the sole copyright holder.
If you're not the sole rights holder, if your project contains other GPL code, you'll need permission from the authors to license under terms other than the GPL. That would include patches from other authors, unless they sign the rights over to you.
I think AGPL is the much more effective open source license if your intention is to have corporations too afraid to use it under the open license and to negotiate a commercial exception license.
Plenty of companies will use GPL code, especially for hosted software.
It's easy, you release it open source... Then make sure you have languages "officially" promote it in their documentation and have people adopt it thinking it's great and an actively developed project that's going to be around forever, etc... And then fork it, stop releasing security updates for the older (open-source) versions, and turn it into a product that you charge people for because corporates are now dependent on it.
You put it on your resume and make your bread doing other jobs or freelance work, where you are now the top candidate in the pile thanks to the work you've done with your publically available library where anyone can inspect the source and see your handiwork.
Engineers in tech always complain that there is no proof of good work, like someone in biochemistry with a stack of papers on their CV would have. Well, this is how you do it. You spend effort sharing ideas with the community knowing you won't necessarily make a dime off of them, just like the biochem person who doesn't get paid per paper, and not spend 100% of your personal efforts working for someone else in private on a for profit project you aren't at liberty to intimately discuss.
Maybe if you code up a library that meets a specific set of requirements, but you do it in a way so that using the library seems simple on the surface but, the deeper the end-user-developer goes, the more illogical stuff becomes. At that point you have a developer too invested in the work they've already done to abandon it: a developer in the market for a "... The Good Parts" or "... Cookbook" book.
I was not thinking of Actionscript when I wrote this comment.
The way they were monetized before SaaS was a thing. You sell licenses to use them. You can't 100% prevent people from using them without a license but for the most part you don't really have to. A company with real assets is generally not going to use a cracked version of proprietary libraries and expose themselves to litigation.
>People say, "services are easy because you can upgrade them centrally, so you can avoid slow-to-upgrade users making everyone's lives worse."
> But this assumes that slow-to-upgrade users can have negative effects on everyone else.
Is the above a reference to Moxie Marlinspike's comments[1]?
So would a concrete example of your abstract essay be that communication should be a client utility that uses an XMPP library[2] instead of Signal's services?
> 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.
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 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.
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?
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.
> 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.
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.
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.
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).
>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.
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.
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."
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.
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.
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.
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.
> 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.
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.
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?
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.
> 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.
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.
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!
>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.
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 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.
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.
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.
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.
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.
> 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.
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.
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.
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
> 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.
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.
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.)
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.
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.
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 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.
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.
This makes no sense. In order to build a service, you need a library (or something very much like it) supporting it.
If you need a library, and can use a library, yay, you're done, it's the simplest and fastest thing possible. If, for some reason, the logic you need can't be run locally, then you need a service. Find or build one and use it. You will pay in application complexity, dealing with the possibility that the service is down/unreachable. You will also pay in latency.
Why is this "not even wrong" article at the top of Hacker News?
You’re right but your service could be exposed with a public API and still have your library public.
I think the best of both worlds is to have an open-source library and a service. People can choose the one they prefer. And you can still make money from selling the service.
Yes, we are both saying "use a library when possible". I am mystified by the need to write or read such an article. It seems akin to "don't use an airplane to go to the corner store for a dozen eggs".
This isn't a new concept at all, but I can't remember where I've read this before.
It is quite sensible. I'm a believer in SDKs. An SDK abstracts the backend. Gives everybody a lot more control over their own domain.
Of course, the requirement, is that the SDK needs to be super-high quality. It also needs to expose a fairly generic API that may not actually map directly to the service it abstracts/replaces.
That being said it's incredibly hard to follow this advice in environments which encourage a polyglot stack and 'the best tool for the job' mindset. The moment you have more than one language in your stack it becomes easier to build services than to maintain libraries in each language. You can of course write native C libraries with bindings to different languages but that's a bit weird.
It's also requires more discipline to maintain abstractions and boundaries properly with libraries in large code bases but that's another story.
This is a good overview of the trade-offs between service and library. Highlighting a couple more things that I didn't notice the author mentioning:
- the author questions why one cares if users are slow to upgrade your library. That depends on what your library is doing. If you really don't need a concern yourself, you're fine. If, however, your library includes a security hole that makes it possible for people to turn software consuming your library into a botnet that attacks third parties, you aren't legally liable, but it doesn't feel good to go down in history as the people who facilitated that exploit. And it's worth remembering that even PNG encoding and decoding libraries have been in this category.
- in general, a library is going to constrain my choice of language to something compilable against a stable API. and the ecosystem of compilation tools and software vending being what it is, it is still, in many ways, quite a bit easier to get functionality in front of users by running it as a service behind an HTTPS API then by releasing it as a compilable binary and trusting all of your potential audience is going to go to the hassle of gluing your bespoke make tooling to there bespoke make tooling. if you constrain the problem to a narrower ecosystem you can avoid this hassle, but then you constrained your user base to a narrower ecosystem.
Totally agree that library is easier to maintain and for developer to use. However, services are a lot easier
to monetize and allow the company to collect any data they want. I can't think of any billion dollar companies that release their core library to the users.
Libraries can also be a PITA to maintain when you need to maintain widespread platform support, including for legacy/crufy systems. I quite enjoy the freedom of owning the underlying platform with cloud deployments vs my on-prem software days.
> 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.
What really happens is that users pay money to some service provider that has said administration costs and margins for providing said library as a service. Users don't want costs related to maintaining a library or infrastructure that it needs to provide its service to them. That's why things like AWS and Azure exist.
Unless of course SaaS providers are your "users" in this case ...
1990s advice on a 1990s website. It's the opposite. We need to move away from package hell by splitting our work in two opposite directions: on the one hand, we should move back to large, effective standard libraries; on the other hand, we should move toward more services, fewer library packages. A project shouldn't need more than a few packages, usually for something like a database connection protocol. Working with libraries is the worst part of the job.
This is one of the worst ideas I've ever read on this site. But I'm glad you wrote it, as this is the epitome of a sentiment I've many times seen lurking.
- Standard libraries always go bad over time as idioms change and they don't have a policy for breaking changes
- Services do not compose as easily as libraries. Composition is key to code reuse.
I understand most off the industry deals with terrible libraries, and many of you long for simpler times, but the proliferation of complexity will occur with or without the NPMs of the world, as the industry grows and functions in a economy that doesn't care about externalities, including endemic stupid extra complexity.
I am trying to maintain an absolute pile of shite because the previous lead dev needed to reinvent every wheel in an undocumented untested way. On boarding developers takes longer. Bugs are more difficult to fix.
You are in my opinion a bad developer for having that attitude. Being able to know when and when not to use a library is an important skill. As with everything, it's a trade off and you seem to not be aware of one side.
Got it, buy the cheapest possible 600$ server, pay 200$/month to collocate it (also do a cost benefit of different facilities), be responsible for all hardware failures and availability issues.
One issue I have seen in distributed systems is where a library is on another customer/teams hosts and brings them down due to a bug in the library. The other customer/team has no way to fix the bug and is dependent on getting the attention of the company/team who vended the lib in the first place. One I remember is where a library had a bug which created 0 byte files and exhausted the inodes causing an outage.
Cloud systems have become cheap enough and flexible enough that protecting your customers by not putting your bugs on their hosts is not as big as a lift as it used to be when you had buy bare metal servers or explicit VMs.
My interpretation here is that this makes a ton more sense within an organization vs externally facing. The other comments regarding saas are on point. But the way you build your saas should - imo - take this approach whenever possible.
Good advice. I will take a modular monolith over a frontend that consumes a series of services any day. Black boxes are fun until funny things start to happen inside them.
> I don’t think it is possible to create a Python library that is not publicly available through pypi/pip, but can be installed in cloud functions
Of course it is possible. You can set up your own PEP 503 [0] compliant repository, even unreachable outside your VPC, and use pip to install from it. One caveat: on GCF you can -- if I'm not mistaken -- only install Python-only libraries; but if you use Cloud Run you can install anything inside your container.
There are servers for hosting your own PEP503 repo, such as devpi [1] -- but ultimately you only need a Web server to serve the file index.
An object in a type-safe language can contain
capabilities for resources which it uses to
implement its methods, without those capabilities
being available to the code calling those methods.
Java-style stack inspection can restrict user or
library code to deny access at runtime to
unauthorized methods.
Capability-safe architectures such as CHERI prevent
code from accessing memory that it doesn't have an
explicit capability for.
Software fault isolation can allow Multics-style
"call gates", where a library has a different
privilege level from other code.
Aside from CHERI, which requires specialized hardware, none of these actually work and none of the implementations you will find in the wild are anything but snakeoil. Just use a service, it's the only local security boundary current OSes even pretend to enforce.
>none of these actually work and none of the implementations you will find in the wild are anything but snakeoil
This is wrong. The foundation of the modern web is safe Javascript implementations. BPF/eBPF is another widespread technology using isolation mechanisms like this.
All of these techniques work. As I mentioned in the very next sentence, only the first in that list is common, but that doesn't mean the rest don't work. If you have found some fundamental hole in NaCL or CHERI or JVM security which makes them ineffective, feel free to publish your results.
I think you are talking about different things. I have absolutely decompiled obfuscated third-party Java libraries, fiddled with a few variables or method signatures, and recompiled + used them.
You're correct that obfuscation of Java libraries has nothing to do with Java stack inspection/JVM security... but the latter is what the article talks about and what is cited above, so not sure why you have just now brought up decompiling obfuscated Java libraries, which is, as you say, totally unrelated...
"Java-style stack inspection can restrict user or library code to deny access at runtime to unauthorized methods.",
which doesn't seem true to me, if the user has access to the library binaries. It's very possible for the user to just patch the library and use it however they want. It's possible (although I'm not especially convinced) that you can prevent the user from reflectively doing this at runtime, but that's not the only way to access unauthorized methods.
Yes, the OP has this backwards. The Java sandbox would allow an application to limit the access granted to a library to protect from a malicious library. It does not protect a library from being used by an application in way that was not intended by the library creator. It is certainly not a means of enforcing a licensing scheme.
Huh? NaCL is dead, and as far as I know nothing relies on the JVM sandbox for security anymore (and it was a disaster when they tried).
These also rely on wrapping the entire userspace into a sandbox, which is hardly relevant to the libraries vs. services thing. You can't inspect a stack from inside the attacker's process and expect that to do anything at all, let alone control access to a resource.
>You can't inspect a stack from inside the attacker's process and expect that to do anything at all, let alone control access to a resource.
See the article:
>If user code is running on a sufficiently advanced platform, one not administered by the user, then a library can safely manipulate resources that aren't accessible to the rest of the program. For example:
I don't hear people talk about the design side of services vs libraries enough, but I think it's a huge part of the picture.
Many people reach for services too fast because they feel more comfortable thinking about APIs through the lens of HTTP verbs and resource URLs than they do in the comparatively infinite garden of options inside a program.
The REST paradigm, despite most people not understanding, needing, or utilizing it fully, has out-competed most other software design memes. It was well-positioned to do so, with its creator being an author on the HTTP RFCs and the internet exploding in popularity and use right as the work was published.
REST (and earlier, SOAP) also had good business/network reasons to become very well known: a business who wants you to integrate with them must tell you about their integration pattern. They need to document it and motivate it. Then people have to actually write a lot of software that works that way, over and over. Exposure spreads at the speed of business, and a broad culture of REST-knowledge was inevitable, as was an industry of teaching it. Learning "REST" has long been a compulsory part of learning web-interfacing development.
By contrast, can you name a similarly restrictive organizational zeitgeist for internal program structure?
Domain Driven Design, maybe? The broad concept of "design patterns"? "OO"? None of these are anywhere near prescriptive enough to answer the classic question, "how do I organize this greenfield project from scratch?"
Maybe someone could take a restrictive set of best practices for internal API design, write a dissertation on it, give it a great name (like NICE) and then proselytize it effectively enough to gain mindshare and improve the design options available. (This seems like an interesting marketing problem as much as it is a software design one!)
As it is though, most people just don't know any other consistent, repeatable way to break a complex system down.
"REST" these days is a defacto code name for "(JSON?) calls over HTTP", with loosey-goosey adherence to anything close to what the original REST author meant.
At this point, we might as well call it RPC-style organized calls over HTTP using JSON representations and defined by "Swagger" files.
Likewise, most of SOAP was "RPC-style organized calls over HTTP (or TCP) using mostly XML serialization and defined by XSDs.
Yes I'm disillusioned with the unnecessary re-invention of the wheel here. And "REST" interfaces defined with gigantic OpenAPI documents aren't really all that better than SOAP, just with hip and still-in-development toolchains around them. It's all marketing and popularity contests, and SOAP/XML/XSD lost out.
> It's all marketing and popularity contests, and SOAP/XML/XSD lost out.
I believe the triumph of REST over SOAP was mainly piggy-backed off of the triumph of JSON over XML (even though neither has technically anything to do with REST).
In practice, in most people's minds, REST == JSON and SOAP == XML and JSON > XML. Therefore REST > SOAP.
Though as you note, what most people today call REST falls way short of the whole singing and dancing HATEOAS bag that Roy had in mind.
(Personally I think hypermedia is way overrated for most APIs, though that's not an opinion many REST zealots are open to).
It was both JSON and the "pretty" URLs, which also don't have anything specific to do with REST but people immediately associate them with it, to the point some people call them "RESTful URLs".
I think JSON is an improvement over XML for RPC, though they are similar. Generic JSON serialization/deserialization is trivial for any language with arrays and string maps. With XML, are fields serialized as attributes or as tags? Unless you are doing something really weird, JSON tells you just to use a JSON object. And for lists: do you use a special <li /> like take for the items or do you skip the intermediate step and just assume each child item is a list?
JSON is definitely not perfect and has similar problems with things like serializing maps with objects as keys, but it does have more opinionated ways for serializing things than XML does.
The main product I work on has a specification that dictates the use of SOAP/XML. So I'm probably more familiar with SOAP than REST (by which I mean JSON/HTTP). Although I don't really delve deep into the RPC code when it can be avoided.
The answer to pretty much all your questions is "depends on the schema". There are XSD (XML Schema Definition) files that you can use to define types. You can define sequences, etc.
Then you can define a WSDL (Web Services Description Language) file which describes the RPC operations, arguments, return types, etc.
After that, you can use something like gSOAP to generate C/C++ out of the WSDL and XSDs. I think Java has a lot more variety in turning a WSDL into code, but last time I looked on the Java side of things it was super confusing. None of the tools seemed to work well together. They would never shut up about beans, and there always seemed to be a bunch of tool specific annotations. Pretty disappointing, and definitely makes me lean towards REST for personal projects, if only from a KISS perspective.
My impression is that SOAP and XML could probably make a much more complex web service than REST (again, abusing the term to mean JSON/HTTP). But after having worked on a pretty confusing contract-first web service, I am kinda jaded about it.
XML guarantees that tag precedes attributes which in turn precede contents, which is a great help when any sort of polymorphism is involved. Heck, anything beyond a tree of untyped arrays, maps, and primitive values adds ugly complexity to structuring and interpreting the JSON.
IMO much of that could be fixed with a JSON derivative that allows optional type identifiers before values. While you're there, guarantee support for comments and trailing commas, because despite design ideals, humans will write JSON manually, even using JSON for configuration files that are expected to be hand-modified!
I now genuinely dislike XML. We ditched all that XML tooling around RPC over the wire and can't be happier. JSON is far better for what we do. Its faster, easier to parse, easier to store, easier to create/modify/delete. For us we even found JSON over HTTP uses less electricity.
We still use XML but its gone from RPC / everywhere to now only being a storage mechanism. I remember the network transfers dropping significantly and being very happy. Haven't looked back.
> As it is though, most people just don't know any other consistent, repeatable way to break a complex system down.
I think MVC is that. It's just vague enough that you can square-peg-round-hole almost anything into it, but it's also pretty prescriptive in that there are exactly three "components" to your program and each has a specific role and relationship to the others.
I think the flow architecture (i.e. Redux) is sufficiently descriptive for how to organize a project, at least compared to REST. There is one giant state object which is essentially a struct/trivially serializable to JSON. This state can only be changed via actions/events which are themselves only structs, not full objects. Reducer function(s) transform the old state into a new state using these events (in practice people use multiple reducer functions which are chained together).
This isn't even message passing really since you do have global state, it's just that this global state is changed via messages/events.
I have a hard disagree here. Though, I suspect it is a matter of what your code is doing.
First, my objection, though. Pushing this "to the users" is in no way easier to support. It is easier to abandon, but support is a different thing. You will have support contacts. And, due to the distributed nature of the deployment, you will have a much harder time isolating your code from the environment it is in.
With a service, it would be a lie to claim this is easier, but it is a bit more approachable.
Now, a difference, I believe, really comes in to whether or not there is state associated with what you do. If there is, and it is not something that makes sense to move close to the user, then a service is pretty much required. If there is no state, make sure that is not artificially done by just moving to all state being managed by the user.
>If one user can't have a negative impact on other users, then you don't care if some users are slow to upgrade; they're only hurting themselves.
This quote looks like it was written by someone who has never had to support users. I've had that pleasure, and, these slow to upgrade users will become the bane of your existence. You'll spend an inordinate amount of time trying to support the "If only this f*ing user would upgrade!" customer.
I don't think there's a one size fits all solution here, and there are constraints that the author isn't seeing.
In favor of a service are cases where users want plugins, and the upstream doesn't want to maintain them. An example is anything that touches DNS, like cert-manager, external-dns, things like that. There are thousands of DNS hosts, and they each have their own API. So nobody wants to provide support for all of them out of the box -- the upstream maintainer's entire life will become approving PRs for obscure DNS services. The maintainer can't test them, because they don't have an account, so can't own the quality of the final product anymore. Therefore, nobody does this. Services are an answer to this problem -- the thing you actually want to use defines an API for DNS services, and the DNS provider gives you a program that can receive messages to update DNS, and everyone is happy. You just run it as a sidecar, and you can update it when your DNS provider changes their API, and update the other thing whenever they add a new feature that you want. The coupling is loose, so you don't get the same perfect reliability as a purpose-built "update foocorp dns whenever an ingress rule adds a hostname", but it's pretty good.
(I honestly don't know if this is actually how cert-manager and external-dns work. I use cert-manager and it builds in libraries for the DNS providers I use, with the caveat that they aren't accepting any more. I don't use external-dns, but I heard some rumblings about making a standard a few years back for this sort of thing. Didn't check in on the status of either. It's just a hypothetical example ;)
Libraries are unhelpful here because there are a billion programming languages, and the upstream provider will never choose your programming language of choice as their priority. Additionally, container builds are hard and I've never heard of anyone with a reliable way of taking some sort of upstream project and building it with local add-ons at every upstream commit, tagging stable versions in parallel with the upstream, etc. Definitely possible, but out of reach of the average container operator. Things like Go without dynamic linking (a feature I agree with, BTW), and container builds make services more critical for the plugin type use case. (My dream is to just write libraries in something that compiles to WebAssembly and use that to implement a plugin system in applications that need it. Some people are kind of sort of doing this; Envoy for example.)
On the other hand, sometimes you need the deep integration that only libraries can provide. It's popular to use sidecars to add network features like distributed tracing and mTLS; linkerd and Istio are examples. But these are exactly the use cases where you should use libraries instead of services. You need to see the TLS handshake so that your application can make authorization decisions based on the peer that you're connected to. To do distributed tracing, you need to copy the X-B3-Trace-Id header out of the incoming HTTP request into the outgoing HTTP request. Libraries can do that for you, but services can't.
In summary, the answer on library or service is "it depends". Hopefully this comment adds a little more nuance than the original article.
I think context is really important here. Multiple comments in this thread jump to the concern that it is much harder to monetize a library -- but in an era where many developers are enthusiastic about service oriented architecture, it's also worth considering the decision between services and libraries for functionality which will only be exposed inside of an organization.
One other dimension not discussed in the article is how the scale of use varies over time. A service operator needs to ensure the service scales to support its use. But some use cases are extremely spiky (e.g. when something is invoked by a batch job processing many TB of data among many workers). Even if the service is able to dynamically scale based on load, that's not frictionless or without cost to the team operating the service, and can cause a degradation of service provided to other users. By contrast, if one provides a library, any given use case can be responsible for providing the capacity to support themselves.
A last dimension of libraries vs services within an organization is attributing value and cost. This is a double-edged sword. When providing a service, the team that operates the service may have some clear costs to continue to run it. Just providing the service can make you look like a cost center. If you do the extra work to make sure use cases are distinguished and trackable (e.g. use cases have separate credentials used in calling the service), then perhaps these costs (and "value" in the form of request volume) can be tied to callers. When providing a library, the team that provides it both doesn't appear as a cost center, but also it may not have a straight forward way of knowing how intensively their library is being used and therefore how much value it has provided to the org.
Services allow you to interop with all languages, they let you avoid worrying about threading models of the program your operating within, and they don't have access to all of they sandbox the code being run allowing you to avoid worrying about the code doing something nefarious with access it gets from running inside your process. On top of this, people just seem to be fat more okay with not having source access to a service than they do using proprietary libraries (which from a security perspective makes sense to me).
If there was a standard threading model, language agnostic interop with clear evolutionary properties (perhaps a channel based one), and a generic mechanism for sandboxing libraries folks could use then maybe they would consider providing libraries more. Some sort of hybrid between COM, wasm, and optimized in process grpc is more or less what I'm trying to describe. This doesn't exist, however, and moving your library out of process solves this issue neatly so it's not a surprise that's what's happening.
I don't really understand this comparison. Point of having a service is not only exposing computation - more usually, it's exposing a centralized database. How is library useful in this context? Unless, the author is talking about writing, for example, a number multiplication library vs number multiplication service... but then the advice is obvious.
EDIT: also, this stuff about accessing memoty, denying access at runtime makes me think that it was written for a different times. Nowadays, who creates new stuff that's not isolated by VM or container layer?
libraries don't make you money, services do. Libraries get your name in a license in the "open source licenses" tucked 20 menus deep in an app's hidden dev options.
328 comments
[ 3.3 ms ] story [ 62.8 ms ] threadServices, in this article, doesn't refer to things that can only be built as services (e.g. because it queries a proprietary dataset) but those that might optionally be built as services (e.g. fetching and processing otherwise accessible data) and could, as easily, be built as a library.
Basically where most devs selling commercial software live on.
https://www.bsa.org/
Copyright infringement is very rarely a crime.
The Indian state of Kerala is the most advanced, well run, and successful region of the country. On development indexes it ranks with the poorer regions of the EU. It's also largely a communist state, but once again the communists are democrats.
Of course, the site was made by a vc, so maybe it really is Monetize Everything News.
At some point, I wonder if our social and economic system becomes a close enough proxy to darwinistic survival of the fittest through capital ownership that a large enough portion of the population realize they would do better outside this construct rather than inside our societies and will begin to reject the system at large.
Right now we are able to provide stable food, housing, and ERs can't refuse people for medical care but stable housing is in the downturn and Healthcare costs that lead to bankruptcy conditions are on the rise. I feel like we're really testing how low many will go before they reject the system at hand and at what point is that number of people large enough to be critical to the existing system's stability.
At some point the effort for comfortable success may become so high people just abandon it entirely.
We have voluntarily destroyed lots of economic growth and plunged millions into extreme poverty because of a virus that is not especially bad when compared to historical pandemics.
CKEditor has multiple commercial licensing plans: https://ckeditor.com/pricing/
I worked at 2 different companies and they both quite heavily depended on RogueWave STL.
It basically allows you to share your code to others in exchange for a fee. If someone builds an app or service that uses your library, and it is paid within Fluence, you will receive a fee. This works transitively.
I worked hard on it and now I don't know how to license it.
I'm okay with non-profit OSS projects to use it freely, but I need others to pay for it. How ? How do you express such a dual license ? And how do you ensure for-profit users reward you ?
That's not the part I prefer in this project...
It's easier to draft a separate license agreement if you're the sole copyright holder.
If you're not the sole rights holder, if your project contains other GPL code, you'll need permission from the authors to license under terms other than the GPL. That would include patches from other authors, unless they sign the rights over to you.
[1]: https://www.gnu.org/licenses/gpl-faq.html#ModifyGPL
Plenty of companies will use GPL code, especially for hosted software.
It's easier if other people can make money with it.
For a real-life example of it, see this blatant bait and switch fuckery: https://github.com/dotnet/aspnetcore/issues/26489
Engineers in tech always complain that there is no proof of good work, like someone in biochemistry with a stack of papers on their CV would have. Well, this is how you do it. You spend effort sharing ideas with the community knowing you won't necessarily make a dime off of them, just like the biochem person who doesn't get paid per paper, and not spend 100% of your personal efforts working for someone else in private on a for profit project you aren't at liberty to intimately discuss.
I was not thinking of Actionscript when I wrote this comment.
> But this assumes that slow-to-upgrade users can have negative effects on everyone else.
Is the above a reference to Moxie Marlinspike's comments[1]?
So would a concrete example of your abstract essay be that communication should be a client utility that uses an XMPP library[2] instead of Signal's services?
[1] https://signal.org/blog/the-ecosystem-is-moving/
[2] https://xmpp.org/software/libraries.html
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.
Do people not sell software licenses anymore? (In theory nothing prevents you from making your license require recurring payment as well)
-certainly there are exceptions. Exceptions seem more likely with smaller older companies with different priorities.
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.
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
However:
> 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?
Another example are Automotive companies like heavy-duty vehicle parts manufacturers, which also benefit from higher Aftermarket exposure
(I thought your initial point was good, just that the argument for it wasn't as strong as it could be.)
There is another alternative universe where commercial software, including libraries, gets sold.
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.
https://en.wikipedia.org/wiki/Qt_(software)
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.
[1] https://www.jooq.org/ [2] http://hibernate.org/orm/support/
[0]: https://sidekiq.org/
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.
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.
If I want to get money (not donations) I rather target traditional corps.
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.
[0] https://signal.org/blog/the-ecosystem-is-moving/
[1] https://github.com/signalapp
[2] https://github.com/LibreSignal/LibreSignal/issues/37#issueco...
[3] my comments about it: https://news.ycombinator.com/item?id=20232499
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?
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.
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.
"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."
https://www.cnet.com/news/why-so-many-android-christian-apps...
They company owns the bible.com domain. Hobby Lobby Stores, Inc. billionaire founder/owner David Green as supported it.
https://www.forbes.com/sites/briansolomon/2012/09/18/david-g...
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.
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.
shotcut - http://www.shotcutapp.com
olive - https://github.com/olive-editor/olive
This has a built-in feature on every smartphone for years now. These apps are a scam.
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.
And other apps in the OI family. Not sure whether they've been updated for current Android versions.
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.
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.
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.
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.
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?
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.
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.
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.
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!
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.
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.
Maybe there is a clever way to work around this issue using in app purchases ...
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.
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.
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 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.
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.)
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.
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.
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.
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.
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.
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.
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.
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.
That's on you; you can easily get software to do that for free.
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.
Now everybody can and is trying to make a living off of it
But OP seems to think 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.)
I imagined this dystopian future 20 years ago, but it hasn't happened yet.
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.
Can't do that with 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.
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.
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.
The flipside of it is, X open source library existing is why a lot of STARTUPS aren't happening ;)
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.
If you need a library, and can use a library, yay, you're done, it's the simplest and fastest thing possible. If, for some reason, the logic you need can't be run locally, then you need a service. Find or build one and use it. You will pay in application complexity, dealing with the possibility that the service is down/unreachable. You will also pay in latency.
Why is this "not even wrong" article at the top of Hacker News?
I think the best of both worlds is to have an open-source library and a service. People can choose the one they prefer. And you can still make money from selling the service.
You're agreeing with the article, and seem to be suggesting that your agreement represents a universal viewpoint, but it does not seem to.
It is quite sensible. I'm a believer in SDKs. An SDK abstracts the backend. Gives everybody a lot more control over their own domain.
Of course, the requirement, is that the SDK needs to be super-high quality. It also needs to expose a fairly generic API that may not actually map directly to the service it abstracts/replaces.
That being said it's incredibly hard to follow this advice in environments which encourage a polyglot stack and 'the best tool for the job' mindset. The moment you have more than one language in your stack it becomes easier to build services than to maintain libraries in each language. You can of course write native C libraries with bindings to different languages but that's a bit weird.
It's also requires more discipline to maintain abstractions and boundaries properly with libraries in large code bases but that's another story.
It also doesn't have to be C, just anything that compiles to a native binary lib.
.NET also -- and this is only my interpretation -- is following that path.
- the author questions why one cares if users are slow to upgrade your library. That depends on what your library is doing. If you really don't need a concern yourself, you're fine. If, however, your library includes a security hole that makes it possible for people to turn software consuming your library into a botnet that attacks third parties, you aren't legally liable, but it doesn't feel good to go down in history as the people who facilitated that exploit. And it's worth remembering that even PNG encoding and decoding libraries have been in this category.
- in general, a library is going to constrain my choice of language to something compilable against a stable API. and the ecosystem of compilation tools and software vending being what it is, it is still, in many ways, quite a bit easier to get functionality in front of users by running it as a service behind an HTTPS API then by releasing it as a compilable binary and trusting all of your potential audience is going to go to the hassle of gluing your bespoke make tooling to there bespoke make tooling. if you constrain the problem to a narrower ecosystem you can avoid this hassle, but then you constrained your user base to a narrower ecosystem.
What really happens is that users pay money to some service provider that has said administration costs and margins for providing said library as a service. Users don't want costs related to maintaining a library or infrastructure that it needs to provide its service to them. That's why things like AWS and Azure exist.
Unless of course SaaS providers are your "users" in this case ...
- Standard libraries always go bad over time as idioms change and they don't have a policy for breaking changes
- Services do not compose as easily as libraries. Composition is key to code reuse.
I understand most off the industry deals with terrible libraries, and many of you long for simpler times, but the proliferation of complexity will occur with or without the NPMs of the world, as the industry grows and functions in a economy that doesn't care about externalities, including endemic stupid extra complexity.
You are in my opinion a bad developer for having that attitude. Being able to know when and when not to use a library is an important skill. As with everything, it's a trade off and you seem to not be aware of one side.
Cloud systems have become cheap enough and flexible enough that protecting your customers by not putting your bugs on their hosts is not as big as a lift as it used to be when you had buy bare metal servers or explicit VMs.
Surely $600 dollar servers all cost the same
However, practically speaking:
- I don’t think it is possible to create a Python library that is not publicly available through pypi/pip, but can be installed in cloud functions
- if the library is a service, I only need to update one service to add a new function or fix a bug
- a service can be called by other non Python services.
With that being said it is much, much easier writing code that import a library than call out to a service. And it is also much, much easier to test.
We use packagecloud.io and inject the relevant token to access our private repo at CI/CD time.
Of course it is possible. You can set up your own PEP 503 [0] compliant repository, even unreachable outside your VPC, and use pip to install from it. One caveat: on GCF you can -- if I'm not mistaken -- only install Python-only libraries; but if you use Cloud Run you can install anything inside your container.
There are servers for hosting your own PEP503 repo, such as devpi [1] -- but ultimately you only need a Web server to serve the file index.
[0] https://www.python.org/dev/peps/pep-0503/
[1] https://www.devpi.net/
But yes, they require the user of your library to cooperate.
This is wrong. The foundation of the modern web is safe Javascript implementations. BPF/eBPF is another widespread technology using isolation mechanisms like this.
All of these techniques work. As I mentioned in the very next sentence, only the first in that list is common, but that doesn't mean the rest don't work. If you have found some fundamental hole in NaCL or CHERI or JVM security which makes them ineffective, feel free to publish your results.
JVM security has nothing to do with this.
"Java-style stack inspection can restrict user or library code to deny access at runtime to unauthorized methods.",
which doesn't seem true to me, if the user has access to the library binaries. It's very possible for the user to just patch the library and use it however they want. It's possible (although I'm not especially convinced) that you can prevent the user from reflectively doing this at runtime, but that's not the only way to access unauthorized methods.
Could you explain what gave you the impression that this was about licensing schemes? That was definitely not my intention.
These also rely on wrapping the entire userspace into a sandbox, which is hardly relevant to the libraries vs. services thing. You can't inspect a stack from inside the attacker's process and expect that to do anything at all, let alone control access to a resource.
See the article:
>If user code is running on a sufficiently advanced platform, one not administered by the user, then a library can safely manipulate resources that aren't accessible to the rest of the program. For example:
>[the list quoted above]
Many people reach for services too fast because they feel more comfortable thinking about APIs through the lens of HTTP verbs and resource URLs than they do in the comparatively infinite garden of options inside a program.
The REST paradigm, despite most people not understanding, needing, or utilizing it fully, has out-competed most other software design memes. It was well-positioned to do so, with its creator being an author on the HTTP RFCs and the internet exploding in popularity and use right as the work was published.
REST (and earlier, SOAP) also had good business/network reasons to become very well known: a business who wants you to integrate with them must tell you about their integration pattern. They need to document it and motivate it. Then people have to actually write a lot of software that works that way, over and over. Exposure spreads at the speed of business, and a broad culture of REST-knowledge was inevitable, as was an industry of teaching it. Learning "REST" has long been a compulsory part of learning web-interfacing development.
By contrast, can you name a similarly restrictive organizational zeitgeist for internal program structure?
Domain Driven Design, maybe? The broad concept of "design patterns"? "OO"? None of these are anywhere near prescriptive enough to answer the classic question, "how do I organize this greenfield project from scratch?"
Maybe someone could take a restrictive set of best practices for internal API design, write a dissertation on it, give it a great name (like NICE) and then proselytize it effectively enough to gain mindshare and improve the design options available. (This seems like an interesting marketing problem as much as it is a software design one!)
As it is though, most people just don't know any other consistent, repeatable way to break a complex system down.
At this point, we might as well call it RPC-style organized calls over HTTP using JSON representations and defined by "Swagger" files.
Likewise, most of SOAP was "RPC-style organized calls over HTTP (or TCP) using mostly XML serialization and defined by XSDs.
Yes I'm disillusioned with the unnecessary re-invention of the wheel here. And "REST" interfaces defined with gigantic OpenAPI documents aren't really all that better than SOAP, just with hip and still-in-development toolchains around them. It's all marketing and popularity contests, and SOAP/XML/XSD lost out.
I believe the triumph of REST over SOAP was mainly piggy-backed off of the triumph of JSON over XML (even though neither has technically anything to do with REST).
In practice, in most people's minds, REST == JSON and SOAP == XML and JSON > XML. Therefore REST > SOAP.
Though as you note, what most people today call REST falls way short of the whole singing and dancing HATEOAS bag that Roy had in mind.
(Personally I think hypermedia is way overrated for most APIs, though that's not an opinion many REST zealots are open to).
JSON is definitely not perfect and has similar problems with things like serializing maps with objects as keys, but it does have more opinionated ways for serializing things than XML does.
The answer to pretty much all your questions is "depends on the schema". There are XSD (XML Schema Definition) files that you can use to define types. You can define sequences, etc.
Then you can define a WSDL (Web Services Description Language) file which describes the RPC operations, arguments, return types, etc.
After that, you can use something like gSOAP to generate C/C++ out of the WSDL and XSDs. I think Java has a lot more variety in turning a WSDL into code, but last time I looked on the Java side of things it was super confusing. None of the tools seemed to work well together. They would never shut up about beans, and there always seemed to be a bunch of tool specific annotations. Pretty disappointing, and definitely makes me lean towards REST for personal projects, if only from a KISS perspective.
My impression is that SOAP and XML could probably make a much more complex web service than REST (again, abusing the term to mean JSON/HTTP). But after having worked on a pretty confusing contract-first web service, I am kinda jaded about it.
IMO much of that could be fixed with a JSON derivative that allows optional type identifiers before values. While you're there, guarantee support for comments and trailing commas, because despite design ideals, humans will write JSON manually, even using JSON for configuration files that are expected to be hand-modified!
We still use XML but its gone from RPC / everywhere to now only being a storage mechanism. I remember the network transfers dropping significantly and being very happy. Haven't looked back.
I think MVC is that. It's just vague enough that you can square-peg-round-hole almost anything into it, but it's also pretty prescriptive in that there are exactly three "components" to your program and each has a specific role and relationship to the others.
This isn't even message passing really since you do have global state, it's just that this global state is changed via messages/events.
First, my objection, though. Pushing this "to the users" is in no way easier to support. It is easier to abandon, but support is a different thing. You will have support contacts. And, due to the distributed nature of the deployment, you will have a much harder time isolating your code from the environment it is in.
With a service, it would be a lie to claim this is easier, but it is a bit more approachable.
Now, a difference, I believe, really comes in to whether or not there is state associated with what you do. If there is, and it is not something that makes sense to move close to the user, then a service is pretty much required. If there is no state, make sure that is not artificially done by just moving to all state being managed by the user.
https://www.youtube.com/watch?v=J7E-aoXLZGY
This quote looks like it was written by someone who has never had to support users. I've had that pleasure, and, these slow to upgrade users will become the bane of your existence. You'll spend an inordinate amount of time trying to support the "If only this f*ing user would upgrade!" customer.
In favor of a service are cases where users want plugins, and the upstream doesn't want to maintain them. An example is anything that touches DNS, like cert-manager, external-dns, things like that. There are thousands of DNS hosts, and they each have their own API. So nobody wants to provide support for all of them out of the box -- the upstream maintainer's entire life will become approving PRs for obscure DNS services. The maintainer can't test them, because they don't have an account, so can't own the quality of the final product anymore. Therefore, nobody does this. Services are an answer to this problem -- the thing you actually want to use defines an API for DNS services, and the DNS provider gives you a program that can receive messages to update DNS, and everyone is happy. You just run it as a sidecar, and you can update it when your DNS provider changes their API, and update the other thing whenever they add a new feature that you want. The coupling is loose, so you don't get the same perfect reliability as a purpose-built "update foocorp dns whenever an ingress rule adds a hostname", but it's pretty good.
(I honestly don't know if this is actually how cert-manager and external-dns work. I use cert-manager and it builds in libraries for the DNS providers I use, with the caveat that they aren't accepting any more. I don't use external-dns, but I heard some rumblings about making a standard a few years back for this sort of thing. Didn't check in on the status of either. It's just a hypothetical example ;)
Libraries are unhelpful here because there are a billion programming languages, and the upstream provider will never choose your programming language of choice as their priority. Additionally, container builds are hard and I've never heard of anyone with a reliable way of taking some sort of upstream project and building it with local add-ons at every upstream commit, tagging stable versions in parallel with the upstream, etc. Definitely possible, but out of reach of the average container operator. Things like Go without dynamic linking (a feature I agree with, BTW), and container builds make services more critical for the plugin type use case. (My dream is to just write libraries in something that compiles to WebAssembly and use that to implement a plugin system in applications that need it. Some people are kind of sort of doing this; Envoy for example.)
On the other hand, sometimes you need the deep integration that only libraries can provide. It's popular to use sidecars to add network features like distributed tracing and mTLS; linkerd and Istio are examples. But these are exactly the use cases where you should use libraries instead of services. You need to see the TLS handshake so that your application can make authorization decisions based on the peer that you're connected to. To do distributed tracing, you need to copy the X-B3-Trace-Id header out of the incoming HTTP request into the outgoing HTTP request. Libraries can do that for you, but services can't.
In summary, the answer on library or service is "it depends". Hopefully this comment adds a little more nuance than the original article.
One other dimension not discussed in the article is how the scale of use varies over time. A service operator needs to ensure the service scales to support its use. But some use cases are extremely spiky (e.g. when something is invoked by a batch job processing many TB of data among many workers). Even if the service is able to dynamically scale based on load, that's not frictionless or without cost to the team operating the service, and can cause a degradation of service provided to other users. By contrast, if one provides a library, any given use case can be responsible for providing the capacity to support themselves.
A last dimension of libraries vs services within an organization is attributing value and cost. This is a double-edged sword. When providing a service, the team that operates the service may have some clear costs to continue to run it. Just providing the service can make you look like a cost center. If you do the extra work to make sure use cases are distinguished and trackable (e.g. use cases have separate credentials used in calling the service), then perhaps these costs (and "value" in the form of request volume) can be tied to callers. When providing a library, the team that provides it both doesn't appear as a cost center, but also it may not have a straight forward way of knowing how intensively their library is being used and therefore how much value it has provided to the org.
If there was a standard threading model, language agnostic interop with clear evolutionary properties (perhaps a channel based one), and a generic mechanism for sandboxing libraries folks could use then maybe they would consider providing libraries more. Some sort of hybrid between COM, wasm, and optimized in process grpc is more or less what I'm trying to describe. This doesn't exist, however, and moving your library out of process solves this issue neatly so it's not a surprise that's what's happening.
EDIT: also, this stuff about accessing memoty, denying access at runtime makes me think that it was written for a different times. Nowadays, who creates new stuff that's not isolated by VM or container layer?