This is more or less my life as well.

The "finisher argument" that gets rolled out is "product lifetime costs". It goes like this.

Open Source Product A will always be your responsibility, which will take X hours off the team's time forever. Vendor Product B will be maintained from the vendor side, thus removing that wildcard of X. Ergo, over the "lifetime" of the product, B will have lower costs than A.

Since this argument has dollars in it, it always wins, and everyone makes smug faces.

I personally think it's almost completely ridiculous to evaluate software with anything called "lifetime costs", and honestly, it's getting pretty close to ridiculous to cite that metric for any complex system, physical or not. But that's just me[1].

I'd be interested to hear what the general readership's opinion is on whether or not the "Lifetime Costs" argument holds water, and why.

[1] In the software case, what's a "Product" "Lifetime"? Is that "the software in its current precise configuration", because then we're talking a lifetime of picoseconds. Or is Product defined so broadly that virtually any software of that class can be called "the Product", in which case you're stretching my credulity to say you're capable of supporting this notion of "Product" for N arbitrary period. I don't think you will make any money doing that. Either way . . when it comes to "lifetime costs" for physical complex systems, there's a supplementary argument, out of scope for this discussion, but still applicable in heavy industry.

But what if that vendor product B got crippled (like recently Unity and today JIRA) for most of features that people deemed essential, or even vanished? People who is less fortunate has to switch to more cost-effective solutions (it may include F(L)OSS ones).

Open Source project O will cost your team X hours of time to develop expertise in managing it.

Enterprise product E will cost your team X hours of time to develop expertise.

O requires install time. E either requires install time or integration time.

When O breaks, it is likely that the community has already seen this problem and can provide suggestions via docs, mailing list archives, discussion fora, blogs... Your team's expertise will increase. If your problem is interesting, the developers will likely get involved.

When E breaks, you will open a ticket. Within 24 hours, someone from the E company will try to diagnose your problem, going down a flowchart that they will not share with you. If your problem is in the FAQ or flowchart, it will get solved within a week, probably. If your problem is interesting, it may eventually be solved in a future release. Your team will spend less time working on it, but E will be broken for longer.

You will pay dollars to your team to support O, which will make them happier.

You will pay dollars to the E company to support E, which will make them happier.

E will invite your execs to dinner at the E conference.

O will never invite anyone to anything.

This is the secret.

E will also conduct award ceremonies and invite the suits - "Best Practices Journey Award 2023".

O will have a virtual hackathon broadcast on their self-hosted Jitsi.

You forgot the cost of Y hours your developers could have spent on A.

This is the actual, non-cynical driver for many of these decisions. An exec is looking at devoting developer time to building or curating software that isn't part of the core competency of the business, and balancing it against staffing product development or IT aimed at the business's specialization.

To make avoidance of E palatable, you have to show that use of O will not only cost significantly less that E, but that using it will also make up for the lost time that you would have spent building A.

I say this as someone who constantly has to justify why we don't just grab some SaaS offering off the shelf and groom it * cough * um... integrate it, rather than continuing investment in the purpose-built "commodity" my team runs.

I actually agree with the "lifetime" argument. The real fallacy is here:

> Vendor Product B will be maintained from the vendor side, thus removing that wildcard of X.

Product B also has a lifetime cost as you'll be paying monthly for the subscription.

Also no product is maintenance free, even as you pay for it. Products evolve, you also do, next months JIRA could break some of a company's use cases and they'll have to deal with it. The vendor might be helpful and guide thsm through the process, but that's still work.

A good example of that is Microsoft's enterprise offering: it's a paid product and you still need a department to manage it day to day.

I dig it. And yeah, B has license costs, but those often go to a different cost center so they're invisible[1] . . and as we all know invisible things don't exist.

We'll agree to disagree that "lifetimes" are a real thing in software - I actually think this is a pretty fluid thing - but I'm going to extend your case here to illustrate how "lifetime" interacts with incomputable costs. We have the known license costs, as stated above, but then added to that we also have this unknown cost that represents "how much time my team needs to spend maintaining the vendor product". That cost is unquantifiable but it's going to go up the less tightly-defined the product is[2], and, as stated, there is an inverse relationship between "lifetime" and "tightly defined".

So you're in a situation where the lifetime is either very short, or the vendor costs are high. But you never know "how much my people will need to do at the very base level of vendor support" so the multiplier can take it way outside of the range of "acceptable" very, very rapidly, with just a small increase in scope/lifetime. You end up paying out more for the vendor support than you're making from the Product, thus operating the whole shebang at a loss.

I think this is much more of a problem when in a domain that's not commodified, or even worse, something that's extremely niche. I'm thinking of SGML and FOSI publishing systems, specifically, but it could go for anything way out on the fringes, like weirdo material-assembly-or-org-specific CAD functions. I'm going to go out on a limb here and say if your business depends on niche, you're really way, way, way better off in-housing that, then interfacing it with the commodified functions that can run off the vendor. There's no ceiling on how high the vendor costs can go with niche stuff.

[1] Please don't get me started on cost centers.

[2] For a given cost, Product grows in scope, less profitable for the vendor to staff for supporting it, support goes down.

A slightly less cynical take is that "nobody got fired for choosing Jira/Microsoft/IBM". It's easier to justify choosing a market leader, even if things go badly later, than going against the grain.

I think you are correct precisely because this is how rentier economics seems to work out in every sector - just look at the housing market. Any captive audience that gives up agency to a third party in exchange for a subscription is ultimately beholden to the whims of that third party. It's an inherently risky proposition.

What would you recommend as Power Automate replacement?

What do you want to do? There is: Zapier Make IFTTT Integrately Etc etc

A ton of automation tools out there.

Python.

I'm pretty uncompromising about that.

Maybe autohotkey in addition.

In my experience at mid-sized companies the decision is usually made by the development teams themselves who have a choice along a spectrum between a proprietary SAAS solution that may end up costing the company unpredictable amounts of money in the future on one end and a self-hosted open source solution that we have to trust the IT/devops folks to maintain competently on the other.

Also in my experience, the companies that were the most cost sensitive with regard to paying for dev tooling were also the ones with the weakest IT/devops support so you either end up with two good options or two bad options.

The cold hard math that engineers never want to do is the one involving their own salary.

On levels.fyi devops is median $150k in the US, and at that price it means they cost the company a lot more including benefits, taxes, etc.

If a "crappy" tool costs $10k/mo for the team and doesn't require much or any devops time to setup and maintain, it's likely cheaper than the $0/mo opensource but requires part or full time management option.

No one ever wants to budget their own cost into the equation!

The same argument applies to the users of the software though, and seeing that played out is even more rare.

If I can run a $0 tool that saves 100 people half an hour a month each because the workflow is better, that's $4k in the "pro" column right there. I should be able to justify spending a day a week on just that one product.

What’s left out is accounting of the time the paid tool wastes. Ten seconds here, a minute there, two seconds another place. If the open source solution is in fact the more productive tool (nb it might not be) then $20,000 in dev time to babysit open source might be cheaper than the $10,000 paid tool—because that tool is wasting more than $10,000 in productivity, it’s just harder to see.

The buyer often doesn't use the product so he has no sense of the value it provides, or the pain of using substandard tools. Unless it's his own company he might not care that much either.

It's not about the cost, it's about the value, unless the products are perfect substitutes, like nuts and bolts. Software products will always differentiate themselves so you can't fairly compare them just on price.

> If a "crappy" tool costs $10k/mo for the team and doesn't require much or any devops time to setup and maintain, it's likely cheaper than the $0/mo opensource but requires part or full time management option.

This is a total fantasy. There is no reason to expect the crappy enterprise tool that costs money will save time relative to the open source tool. In my experience enterprise tools takes more time and average and cost money. This line of reasoning (frequently pushed by dishonest sales people) is seductive because it tricks you into ignore the time cost of dealing with enterprise, not because it is correct.

I think you must be in some terrible giant corporate entity where everything sucks all the time.

I bet you that what I told you about this cost/benefit is being done in every startup that YCombinator funds. I bet you they are all choosing product over staff, because their engineering staff is already their ~largest expense. Their engineers might even cost more than the rest of the company combined including executives.

How many companies are choosing SaaS/PaaS/alltheS so their lean team of engineers can scale to millions, instead of hiring a whole team to manage AWS and docker or whatever ops strategy they have.

You might think it's a total fantasy and in the places you work it may be, but I've been in countless meetings with countless executives where the Google Sheet is busted out featuring engineering cost and tool cost and where cost/benefit is aggressively decided.

Spoiler: it's almost always cheaper to use the tool

> I've been in countless meetings with countless executives where the Google Sheet is busted out featuring engineering cost and tool cost and where cost/benefit is aggressively decided.

That is the problem though. It isn't the engineering cost vs the tool cost. It is the engineering cost vs the tool cost PLUS the engineering cost of dealing with the tool once you buy it. Everything you have said so far leads me to believe you are missing this aspect of the cost of buying the tool.

You are right that there is a time and a place for buying over DIY, but in order to make those decisions reliably you need to know how much effort is going to go into dealing with the tool once you buy it. This isn't something you can figure out using Google sheets, because you have to actually evaluate the tool and get a sense of how dangerous the foot guns are.

You're probably right about scaling though. That sounds like an area where the ROI of paying someone else to do it is pretty good.

The thing that drives me nuts about jira is gated its features are and forced way of working. I should be able to turn on the initiative planning and work dashboard for a single project.

Case in point, I spent hours creating fancy new ticket tiers and guess what? They don't appear on the initiative planner because it goes outside what atlassian wants.

I've written this to them but they don't see the point in making an adaptable ticketing system. It is what it is