IT Departments - How Are You Supporting Your OS Code?

ZMan asks: "A lot of IS groups are using Open Source tools (Linux, MySQL, PHP, etc...) to build cost effective and reliable IT infrastructures for their companies. Upper and executive management wants to know how these tools will be supported since their isn't one single commercial entity that does by default (ie. Microsoft). So, what does your IS group do? Do you hire staff with the expertise to do support in-house or out source all your support to a third party? Or something else?" You've got the source, why not find someone who can care for it, be it an employee, or contractor?

Comments

The old fashioned way

[linuxwrangler]

Pay someone...

Seriously, four points need to be made to management.

One. Relying on a single vendor is every bit as dangerous as building a stock "portfolio" with just one stock. Diversity is good.

Two. Support exists - you might try compiling a list of support options. Include both the free (newsgroups, web sites, etc.) and the not free (list the consulting companies that specialize in the software you use).

Three. Big vendor and single vendor are not the same as good support. One need merely read the Gripe Line column in InfoWorld to see how shabby the (often very expensive) "support" is from many large and supposedly solid and reputable companies.

Four. The right to use the code indefinitely prevents abuse by vendors. It is no fun investing lots of effort building systems (code you develop and own) only to have a vendor pull the rug out from under you when they cease supporting or selling a product or when they switch licensing schemes to make continued use unaffordable.

Re:The old fashioned way

[sydb]

I should also say:

One. Relying on a single vendor is every bit as dangerous as building a stock "portfolio" with just one stock. Diversity is good.

Management just won't see it that way. They see an infrastructure comprised of products from a single vendor as more likely to 'interoperate'... and they theorise that support will be better, as the vendor won't be able to blame some third party.

The risk you identify is of that vendor going under. But, to use the example from my other post, no-one thinks IBM is about to fold. That would be a 'steady performer' in your stock portfolio.

But if you can convince management to use Free Software, then you are right, as that particular risk is not important, as long as someone else is available to take over support and maintenance.

The acid test of all ideas is 'convincing management'...

Re:The old fashioned way

[jason_watkins]

>One. Relying on a single vendor is every bit as dangerous as building a stock "portfolio" with just one stock. Diversity is good.

There's something you're glossing over. For the most part, stocks values are distinct. While a global factor may affect all stocks to some extent, typically the rise or fall of a single stock has a very limited influence on the other stocks in your portfolio. IE, if netscape tanks, it likely won't dent say General Mills.

With solutions however, this isn't always the case. Often a single failure among the componants will bring the entire solution down. This is what makes management nervous, and it's justified and good; don't slam them for it. The way you mitigate this is you make the slices between componants fall on standardized protocols or interfaces. Ie, if MySQL starts to bog or takes a development path away from what you want, if you do things right, it should be quite simple to switch to PostgreSQL or oracle.

So keep that in mind, diversification and combination are not nessisarily the same, and you need to balance the issues.

Many of these companies do sell support

[Anonymous Coward]

MySQL does offer support if you wish to pay for it. It even comes in two forms, standard and advanced.

PHP support is also available from Zend, and some is even included when you purchase one of their products.

It may not be one unified source, but if you're using Oracle software, you wouldn't expect MS to support it would you?

Documentation Documentation Documentation

[cow ninja]

When writing inhouse applications or when building something with unsupported tools documentation is key. If your code is commented and you keep a "Journal" as you go someone else will/should be able to pick up where you left off. This is common coding practice.