This is also the sole reason IBM still exists, at least in services.
"Oh our system is an overengineered pile of garbage that takes two weeks to deploy an update to a static asset? It's (cue dramatic music) their fault!"
CTO proceeds to get bonus
IBM Consultants are brought in
The risk mitigation factor from large vendors comes not from performance but from reliability. You can trust that old mainframe code will continue to be supported for many years. You can trust that your COBOL workload will be continue to run, and that the 20 years of updates, patches, and tweaks have made it reliable and predictable in a way that precludes rip and replace in all but the most extenuating circumstances.
IT budgets tend to be governed by an 80/20 rule - maintenance vs innovation. Sometimes, its more of a 95/5 in practicality due to shrinking budgets. My experience says that the innovation side is drastically shifting away from these big vendors, but that the maintenance side has a lot more riding on it still.
When is the last time an OSS programming language that took off actually died? For example, even though it's not as popular Perl 5 is still used professionally in many environments and as far as I know the ecosystem actually went through a sort of renaissance a few years back.
And these days I think it's even easier for OSS ecosystems to achieve critical mass and sustain themselves for decades since communication is easier (a lot more broadband internet in the world) and there's a lot more programmers around. Python, Ruby, PHP & co will probably be around long after I'm dead.
This is certainly a cultural thing. In some organizations (and even the governments of other countries) open source is well regarded and sometimes required. These organizations realize that a strong trusted community around an open source project is usually good enough- especially when you invest in good employees.
Note, some FOSS products also provide a strong support team to handle this exact thing, and in those cases they were usually the winner.
Edit: Looks like abakker posted the same idea simultaneously.
You could say the same about proprietary software, no?
Reliable on call support. Oracle is not going to vanish overnight or de prioritize you due to lack of resources.
The possibility of that risk in other firms is sufficient to make them non options
You want support for sure but big companies are hit and miss on support quality.
Consulting mailing lists and IRC for a DIY solution is not an acceptable solution for most enterprise users. Moreover, there's nobody to sue if something goes wrong.
Red Hat was formed to fill that gap, but so far it has had only modest success. Companies like IBM, HPE, and Oracle exist because they are perceived as stable, likely to be able to support their technology over the long term.
For example, mainframes and COBOL are largely long dead technologies, but banks that bought mainframes running COBOL from IBM in the 1970s are still very much getting active commercial-grade support for those technologies from IBM today.
Again, for innovative new projects, this is changing.
Years ago, I worked on a project that used Oracle's BPM product. It was the only time I've worked on something where the team had a direct line to vendor support. When we had issues, all they ever seemed to do was ask for more logs, over and over again. I think they were hoping we'd give up and close our SRs.
Luckily, I got off that project pretty quick. I later learned that they 1) rewrote their BPM product and did not offer a clear upgrade path to the new version, and 2) planned to end support for the old version in a few years.
As a developer, the promise of vendor support doesn't ease my mind very much.
I agree with another commenter that in the long run, it'll end up as OSS + support from a 3rd party consultant or vendor that is commercially aligned with your success.
It has taken a very long time to convince most IT to behave like a branch of business that can create new value. Once that shift happens fully, we'll see the "keep the lights on at all costs" mindset change a bit in favor of truly measuring ROI and true total cost of ownership. For most large companies this has never been done.
(Of course I have to admit they were successful ads if I remember them 15 years later.)
Links to the ads: http://www.landscapesofcapital.com/items/show/893 http://www.landscapesofcapital.com/items/show/888
http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pro...
Someone is delivering business value; whomever that is is the one who is getting paid.
> Someone is delivering business value; whomever that is is the one who is getting paid.
I was going to respond to this by pointing out some common exceptions, but patio11 actually covered this issue in his post too:
"Businesses do things for irrational and political reasons all the time (see below), but in the main they converge on doing things which increase revenue or reduce costs. Status in well-run businesses generally is awarded to people who successfully take credit for doing one of these things. (That can, but does not necessarily, entail actually doing them.)"
EDIT:
"Their [Salesforce's] motto and sales point is “No Software”, which conveys to their actual customers “You know those programmers you have working on your internal systems? If you used Salesforce, you could fire half of them and pocket part of the difference in your bonus.” (There’s nothing wrong with this, by the way. You’re in the business of unemploying people. If you think that is unfair, go back to school and study something that doesn’t matter.)"
Holy shit. That hits hard.
They will deploy the most complicated solution they can (almost) keep running and then ask for more time and materials when they miss.
The FTEs at the company will want nothing to do with their Rube Goldberg sparkly bullshit and are all too happy to walk away and work on something else.
Nobody can make XML impenetrable like IBMGS can. It is both fascinating and horrifying to watch.
In the end, I tend to prefer discoverable code (hate angular because it is anti-discoverable), and when there are abstractions, prefer to keep them isolated and clean in purpose. It sometimes requires changes as requirements evolve, but then again, I've been in touch with enough people who've worked on projects I've started/built and haven't gotten any extreme WTFs about it.
I'd like to see a lot more formal work on discoverability. There are a lot of libraries being written by "smart" people who are behaving very stupidly right now.
Well, this can be said for any big business software company. It's the same story with SAP, IBM and friends. Business software is simply not about spending money well.
That's never really expressed places like here. It's just "not spending money well", when I think there are legitimate positives to a lot of business software.
It happened only a few times that users of such products (analysts, admins, support, devs, ...) told me that they like this or that. And I still remember each one of those guys and girls. (Weren't that many)
I know what those companies charge for their software and maintenance. I've been involved in the development of those products for a couple of years. And my very personal opinion is: they're not worth their money. No matter what a customer tells the press how much easier their business is after purchasing product X from company Y.
As I said, it's my personal opinion on that matter.
The reality when you work in these fields are that there are many different reasons why a given solution is selected, and often times people really like it.
I almost don't want to post about this here because I know it's going to be disliked, and I'm not trying to start an argument. But you never get that perspective here.
SharePoint is good for locking everything down, enabling complex workflows and intricate business processes. Because of that it's a total shit show from and employees perspective because it drains your life force every time you have to slog through it.
Heck even something like JIRA is an example of this. Its infinite knobs and levers let managers and PMs layer on complexity until a nice out of the box experience turns a lot of HNers into JIRA haters for life.
Other reason, they are gaining money mainly because there are enough fools around running big corps, who can conveniently pass the buck if something goes wrong. Similar is true for MS too.
But if you really want to see your money well spent, Oracle is not at all the way. The recent decision by Yandex to shift from Oracle to Postgres should be seen here. [1]
[1] https://www.pgcon.org/2016/schedule/attachments/426_2016.05....