Comment by abakker | Hacker News Reader

Comment by abakker | Hacker News Reader

Parent Full thread

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.

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.

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.

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.

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

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

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.

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.

Reply on news.ycombinator.com