Hacker News Reader

Comment by tmptmp | Hacker News Reader

I am happy Oracle is losing this battle (edit: or at least feeling the heat), one sort of personal reason is that they have killed/crippled many open source projects.

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

View on HN

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

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

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.

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.

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.

I just spent today in meeting hell with networking vendor sales engineers. One thing everyone agreed on was what an absolute delight it was moving from Oracle to Postgres. Oracle is a top-class database - it saves your data, it gives it back really fast and reliably - but every other detail of dealing with them is awful. The biggest benefit of moving to PG is we never have to think about licenses again.

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

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.

Business software is about regulatory compliance. That is the baked in value that these behemoths offer.

Big companies are often are complicated mess, and I can emphasize with desire to simplify and streamline operation. There's some benefit with setting your infrastructure in such a way that there's a known party you can pay to fix things quickly, and that you can sue if they can't.

Often they also like to stay understaffed in IT, so having consistent vendors, and similar systems allows them to keep just a few guys around that have any clue how it works, and supplement with consultants and vendor support.

People say that a lot, but I work with customers all the time who are very happy with their solutions. I don't disagree that some people hate them, or hate this or that ui, but I can think to many companies/interactions with people that love the products.

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.

I don't claim that I know the ultimate truth, but I worked for many years for one of those big business software companies. But from my experience, only the people who don't have to interact with such products in any form like it. (Who are often also making the decision to purchase it)

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.

"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." - Is there any source to justify this comment ?

No. It's not even really true.

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.

Not least of which is the time/expense/risk to replace even a suboptimal solution outweighs the benefits.

I agree in the general sense but it's important to understand that the reason you see so much disdain for these pieces of enterprise software are motivated by reasons that are just as valid as the reasons for choosing it in the first place. Is Oracle RAC a database with compelling features and a large pool of adequate DBAs? Sure. Is it a piece of shit that requires X Windows on the server? Sure. The reason it needs an X Windows server to install and manage is because it needs to have a GUI that those pool of cheap DBAs is capable of reasoning about.

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.

Even though I think it's a lot more nuanced than that so I don't exactly agree asking for a source for every little thing, particularly things that are clearly understood through experience (or something you can Google yourself), is a redditism that I think HN would be much better off without. It's often an underhanded way to effectively kill a discussion with a cheap "checkmate". If you disagree or have a differing experience simply say so.

Reply on news.ycombinator.com