Re: Interview

Arved Sandstrom wrote:
Dave Searles wrote:
Arved Sandstrom wrote:
In all of these cases there were nuances as well. In the first case the vendor officially supported over three-quarters of our installed software. If we had replaced the small piece that was flawed with an open-source implementation, the argument was that the vendor would have refused to deal with any problems related to the entire stack. Not inconceivable. That's political, but it's also a decent argument.

The correct way to deal with that is to tell the vendor all about the flaws in the small piece, and if the vendor wouldn't do anything about that, go with the open source replacement for that component. And of course what the vendor doesn't know won't hurt it; no need to specify that that component was replaced. Just tell the vendor if some other component has problems what the inputs to it were and what the incorrect output was. If the output was clearly not what should have resulted from the inputs, the vendor can't very well argue, regardless of where those inputs actually came from.

Depends on the vendor involved. This particular vendor happens to be in the Top 5 of global IT companies by annual revenue, so if they intimate that support for problems with your installation of their software stack is contingent on not screwing around with that installation, including swapping out pieces for third-party software, it's probably a good idea to listen to 'em.

In other words, they use a near-monopoly power to bully their customers around and make life difficult for them if they have a component acting wonky? This vendor's name wouldn't happen to be nine letters long and starting with an M, would it?

Unless the vendor is irrational, of course, in which case the vendor is going to turn into an anchor tied to your foot and drag you down sooner or later. Get one that isn't crazy, ASAP, or go open source for the whole stack, and then you can fix things yourself using in-house expertise or using a company like Red Hat that sells support services for open source systems.

As to the latter, a vendor like Red Hat sells support for _their_ systems, OSS or otherwise.

The point being, you can use OSS and still be using something the vendor supports in this case.

IOW, you don't generally select a piece of third-party software because it's open-source, you select it because it's the best software for the job.

But what is "the job"? It might include making it easier for you to self-support if you have to. Or it might not. It depends on what is meant by "the job" in a particular case.

In the other two cases I mention there were actually larger project issues involved - possible retraining of internal staff, or hiring more external people, extending deadlines etc.

That seems to me to depend on what was being done. For example, with retraining of internal staff, the problem would be that some user interface was being changed. If the product being contemplated was well designed, the UI and the engine would be decoupled enough that the UI could be replaced or reconfigured so retraining wouldn't be needed (except maybe all those workarounds for annoying known bugs could be happily forgotten about). If the product being contemplated was not well designed, then it fails on the merits anyway.

In this case there would have been technology changes involved. The internal staff would have been programmers and operations support. You don't lightly propose changing technologies, even if the target technology is a much better solution for the problem, without taking those kinds of resource issues into account.

Then you may be sunk, stuck in a quagmire from having backed the wrong horse at some point. Maybe you backed Eiffel back in the day and then Java's what took off, for instance.

This is all political stuff. And unless you're a software developer on the bottom rung (and maybe not even then) you'll have a happier career if you learn how to take it into account. You certainly don't have to, but you'll end up frustrated and bitter if you don't.

If you don't, AND work for the wrong sorts of people, perhaps.

You'll never work for a company that has no politics.

I would think that a company that minimizes politics, or at least minimizes the collision of politics with the technical hires, will be able to outcompete any companies that don't. So if what you say is true, it is also probably an unstable state of affairs that will not last indefinitely. Like an excited quantum state or a stock market bubble, the bottom will drop out from under such a system eventually.
.

Relevant Pages

  • RE: Vendor wants remote control of our Servers and Workstations
    ... Of course the age-old problem with security is that ... Vendor has significant access to your internal ... this vendor uses the same method to support a number ... customer and makes significant changes ... ...
    (Security-Basics)
  • Re: IIS-5.1 ISAPI dll - "The page cannot be displayed" after XP - SP2 install
    ... The vendor is still responsible for supporting their product. ... "Do you support product X on XPSP2". ... Received a response from the vendor. ... how can you verify that your ISAPI Extension is correctly configured? ...
    (microsoft.public.inetserver.iis.security)
  • Re: Interview
    ... You'd best have some skill at politics if you wish to enjoy a successful career. ... If we had replaced the small piece that was flawed with an open-source implementation, the argument was that the vendor would have refused to deal with any problems related to the entire stack. ... The correct way to deal with that is to tell the vendor all about the flaws in the small piece, and if the vendor wouldn't do anything about that, go with the open source replacement for that component. ... This particular vendor happens to be in the Top 5 of global IT companies by annual revenue, so if they intimate that support for problems with your installation of their software stack is contingent on not screwing around with that installation, including swapping out pieces for third-party software, it's probably a good idea to listen to 'em. ...
    (comp.lang.java.programmer)
  • [ARL02-A15] Multiple Security Issues in MyHelpdesk
    ... Vendor Homepage: http://myhelpdesk.sourceforge.net/ ... Vulnerability Type: Input Validation Error ... MyHelpdesk is a PHP/MySQL Helpdesk system based on the ... When a support assistant creates a new ticket, ...
    (Bugtraq)
  • SUMMARY: problems setting up mpxio
    ... The device must support the REPORT_LUNS SCSI command, ... It appears that these disks do not support the page 83 Device ID. ... Vital Product Data Pages Supported by Device /dev/rdsk/c0t25d0s2 ... Vendor Specific Page ...
    (SunManagers)
Loading