Constructing a Corporate Open Source Policy?

Stokey asks: "I work for a global finance firm, (60000+ employees and presence in 25+ countries) in the Group IT department. Pressure is building from the businesses to cut costs and Open Source software has been pushed onto the discussion table. I am trying to educate IT Directors where I can with correct definitions, breaking down assumptions, and will most likely end up writing the group wide Open Source policy. The challenges are well known: risk, cost, support, licensing, benefits, training, and so forth. I am looking for help in putting together a pack that can be handed to our IT Directors forum which contains a policy, TCO (Total Cost of Ownership) reviews, and risk reviews by companies that have done it. After asking what Gartner has to say, the next question will be 'So who else has done this?'. Can Slashdot assist?" What information do you think should be included to sell Open Source to management at the top-level of any corporation or business?

I'm sure several of you have run into this situation before, so I figure this may be as good of a place as any to suggest what information might be appropriate to place in such a policy, especially for future IT workers who find themselves in this position. If people are serious in getting Open Source further into the enterprise than it has already is, such information will be necessary to convince the powers-that-be on the things that we already know: Open Source can be as good as, or better than, commercial software for business tasks. Things like licensing descriptions, common misconceptions, and what Open Source really is would be an absolute must. What other information do you think would be absolutely necessary to include into such policy?

Comments

Don't sell "Open Source"

[rjstanford]

Some open source projects are very well done, and provide clear and immediate benefits upon implementation - assuming that you have problems that they solve. Others are less so. In other words, don't try to sell "Open Source" as a fundamental concept. Sell specific open-source solutions to specific corporate problems.

Remember also that everything is relative. Let's say that you're working for a small software company. You need an office suite. You could use OpenOffice, which has no initial cost and a small but non-zero chance of incorrectly storing documents that get sent to potential customers and investors. Or you could go to Microsoft.com and get a ton of NFD software, including Office, for a couple of hundred bucks. Here, the open-source solution fails to be appealing. If you're developing J2EE applications and need a good app server though, its very possible that JBoss provides a compelling open-source alternative to expensive software like WebSphere.

But (and here I'm speaking as the CTO for a growing software company), if you start out with blanket statements like "Open source has lower TCO," without talking to the specific context of a business problem - I may agree in principle, but speaking as the company, "I don't care." Solve a problem, do it well, do it cheaply, and you'll find that the company execs don't care either - but that holds true in both directions. If the best solution happens to be open-source then they'll probably go for it, but not because its "k3wl" or open, but because its better for the business.

This is the time for open source to, as they say, put its cards on the table. The advocates feel that it does deliver lower TCO (and other advantages). I happen to lean that way myself. But that should mean, ironically enough, that the end product should be superior without including the specific point that its open source, any more than I would pick any other product because of the way that its built. The better building technique produces a better product, and that's why it gets used.

At least, that's my opinion.

Re:Don't sell "Open Source"

[rjstanford]

But this doesn't have to happen at all. OpenOffice allows you to set .doc as the default save format; resulting in a zero percent chance of files being saved incorrectly and your customers ever receiving unreadable documents.

Not quite true - a couple of times, the last time I tried to use Open Office, I opened a .DOC file, made some changes, saved it, and got ready to send it off. Being the trusting soul that I am, since I was just eval'ing OO, I checked it in Word. For some reason the bullets had been changed to little smiley faces - at least, when it was opened in Word (which is almost certainly what the recipient would do with it).

Seriously.

Why did this happen? I don't know. The other issue is that I don't care. I have better things to do with my time than to try to figure it out as well (at least at the moment). So I ditched the whole product. Was it because of something that Word did to the original document that OO didn't properly understand? Could be. Again, who knows? I do know that that wouldn't have made a good impression on our client though.

Saving $200 - good
Showing poor QC to a multi-million dollar client - bad
Any questions?

Re:Don't sell "Open Source"

[KGBear]

Unfortunately, it's not that easy. I tend to agree with you in principle - just pick the right tool for the job, it shouldn't matter if it's open source or not. On the other hand, You must remember that there is a lot of pressure against anything Open Source (in the form of marketing from Microsoft, conservatism inside the organization, end-user unwillingness to learn something different) and this pressure should be balanced with an equal force and opposite direction if your Open Source implementation is to be successfull. More and more it becomes hard to chose the right tool for the job because Microsoft tools, Microsoft proponents and Microsoft consultants don't want you to integrate.

I had this discussion with my boss where I used to work a few years ago. He felt that it was OK to include Outlook as an option for a mail client for users alogside Eudora and Netscape Mail, I felt it was risky. This is how it went:

- User starts using Outlook, notices the groupware functions
- Instead of asking for the functions, they ask that those buttons in their Outlook clients "be enabled"
- The only way to do that was (at the time) to replace Sendmail with MS Exchange
- Exchange doens't integrate with current NIS+ servers unless it's through AD + Windows Services for Unix
- That requires master and slave AD servers;
- AD + Exchange will be happier with their own DNS server
- No real Open Source anti-virus software to talk to Exchange while running on Linux, so there's another Windows server

So there you have it: one Linux server that used to run Sendmail, anti-virus, NIS and DNS get's replaced by 1 Exchange server, 2 AD servers, 1 IIS server, 1 anti-virus server. 1 linux box replaced by 6 Windows servers at considerable cost and we lost our ability to chose the right tool for the job for that whole chain.

In the end what I'm saying is that while choosing for the right tool for the job you should be careful not to be locked into something that will force you to pick a lot of tools not so right for the job!

Verizon does it.

[thedoktor]

Verizon's IT division had been running the entire development team on Linux, Openoffice for years now. There was an article somtimes back, on newsweek about a Verizon Director George Huges's initiatives.

www.cat.com

[dukeluke]

Try Caterpillar for a real life example! -- I know personally that all their back end servers and mission critical servers are indeed open source.

And - NASA's going open source too see /. here

All Your Base Are Belong To Us

Re:Don't think of it as open source

[wo1verin3]

>>no, they are saying "I don't trust that a non-
>>commercial entity can provide ongoing support
>>nor do I trust a product without several names >>I can immediately call to get my request routed
>>to the correct division for support"

Do you of many non-commercial entities that trade publically? Going open source doesn't mean you're going non-commercial. It means you have the option to go this route, or not go this route.