4 ms·

I am the ultimate smart tech man at my company. Warned them about Jira. Warned them about M$/Sharepoint/Power Automate. Jira and New M$ services are at bait

I am the ultimate smart tech man at my company. Warned them about Jira. Warned them about M$/Sharepoint/Power Automate. Jira and New M$ services are at bait pricing. They will all be extortionary levels at some point. Kind of amazes me people are paying for inferior closed off services, but I imagine the people making the purchasing decisions are more concerned about which concert or sports game the sales person is taking them to.

AlexandrB 3y ago
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.
s0l1dsnak3123 3y ago
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.
world2vec 3y ago
What would you recommend as Power Automate replacement?
- osullip 3y ago
  What do you want to do? There is: Zapier Make IFTTT Integrately Etc etc A ton of automation tools out there.
- hospitalJail 3y ago
  Python. I'm pretty uncompromising about that. Maybe autohotkey in addition.
MilStdJunkie 3y ago
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.
- bagasme 3y ago
  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).
- dsr_ 3y ago
  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.
asoneth 3y ago
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.
- criley2 3y ago
  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!
  - regularfry 3y ago
    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.
  - hotnfresh 3y ago
    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.
    - 3y ago
freitzkriesler2 3y ago
The thing that drives me nuts about jira is its gated features 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

AlexandrB 3y ago

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.

s0l1dsnak3123 3y ago

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.

world2vec 3y ago

What would you recommend as Power Automate replacement?

osullip 3y ago
What do you want to do? There is: Zapier Make IFTTT Integrately Etc etc A ton of automation tools out there.
hospitalJail 3y ago
Python. I'm pretty uncompromising about that. Maybe autohotkey in addition.

MilStdJunkie 3y ago

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.

bagasme 3y ago
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).
dsr_ 3y ago
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.

asoneth 3y ago

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.

criley2 3y ago
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!
- regularfry 3y ago
  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.
- hotnfresh 3y ago
  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.
  - 3y ago

freitzkriesler2 3y ago

The thing that drives me nuts about jira is its gated features 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