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

BIg Company

[LennyDotCom]

Your company is very large. You must be using many open source solutions in many ways already. You should start there by identifing what is already being used and how effective they are. Thereby providing your own case studies.

You are fortunate!

[lscotte]

You are fortunate to work in a company that is open to open source. I work for a large software company (10000+ employees in several states), and the official policy is that nobody uses any open source software, because if somebody sues us there isn't a company we can turn around and sue. This is seriously the primary reason - I've had one-on-one discussions with our lawyers on this issue.

Personally, I violate that corporate directive on a daily basis - I run linux, I use mozi^h^h^h^hphoe^h^h^h^hfirebird^h^h^h^hfox, etc. I do have to rdeskop to a windows box for corporate email and to use word+excel, as many people in my same position have to do. But 100% of my development (java) is done on linux.

We're in the same boat

[BritGeek]

Oddly enough, my own company is in much the same situation. Our policies have historically forbidden open source software (generally because of the lack of support). However, a few mavericks have been changing the position on this. Here are the salient points from our thinking:

1. Have your policy/standard give prescriptive guidance about when you feel it is - and is not - appropriate to use open source. I'm not saying there are necessarily cases where you may not want to use open source, but there may be. For example, our shop is a big WebSphere user, and for us that was a strategic choice. We have good operational competence at running it too. So, just because some project came along and said "we'd like to use JBoss", that would be a good example of when not to use open source - for us, anyway.
2. For cases where you do use open source, make sure that the sponsoring project for some particular open source tool has clearly identified how it will be supported in production. This may be the team itself, it may have chosen to outsource, who cares... But, make sure they do identify a source of support. Otherwise, when stuff breaks a 2AM, the ops folks will just call *everyone* in... ...probably including you.
3. Make sure that your General Counsel's Office is thoroughly briefed on the various kinds of open source license agreements, and that they are ok with the license for the particular open source tool when it is "acquired". Some licenses may not be compatible with all commercial usage (LGPL is probably the worst offender from this perspective), and thus careful review is appropriate. In any case, if you don't get your GCO on your side, they'll shoot you down in flames...
4. Make sure that your policy/standards differentiate between where it's appropriate to *use* open source, vs. where it's appropriate for you to *contribute* to it. There are at least two reasons for this: a) if no one gives back, the quality of open source software will suffer; and b) there are often cases where it's better to give up both work (as well as "intellectual property") rather than doing something proprietary. For example, three or four years ago my own company had decided that we needed an MVC-based front-servlet design. It proved very handy, and as projects like struts came along, we just dumped some of the core ideas into that project. Over the long-haul it is much better for us to have our needs supported directly by open source products, than it is for us to have to build a bunch of proprietary goo.
5. You will likely have another fight on your hands with the aforementioned lawyers on the idea of contributing to open source, but it's worth fighting for. (Our own GCO just didn't get this, and I'm not sure whether they fully do yet. They have a distinct feeling that our IP rights are such that we should own the universe.)
6. Expect a fight. There will be a certain number of folks "from the Dark Side" who view open source as a threat to Civilization As We Know It. Take no prisoners with these types...

Good luck!

Re:Quick List

[tuba_dude]

While it is true that the workstations would probably be used for word processing and e-mail, I'd have to say that replacing Windows on the workstations is less likely than on the servers. The servers, when they have to be touched at all, will be serviced by geeks (or at least trained facimilies) who understand what they're doing. The end users at the workstations can't always be counted on to understand what they're using, and those that don't get it usually complain when something changes.

Dealing with end users could actually be pretty simple, if a bit frustrating. Install your favorite flavor of Linux across the entire company in one massive night-op, forcing everyone to "jump into the deep end." That would make them complain and make even stupider mistakes than usual, but it would be a fast transition.
Or Option 2: Install Linux on the workstations one department at a time. This way you can watch people migrate across their offices to check their email on the windows machines, as they are afriad of their own systems. As the Windows numbers dwindle, the more bold return to their systems to avoid the lines at their co-workers' computers. The stupid (more so than usual) help calls start to trickle in as they realize they don't know what they're doing and they want you to share in their pain. When the Windows machines begin to near extinction, more and more employees return to their systems, repeating and aggrivating the cycle of stupid.

So do you do it at once, or draw out the pain? It's kinda like adolescence really. It's got to happen eventually, but nobody really wants to go through it. Might as well be an early bloomer!

Oh yeah, back to the original subject. Linux on servers: Good, farily easy transition, especially if the IT dept. has any Unix experience. Linux on workstations: Good thing, probably a painful transition, but worth it in the long run.

Re:Don't sell "Open Source"

[rjstanford]

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.

Agreed - provisionally. You made a good point for the higher TCO of Outlook there though, which should push it to the bottom. Unless, of course, it turns out that your users are actually productive enough with the groupware functionality of Exchange to justify the expense of the additional servers, licenses and maintenance - which could be true or false, depending on your company. Everything is, after all, relative.

Forgivenesss v Permission

[SenorFluffyPants]

I am the IT Director at a much smaller (100+ employees), so this advice may not wash in just a vastly different culture. I have found that it is much easier just to do it, and then point to it when it is up and working at a reduced cost. I have found great success in this approach.

"Here are last year's costs...here are this year's costs. Wow, is that a lot less or what?!"

YMMV, of course...

DO sell "Open Source"

[daveball]

While (as you rightly pointed out) it is quite clear there are advantages for and against individual opensource an proprietry products, there is also an argument to be made for opensource in general.

This is not to say that every open source product has better (or even equivilent in some cases) functionality, but that the very fact that it is open source has benefits. For a large multinational such as the submitter is enquiring for, one of the big wories must be ownership and continuity of support for whatever product / projects they use in their IT infrastructure.

Pick a proprietry product, and a company going bust or mearly becoming uncooperative could result in a large risk to your ability to maintain your internal infrastructure - be it through bug fixes or introducing new features.

By choosing an opensource strategy, it will always be possible to either maintain such systems internally, or shop around for someone appropriately qualified to make the changes you need. Purchase and maintainance TCO are good arguments, but IMHO the biggest factor to large multinationals will be one of reduced risk, and therefore there can be a benefit by choosing a lower featured opensource product over a traditional proprietry one.

Re:Don't think of it as open source

[mr_lithic]

I have been using an abandoned project for the past 15 years. It is a bulletproof little disc app that was abandoned by its creator and distributed as freeware.

In addition, I have based our entire helpdesk on an abandoned project which is the best, most stable, platform independent helpdesk app out there. It has a huge user base and large number of forums for help and support. But no one currently developing code for it.

Are either of these apps useless because they are abandoned?

Nope.

Abandoned software does not mean it is has no use, simply that it may be limited in future plans. But if it works now and does the job, why not use it?

Be ready to counter 'viral' arguments

[Experiment 626]

Between the FUD that Microsoft and SCO have been throwing about, most non-technical people will have a very confused view about things like the GPL and open source IP issues. You have to be prepared to address these in simple, easy to understand terms and examples.

For instance, a lot of people get scared by the 'viral' GPL FUD, and think using open source products means they have to release all their own IP crown jewels to the public. You might counter this by pointing out that you can write closed source software with open source tools all you want, and only run into trouble if you actually incorporate their code into your product. Because this is something you couldn't do with non-open source software anyway, as you never see the code, the percieved risk isn't a factor for doing things the way you're used to.

Anti-open-source people have been throwing a lot of FUD around lately. The people you are trying to pitch this policy have heard some of it, and probably don't spend lots of time on Slashdot or Groklaw finding out the whole story. Part of your role is going to be to dispel all this FUD about the GPL, IP issues, and such.