by pistoriusp on 6/6/25, 6:10 PM with 135 comments
by lokimedes on 6/6/25, 7:27 PM
Let us buy our software, and separately, offer us a service agreement that actually has to provide value in its own right. The bundling of these in SaaS is what makes this obscene.
by citizenpaul on 6/6/25, 8:36 PM
Which means in 10 years they will really be locked in because no one is going to un-entrench that thing.
by bob1029 on 6/7/25, 5:19 PM
In a prior role, I was responsible for figuring out the best way to deliver a docusign-style experience that integrated with our product. After having conversations with two of the biggest vendors (DocuSign/Adobe), we decided the constraints of their APIs were causing too much friction with how our product/customer wanted things to work. We went with a fully in-house solution.
In most situations, trying to reinvent something like DocuSign is a terrible idea. In this case especially so since often you are using it simply because it is trusted (not because it is technically superior). In our case, the product was already installed and deeply trusted by the customers. They would have gone along with DocuSign, but they also had no problem with us doing it first-party.
Ultimately, it was a lot of up front work to get this implemented, but the customer absolutely loves it. We had to make some minor tweaks to how it functioned and that really highlighted why this was a good path. If we had gone with DocuSign, Adobe, et. al., that minor tweak would have turned into a major refactor and hack around shitshow.
by 0xbadcafebee on 6/6/25, 7:21 PM
No matter what choice you make, it's always going to be vendor-locked in.
Switching out something, even if it's open source and self-hosted,
means that you're rewriting a lot of code.
That's not what lock-in means. Just having a vendor-specific component or integration, is not the same thing as being locked-in to a vendor or integration.Locked-in means that switching it out for something else is either A) impossible, or B) would require an investment greater than just sticking with the existing thing.
When you write software in a loosely-coupled, highly-cohesive way, the intersection between different components is designed to not take much work to replace one component or another. The same is true of systems. If the interfaces of those components are simple, and their use is cohesive, it should not be difficult to replace a part. However, if your components are not cohesive, then it will be a huge pain in the ass to replace anything.
So, no, it's not a good idea to choose a platform because "everything is lock-in, so fuck it, i'll lock myself in even more!" As a developer, I can see the appeal, as it means less work for you. But as a business owner, this is a stupid reason to choose a solution. Choose solutions that will support the business and give it flexibility to change over time.
by solatic on 6/6/25, 8:34 PM
Which is... not really controversial. Fewer vendors makes your life easier. Fewer dependencies makes your life easier. It would be awesome if you could build your entire product based on the standard library alone! Sadly... that's not really realistic. Nice pipe-dream though.
by AstroBen on 6/6/25, 7:41 PM
by abelanger on 6/6/25, 9:00 PM
> Switching out something, even if it's open source and self-hosted, means that you're rewriting a lot of code.
The point of something open-source and self-hosted is that it resolves nearly all of the "taxes" mentioned in the article. What the article refers to as the discovery, sign-up, integration, and local development tax are all easily solved by a good open-source local development story.
The "production tax" (is tax the right word?) can be resolved by contributions or a good plugin/module ecosystem.
by jgord on 6/7/25, 4:39 AM
Likewise .. if you can get your data in a standard format and walk away, you are not locked-in.
Customers tend to feel less aggrieved when they have access to their data - too many SaaS platforms dont allow this.
by sophiabannet1 on 6/19/25, 6:32 AM
by foundart on 6/7/25, 5:53 AM
The problem is, you'd be foolish to run your own thing in the early days of a company. It's only when you've succeeded and scaled that it becomes a problem. You survived long enough to need to scale in part by keeping costs low and one way you did that was by using SaaS services instead of building and/or running versions of those tools yourself. That was smart.
As the business grew at least one or two of those SaaS services got so entwined into the daily operations of your company that there is now no way to replace them without a lengthy, risky, and expensive migration project.
The SaaS problem is a negative side effect of your success.
edited - a typo and a word change
by missedthecue on 6/6/25, 7:14 PM
by paxys on 6/6/25, 8:49 PM
by gavmor on 6/6/25, 6:59 PM
by canadiantim on 6/6/25, 6:56 PM
by davidpaulyoung on 6/6/25, 7:32 PM
by antithesizer on 6/6/25, 9:33 PM
by nitwit005 on 6/6/25, 9:00 PM
Because that's the incentive, particularly with products that are naturally fading and ceasing to make new sales.
by pjmlp on 6/7/25, 5:56 AM
Who doesn't like it, should promote that upstream gets more than bug reports and push requests, as means to pay their bills.
by dasil003 on 6/6/25, 6:47 PM
by klysm on 6/7/25, 12:27 AM
by exiguus on 6/6/25, 8:11 PM
by atoav on 6/7/25, 8:35 AM
As a former freelancer most of the software I still pay for has a model in the form of: Pay 350 € once, get 2 years of updates and use it as long as you like. If you want new updates after you get a reduced price of 120 € for an extension period.
This is my favourite license model for commercial software since it gives me maximum planability of my expenses and it gives the software company an incentives to add substentially useful features with new updates instead of just collecting rent.
by turnsout on 6/6/25, 11:51 PM