For many people in IT, generally not the Hacker News crowd, but the guys in the trenches of [insert corporation name here] with ops in many countries, The Money is NOT really the important thing. Risk mitigation by having a passthrough to the big IT vendors is what they are paying for specifically. I work in the IT consulting / business research space. In our surveys, "vendor viability" is a frequent concern, and the more critical the workload, the more weight is given to wondering whether the vendor will be around, unchanged, in the next 3 years.

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.

Well, thing is, Open Source is changing that proposition. As long as you're prepared to be conservative in your choices, something like Debian + Apache + OSS programming language will likely be around 20-40 years from now.

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.

A lot of large U.S. organizations wont use software they cant buy support for. So, you can use RedHat and buy support. When you create software, your developers are going to use all kinds of tools, libraries, etc. and depending on the policies of the organization they are going to want to manage that risk. For example, if you're a bank and the devs who make your mobile app use some random authentication library that later turns out to have major security issues- the bank wants to have support for fixing the problem immediately. And, they want to know who they sue to recover the money they lost due to the security issues.

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.

Part of the reason that Postgres is popular is that there are multiple companies selling support for it, several of which are also major contributors. So there's actual competition to keep prices somewhat under control.

Yeah, don't remind me. I still have nightmares from my experience with Enterprise DB from my last company.

Me too as I was considering pitching them to Oracle shops. My email is in profile.

I'd love to hear more about this. pjlegato at databaselabs dot io

I disagree that there's PostgreSQL support out there. When I was having serious performance issues, I did a ton of Googling and couldn't find a single place that could offer a-la-carte support, only very, very expensive yearly subscriptions from questionable places - ie. no name brand consultants or anyone connected to PostgreSQL itself.

I agree. However one additional thing to keep in mind in the COTS vs FOSS is if there is some bug that affects the company and requires attention. The company doesn't generally have the engineers on staff to actually change that software, and there's no guarantee that the associated FOSS community will prioritize the bug. With a COTS solution, you can pick up the phone and call the support team. Generally my company chooses COTS over FOSS because they want guaranteed support even if it costs more.

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.

Indeed. It seems that the most sustainable business model for Open Source so far is a combination of FOSS product + paid support / consulting company. It has some potential conflict of interest (e.g. deliberately not improving some aspects of the product that brings in support calls), but being a successful open-source product often depends on outside contributions which themselves depend on reputation, and that may keep companies honest.

> It has some potential conflict of interest (e.g. deliberately not improving some aspects of the product that brings in support calls)

You could say the same about proprietary software, no?

Yes. I was stating they exist, not comparing to propertiary software.

That still doesn't work because the core issue is partially addressed.

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

Many of the companies making proprietary products with high lockin have terrible support just because they know you cant leave. Whereas it's the opposite for some startups and FOSS companies knowing how easy it is for them to loose business. So, I dont buy that as an advantage of companies like Oracle.

You want support for sure but big companies are hit and miss on support quality.

I work for a major bank that is making the transition to OSS. The long term costs of a supported solution are often huge.

From what I have experienced, open source is acceptable, as long as it has a support contract behind it. So basically for Linux you can use Red Hat or Suse, and with the occasional Ubuntu in there as well.

It's not about whether the technology will die per se; it's about whether they are contractually guaranteed that there will be a professional support team in place to support it for X years, and whether the vendor's ability to fulfill that contract over the long term is perceived as realistic by the client.

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.

Open source may perpetuate, but it is the on-call, active support that enterprises value. You can't exactly demand prompt action from the support forums, can you? Now maybe open source like Red Hat works that way, but it is very much the commercial terms and operating models that businesses are interested in.

Again, for innovative new projects, this is changing.

You can't necessarily demand prompt action from a big vendor like Oracle, either.

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.

This is, of course, how oracle and others earned its reputation. These things and worse really happen. Obviously nobody wants this when they pay for better.

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.

Being able to pass the buck to IBM if things go wrong was actually the theme of IBM's ads in 2001. In a typical ad, the CEO is getting blamed because the system is down / can't be upgraded. CEO: "And whose job is it to make sure all this stuff works the way it's supposed to?" Assistant: "That would be yours." Tagline: "And that's when it hits you, you are so ready for IBM.”

(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

Honest ads describing the business value directly. I like that. We could use more of that these days.

Feels strikingly similar to patio11s blog post:

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.

Thanks for linking to that post, it's great!

> 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.

IBM Global Services seems to prefer hiring masochists.

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.

This is part of why my initial and strong reaction against most "Enterprise" patterns and libraries... It often leads to so much indirection and complexity, that those working with it don't ever stop to thing "why" they are doing things a certain way, and when new people come in to support said solution, they face a mountain of difficulty.

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.

We had a good convention for our Angular project that wasn't too bad. Certainly a lot more discoverable than the rails project I worked on before 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.

Don't forget the original reason: backward compatibility with complicated, mission-critical software on weird hardware nobody can legally clone. These businesses would have to port all their stuff to avoid IBM. They probably don't even know what it does. So, they stick with them to mitigate that risk.

Plus, the time to transition off it is far longer than the next quarterly results. It may well be longer than the expected tenure of the CEO....

Great point. They are short-term focused most of the time.