Kclug Digest, Vol 39, Issue 9

[Monty J. Harder]

On 10/8/07, leenix <leenix at kc.rr.com> wrote:
>
> First of all let me say thank you to everyone who shared ideas. it has
> been very helpful.
>
> OK. Let me play Devil's Advocate for a minute.



1. I realize the source is available, but I want my developers
> developing OUR software not OS (Fill in your other FOSS software here)
> software.


The value to you of having the source available is not just that your
developers would rewrite the FOSS software itself.  That can be done by
others, although you'd be surprised how little of your devs' time it would
take to patch FOSS projects, and be good citizens who submit them upstream.
The time they don't spend trying to reverse-engineer some obscure bug in
someone else's code will probably more than make up for it.

The big win is they'd understand exactly what the software is doing so that
they can interoperate with it. Documentation tells you how the code is
SUPPOSED to work, but the code tells you how it really works.

2. If I buy a piece of software that is closed-source, the company
> selling it to me has to support it. If something is wrong with it,
> they'll fix it, because that's where they make their money.


No, they don't have to support the software.   They can sell support
contracts separately. Call a closed-source software company without that
contract and see how much support you really get.  And they don't make their
money from fixing the software, they get it from SELLING the software.  They
already have your money.  So unless they're going to CHARGE you for the new
version that fixes the bug, they don't make money from the transaction.  And
if that's the case, you might be able to pay one of your developers to fix
it NOW instead of waiting for them to even admit that the bug exists, much
less fix it.


3. If I buy [closed-source company]'s software I know it will work with
> their Database, Mail server, Office Suite, etc. because it is made by
> the same company. I'm not sure that we'll be able to get [open-source
> company]'s software to talk to our existing infrastructure, our to our
> partner's existing infrastructure.


Do they guarantee that it will work with that other stuff?  In writing and
everything?  When you upgrade $foo, do you also have to upgrade $bar, $baz,
etc. to maintain that interoperability?  Even if you do get seamless
integration between their software packages, do they provide any interfaces
to let third-party apps work with them?

The thinking in #3 is an Unconditional Surrender to Lock In.  It cedes all
authority to this closed-source company to define your operations.  Instead
of adapting software to your business, you'll mold your entire organization
to fit the tools they provide. "When the only tool you have is a hammer,
everything looks like a nail." You'll turn perfectly good wood screws into
nails.  This is the first step in a downward epistemological slide. You'll
declare that 1900 was a leap year, because Excel says it is.  You'll insist
that you got that black eye by falling down and hitting a doorknob; no,
you're not a victim of domestic abuse; he's really not a bad guy...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kclug.org/pipermail/kclug/attachments/20071009/ec37b4be/attachment.htm