4 ms·

As with many situations with enterprise software vs. roll-your-own solutions (FOSS or otherwise): reliability, responsibility, and liability are the reasons. M

As with many situations with enterprise software vs. roll-your-own solutions (FOSS or otherwise): reliability, responsibility, and liability are the reasons. Most enterprise software is purchased to do something the company requires, but is not within the company's actual line of business. Payroll, tax calculations, identity verification, etc. In these cases "cheap" is not very important so long as the solutions are cheap enough relative to the value of what the company's business. This is also why companies routinely contract out vast amounts of work to highly-paid lawyers - paying someone six figures to do work on a deal that's worth 9 figures is a rounding error, and is not a cost worth optimizing. More importantly, the third party provides two important pieces: responsibility and liability. Docusign is on the hook if they fail to validate the signers' identity, and if anything goes awry Docusign is on the hook for fixing it. These are features, not bugs, to enterprises who need a function performed but really do not want the liability or responsibility around it. This is similar to why tech companies outsource to cloud services rather than run on their own metal.

ineedasername 5y ago
>and is not a cost worth optimizing. Well, it's kind of like plumbing. Once established, you don't think about it much until something goes wrong. Maybe someone notices, "Hey, our annual maintenance is $x, but I think the normal rate is only $x-y." But unless it's time for a lot of belt tightening, making that change is pure risk if the system mostly works, problems are fixed quickly, etc. Because maybe you change plumbers, and there's a catastrophic failure that would have happened anyway, but now via the magic of post-hoc fallacies it looks like the change is what caused the problem. (And maybe it did! who knows?) So there are many things in any organization that only get optimized/updated (or even just simple maintenance) when they become a noticeable problem. The old adage about not fixing what isn't broken-- you need to really be able to show a likely failure in order to make a preemptive change.
- ineedasername 5y ago
  As a side note, this can be a good thing. When a certain amount of change aversion isn't maintained, you get change for change's sake. Organizationally, you get every new manager trying to "make their mark" on things. Individually, you get developers trying to add "migrated product to $X shiny new framework" to their resume for their next job hop in 2-3 years. But many/most of us have probably also worked in environments that were far too conservative about changes, so that may be the more common problem.

ineedasername 5y ago

>and is not a cost worth optimizing. Well, it's kind of like plumbing. Once established, you don't think about it much until something goes wrong. Maybe someone notices, "Hey, our annual maintenance is $x, but I think the normal rate is only $x-y." But unless it's time for a lot of belt tightening, making that change is pure risk if the system mostly works, problems are fixed quickly, etc. Because maybe you change plumbers, and there's a catastrophic failure that would have happened anyway, but now via the magic of post-hoc fallacies it looks like the change is what caused the problem. (And maybe it did! who knows?) So there are many things in any organization that only get optimized/updated (or even just simple maintenance) when they become a noticeable problem. The old adage about not fixing what isn't broken-- you need to really be able to show a likely failure in order to make a preemptive change.

ineedasername 5y ago
As a side note, this can be a good thing. When a certain amount of change aversion isn't maintained, you get change for change's sake. Organizationally, you get every new manager trying to "make their mark" on things. Individually, you get developers trying to add "migrated product to $X shiny new framework" to their resume for their next job hop in 2-3 years. But many/most of us have probably also worked in environments that were far too conservative about changes, so that may be the more common problem.