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 think of it as open source

[superpulpsicle]

I don't know why people think of a product as open source or not when doing deployment. Just think of it as linux or windows or mac or whatever the product is with whatever the feature you need.

How silly would it be to say to any manager, yeah... we're not deploying this because I can see the #includes and functions. That's essentially what people are saying, when they say no to open source.

Re:Don't think of it as open source

[13Echo]

Having access to the source does ALL of us some good. Even if you don't make use of the source specifically it is available for EVERYONE to have the opportunity to improve it. Thus, simply being able to receive updates of improved OSS software. What does this mean? It means that you won't have to wait 6 months for a patch on a critical exploit... Try six minutes or six hours.

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?

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.

Quick List

[JamesP]

It really depends on how your bosses understand the situation.

If they're more of the PHB kind, go "Linux is Free, we don't have to pay nothing, yadda..."

Now, in the "willing category":

1 - replacing WIndows w/ Linux at workstations may be a good idea. After all, their main use is Word Porcessing and E-Mails...

2 - In the server side, there are good choices too, but then there is support...

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.

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.

"Open Source" is not the selling point

[Anonymous Coward]

Assuming you're advising management, or perhaps the CXO level, what you want to focus on is cost. Price. TCO.

Executives don't give a flip about "open source," or "contributing to the community," or "furthering the Free Software movement," etc. Executives do care very much about what they're spending on IT.

Consider the cost of 60,000 Windows workstations vs. 60,000 Linux or FreeBSD workstations. Do some calculations based upon the Windows licensing scheme vs. "free." The differences will undoubtedly be astronomical. Don't push the "free" aspect over the top; factor in the legitimate costs of a) switching existing workstations to an open source OS and b) supporting users migrating from Windows to the OS you choose. Any open source OS will still come out way ahead, even with the cost of switching.

Finally, I would advise that you forget what Gartner has to say, unless your superiors are totally sold on Gartner results.

Start Small

[Anonymous Coward]

I work for a massive-global corp and getting an OpenSource policy in place would be impossible. My suggestion would be to start with a small group. For example, the group I'm with has been denied licenses for PowerPoint do to cost reasons. The solution was to distribute OO to our team members so that we can create PP compatible presentations for distribution and viewing.

If you were to identify those kinds of groups that have been denied or lack software packages do to cost reasons, then you might be able to make similar in roads.

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: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.

First Dispel Myths

[slutdot]

I run a 6000 user network in the healthcare industry. The first thing I had to do here was dispel the stupid myths such as open source software is insecure because so many people can change it. This was difficult because of the power of the Gartner Group and other orgs like them. In fact, the network manager was so Microsoftized, it took going over his head to the CIO in order to get people to start listening. That was quite a risky move but luckily it worked.

The second thing I did was set up parallel apps that mirrored the same thing the company was doing with their closed sourced systems (Windows). This included setting up squirrelmail to connect to the Exchange servers, setting up Linux-based SSH boxes (we had SSL-based FTP) and setting up a Snort box to rival the ISS IDS that was installed. Once they got a taste of how good (and cheap) the software was, management starting coming around. Another thing that helped was the software that I mirrored on Linux boxes were apps that we had been experiencing consistent problems on. The Outlook Web Access and the IDS servers kept crashing so that was easy. The more challenging one was the SSL-based Windows FTP server. I prevailed when I got our customers to start requesting SSH client access (a little comment every now and then doesn't hurt). Most of our customers were running a UNIX-based system so once they found out that we could possibly start using something native to their systems, they started requesting it through our sales reps.
It also helps to get in good with your business partners' IS department.

Re:ROFL!

[Daniel Boisvert]

The poster of this 'Ask Slashdot' probably makes 2-3 times what I make (if not 10x-20x in stock options alone) and yet he's willing to listen to my poorly informed ideas on such an important matter?! Truly hilarious!

Sometimes folks get promoted into positions of power and influence because they realize that the best answers aren't necessarily the ones you pay the most for. Indeed, isn't that one of the major selling points of OSS--that paying more does *not* always get you more?

A request for opinions is exactly that. You didn't really think he was going to use your opinion to supplant his own, did you?

Dan

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.

Re:Don't sell "Open Source"

[KGBear]

When will I learn? You really can't try simplify something to drive across a point without someone calling you a liar. OK, here goes a point-by-point reply:

Based on your assertion that you previously ran nearly everything on a single linux server - implying a fairly small company - I'd just like to make a few observations that point to you having made the whole story up.

Actually the company was a bank. Granted, a fairly small bank, but I don't think it qualifies as a small company. About using a single server, that's not entirely acurate. We had two for failover, even if the second one was never used because we never needed to use it.

Primary and Secondary Servers: There is no such thing as Primary and Secondary Active Directory servers in a domain. There are just ADS servers, which hold the distributed ADS database, and member servers, which don't. Master/Slave or Primary/Secondary was NT 4.0.

Fortunately, I'm not a Windows administrator. Anyway I apologize for incorrect use of Microsoft terminology. The bank hired Microsoft itself to perform the installations and Microsoft suggested we used 2 AD servers.

DNS is integral to Active Directory. You don't have a seperate DNS server.
You could easily have made the Exchange server an ADS server in case of failure on the primary - or, considering you imply you were running everything on one linux server, just run Exchange on a machine that's also the domain controller.

Again, not my call. Microsoft suggested that we have should have a server per service, as they put it. That goes for the antivirus too. We ended up with another windows server for that function because Microsoft said they wouldn't accept responsibility for the antivirus stuff if every mail was forwarded from an open source machine.

You have to balance the time savings the company made by using the Outlook Groupware functions against the cost of any additional machines or software. This is why the actual difference to the bottom line of a company that Open Source makes is so negligible.

I already replied to that. The same functions could have been implemented with alternative solutions, including open source and proprietary such as Lotus. Outlook is not the only possible way to achieve that.

1 Exchange Server + 2 ADS Servers + 1 IIS Server + 1 AV Server is five Windows Servers, not six. If you can't do basic Maths, I'm not suprised your boss over-ruled you. If it was true, I agree with you: You should have stuck with Linux, because you clearly know nothing about Windows Servers.

Oops, I'm sorry: 5 servers, not 6, you are correct. Actually my boss did not overrule me, he agreed with me. We were both overruled by HIS boss. You are also partly correct regarding my Windows knowledge: I don't have a lot, that's why I hired Microsoft for the consulting job and we followed their specifications to the letter. After the whole experience I decided I really didn't want to know a lot about Windows servers, that's why I don't work there anymore.