Live data from Hacker News

Write libraries instead of services, where possible

catern.com

231–240 of 328 posts

Re: Write libraries instead of services, where possible

#231

> 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 y…

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.

Can't do that with a library.

Re: Write libraries instead of services, where possible

#232
post #200

Earlier quoted context omitted.

It’s not hard to find a T-shirt I can wear over and over again without having to keep paying for it. Nowadays it’s nearly impossible to find software that lets you pay once at a reasonable price. So yeah, it is very frustrating to fight off subscriptions.

I think the problem is that people are overestimating the benefits of subscriptions. Yes, subscriptions make recurring revenue. But so does pay-once software, as long as you don't stop getting new users. But your SaaS subscribers also churn, so you can't stop getting new customers there either. Pay-once has the huge advantage that the barrier to entry is much lower. I'm pretty sure that it's much easier to sell a 50€…

>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.

Re: Write libraries instead of services, where possible

#233
post #131

Earlier quoted context omitted.

> 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 b…

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 "fight…

> 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 Cancel 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.

Re: Write libraries instead of services, where possible

#234
post #200

Earlier quoted context omitted.

It’s not hard to find a T-shirt I can wear over and over again without having to keep paying for it. Nowadays it’s nearly impossible to find software that lets you pay once at a reasonable price. So yeah, it is very frustrating to fight off subscriptions.

I think the problem is that people are overestimating the benefits of subscriptions. Yes, subscriptions make recurring revenue. But so does pay-once software, as long as you don't stop getting new users. But your SaaS subscribers also churn, so you can't stop getting new customers there either. Pay-once has the huge advantage that the barrier to entry is much lower. I'm pretty sure that it's much easier to sell a 50€…

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.

Re: Write libraries instead of services, where possible

#235
post #95

Earlier quoted context omitted.

A good one, yet go check the crowd with pitchforks and torches heading to Qt castle.

For the ones missing the context: 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 Q…

5.15, not 5.7, but everything else you say is true

Re: Write libraries instead of services, where possible

#236
post #93

Earlier quoted context omitted.

>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 d…

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:

>[the list quoted above]

Re: Write libraries instead of services, where possible

#237
post #200

Earlier quoted context omitted.

It’s not hard to find a T-shirt I can wear over and over again without having to keep paying for it. Nowadays it’s nearly impossible to find software that lets you pay once at a reasonable price. So yeah, it is very frustrating to fight off subscriptions.

I think the problem is that people are overestimating the benefits of subscriptions. Yes, subscriptions make recurring revenue. But so does pay-once software, as long as you don't stop getting new users. But your SaaS subscribers also churn, so you can't stop getting new customers there either. Pay-once has the huge advantage that the barrier to entry is much lower. I'm pretty sure that it's much easier to sell a 50€…

> 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.

Re: Write libraries instead of services, where possible

#238

Earlier quoted context omitted.

What it says is "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 runti…

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.

>It is certainly not a means of enforcing a licensing scheme.

Could you explain what gave you the impression that this was about licensing schemes? That was definitely not my intention.

Re: Write libraries instead of services, where possible

#239

Phoenix is practically built with this idea in mind. My startup is built out of a single phoenix monolith. Only external dependency is postgres. Despite this, I've managed to completely avoid all the typical scaling issues of a monolith. Need a service or background worker? I juts make a Genserver or Oban worker and mount it in the supervision tree. The Beam takes care of maintaining the process, pubsub to said servi…

Anyone like me first hearing about Phoenix and had trouble finding it, it's an Elixir framework: https://www.phoenixframework.org/

Yeah, my first thought was "If this is called Phoenix and it's Cloud-related, I'm gonna have to swim through a lot of FFVII results before I find it".

Re: Write libraries instead of services, where possible

#240
post #44

Earlier quoted context omitted.

Only on the FOSS world, because it is the only way to force devs to pay. There is another alternative universe where commercial software, including libraries, gets sold.

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) b…

Because a large majority of those developers feels entitled to get everything for free.

If I want to get money (not donations) I rather target traditional corps.

Post reply on HN