[BBLISA] Unhelpful responses (was Re: How would you address this?)

Douglas Alan nessus at mit.edu
Fri Feb 17 18:10:50 EST 2006


Adam S. Moskowitz <adamm at menlo.com> wrote:

> > "We've decided to go with the open source alternative."

> I won't go so far as to charge unprofessionalism on this one, but it
> still bears all the marks of a typical (bad) sysadmin response. First
> and foremost, it doesn't answer the question the customer (in this
> case that's Michael) asked.

Sure it does: corporations don't exist to do what is *right* -- they
exist for one reason and one reason only -- to make money.
Consequently, the only leverage you have over a company is either throw
lots of money at them or threaten to walk.  Reasoning with them is
almost never fruitful.  The only reason a corporation understands is
*what's in it for them*.

Case in point: I was once offered a job at a huge international
corporation, and a few days before I was supposed to start there, they
informed me that I had to pee into a cup for them as a requirement for
starting the job.  I felt that this was a violation of my privacy,
despite the fact that I would have passed their little test with flying
colors.  I explained to them patiently, with numerous supporting reasons
to them over and over again, that I could not in good conscience submit
to such a severe privacy violation.  All my carefully argued reasoning,
of course, fell on deaf ears.  In the end, I refused to pee into the
cup, consequently they couldn't hire me, and they had to start their job
search over again.  Subsequently, however, they were so burned by the
experience, that the entire corporation (or at least their US locations)
changed their policy and stopped requiring new employees to pee into
cups.

So, from my direct experience, my advice on how to deal with a
prospective employer who wants to invade your privacy is to forget
trying to reason with them: either put up with the violation or look
elsewhere for employment.  I prefer the latter approach.

Likewise for commercial software: either learn to live with its flaws,
or look elsewhere.  Sure, complain all you want, but don't expect any of
your reasons to be heard.  The reason to complain is to (1) make them
worry that they are going to lose your business, and (2) if enough other
people make the same complaint, they are likely to hear you.  But your
specific reasons are unlikely to be heard.  "It doesn't meet our needs
well", is reason enough.

Open source software is different from this in that the goal of the
project is to make something that is as good as possible (at least
according the participants' notion of "good"), not to maximize profits,
so good reasoning on your part may actually be heard.

> Third, I believe this shows a certain bigotry with respect to choosing
> software packages.

It's not bigotry -- it's my direct experience.  Open source products,
when they exist for a specific problem domain, often (but not always)
work better, are better supported, have longer lifespans, are supported
on more platforms, require fewer in-house resources to support, and most
importantly, you can depend on them being around tomorrow.  As an extra
added bonus, they are free and you always get the source code.

Case in point: On a project I worked on we chose a commercial C++
implementation rather than going with g++.  The company that makes that
C++ compiler no longer exists and a machine running SunOS 4 needs to be
kept alive to this day just to run the license manager for the compiler.
The license manager crashes frequently and people can't compile their
code until someone goes and restarts the license manager.  Since the
company that made the compiler no longer exists, it has not been
improved to keep up with the newer features of C++.  Code that was
developed using g++, however, has no such issues.

We also used a very popular commercial persistance library that
prevented us from later porting much of our code from Suns to Intel-base
Linux due to severe byte ordering issues.  For the part of the project
that I had ownership of, however, I rolled my own persistence code
because I wasn't confident as to the design quality of the commercial
library.  My code had no such byte-ordering issues and was readily
ported later.

Another case in point: An EDI system I help to maintain comes with a GUI
prgram for making translation tables, which are stored in some obscure
proprietary format.  We do some similar translation stuff, however,
using XSLT (an industry standard translation language with several open
source implementations using an XML API the vendor provided).  In order
to upgrade to the latest version of the product, a very egregious update
procedure must be applied in order to carry over the GUI-made
translation tables.  Much to my dismay, it is just not possible with the
commercial software to install a brand new installation of the product
and then import the old translation tables.  The XSLT scripts, on the
other hand, merely need to be copied from one computer to another and
everything works just fine.  Or they would, if the aforementioned vendor
hadn't removed their XML API from the new version of their product.

Don't even get me started on all the other woes that this very expensive
software gives me.

Yet another case in point: Oracle just won't install on my Mac, despite
more than a day of effort.  Postgres installs in about 60 seconds.

> In more than a few cases no open source package exists for a given
> purpose; in quite a few other cases, the quality of the closed source
> package far exceeds that of its open source counterparts;

Hence,

     (5) Always go with an open source product, rather than a commercial
         product, IF THERE EXISTS SUCH A PRODUCT THAT MEETS YOUR NEEDS
         AND HAS AN ACTIVE USER AND DEVELOPER BASE.

Believe me, we had very good reasons for choosing the commercial C++
compiler; i.e., g++ just wasn't ready for prime time at the time.  If it
had been, life would have ultimately been much better for us.

And today, we have a very good reason for using a commercial EDI
product: there just aren't any open source ones.  Or at least not any
worth mentioning.  The commercial software is just torment, however, and
if there were a decent open source alternative, it would almost
certainly be superior.

> In nearly all cases the options for and/or levels of support available
> for closed source packages is much, much better than those for open
> source packages.

That's completely counter to my experience.  My experience with
commercial software is that the quality of support is routinely
terrible.  (E.g., "Did you try reinstalling Windows?")  That's not
always the case, but in general, I find the level of support in the open
source community to be significantly superior.

> One last thing: Michael is "one of us"; he's our colleague, and he
> came to us for help. We ought to treat our customers as good if not
> better than we treat our colleagues, but treating our colleagues as
> poorly as we treat our customers really irks me. Why?

I feel that Michael is highly capable and worthy of receiving the
pleasure of my sardonic wit.  In fact, I completely empathize with his
plight, which is why I have to laugh with him, until I cry.

|>oug




More information about the bblisa mailing list