On 10/8/07, leenix <leenix@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...