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?
Slashdot Mirror
Though they may not be 100% trusted by the community, they do have resources and studies to help prove your case. Sometimes the slick presentation is valued more that the well-researched one, anyway.
Make sure to highlight both the positive and negative aspects of the switch to open source from a user's perspective. That way if something doesn't work exactly like the higher-ups want it, you have covered yourself by telling them beforehand. You also may be credited with good foresight in the event that certain tasks / implementations are made to work better / faster. Again, make sure to cover both sides of the story or you may be in for some dissapointment or trouble.
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"
Ignorant statements like yours show why the OSS community is having trouble getting its message across. Get it through your skull: Nobody cares whether or not they can see the fucking #includes.
They care whether or not it will work and, when the inevitable problem happens, how quickly it can be resolved by a subject matter expert, not by one of their in house geeks reading the fucking source.
No businessman ever trusts something that is argued to be "free". The saying "you get what you pay for" rings true with most management teams, and anything "free" is directly indicative of being poor quality. Cheap is a euphemism for bad quality normally. And switching to Open Source is not free, indeed it is often not even cheap. The costs are real, but so too are the advantages.
I don't know about your IT department, but for many more than half the price of a PC is Windows and Office licences. Stopping those is a dramatic cost-saving.
Your company will almost certainly want continuing support for its systems, this will have to be budgetted for. Don't forget training costs, your workers will need to be retrained to learn how to use the new systems and this costs money. There are more costs but you get the point.
Do a genuine cost-benefit analysis, work out all this, especially support and training costs, and it will still be dramatically profitable to switch to Open Source. However a fully polished, professional and complete cost-benefit analysis will provide very useful and significant information to management, in a form they can understand and trust.
I think it is most important that the ROI be measured in an effective method. Such as, not only look at the obvious costs, but look at the hidden savings from changing to Open Source. Such as, we are running Pentium II computers for a year longer since we are running Linux, which extends the life beyond the cycle of expected depreciation. We can cycle in upgrades to hardware in cycles to prevent a one time expense on the balance sheet.
Then cover things like the amount of power saved with the older machines using less watts. For some companies, this could be $100,000+. EnergyStar has statics on this information.
I would also mention the recent losing of the source code for Windows along with the ability to break free of recurring charges with virus software.
In the grand scheme of security, it would probably be beneficial to note that spyware and corporate theft is less likely in a system that is unfriendly to script based theft schemes.
Mention that you don't have to worry about paying for MCSE for employees. You have no fears of employees stealing licenses.
No more formatting when a new employee inherits a machine.
The ability to disable Cd Drives remotely at will.
I guess that covers the basic things. I would give them all copies of Linux LiveCDs that they can take home and use on their home machines. LindowsLive is a good one to use. Let them see for themselves that it is not going to be a foreign OS, but just a slightly different OS.
I recognize up front that I may not be the most objective soul on the planet, speaking as a web/database developer working exclusively on a free software platform. What follows would be my list of potential gotchas concerning questions we've been asked by clients:
(1) Since you are a member of a company that's subject to rather scrutinous regulatory and privacy concerns, you would definitely need to develop a solid policy for code auditing. Yes, I tend to trust the core developers of most major projects to watch patches and such pretty closely (especially with OpenBSD and Debian), but mistakes can happen. You'd probably need to consider the cost of keeping an in-house audit team (a few good coders) to review new releases under consideration for your production environment. These people don't come free, but I'm pretty sure they'd be less expensive than (a) implementing the applications yourself in-house, or (b) going with a propietary solution (which costs money up front) and then STILL having to audit the code to be sure.
(2) In relation to item (1), I'd be sure to cover the fact that just because a company has a closed source product doesn't necessary make their developers any more trustworthy than highly regarded community development teams. Reference the Sybase backdoor debacle for some concrete proof that nasty things happen in Fortune 500 companies. "Having someone to sue" doesn't necessarily mean jack when your company is getting hounded by the Feds for improper information disclosure.
(3) I'd try to focus on tech segments where open source solutions are already extemely well tested and in general acceptance, such as Apache for web serving. Again, some internal problems may really benefit from a chained solution using existing OSS projects and toolkits, but these are probably a touch sell that would be better left alone until other projects are firmly grounded. Possibly exempt from this rule would be broad projects such as the Perl programming language, although you would probably want to add a policy subsection on module auditing as well (since CPAN is just so darned comprehensive).
That's about all I've got for now; I'm a bit tired from a late day/night of bug fixes. Hope some of this helps.
Sig: Seeking partnerships with web design firms.
I assume you won't be going open source for everything, but will rather evaluate on a need-by-need basis.
As you evaluate each need, some special questions apply:
- Legal: Do we want/need legal recourse if something goes wrong with this piece of software?
- Do we plan to extend and enhance this product ourselves? Are we willing to share our work with the larger OSS community?
And for each OSS candidate:
- Liveliness of maintainers: are they issuing regular updates? Are they meeting the needs of the community?
- Conversely, does our organization have the right skills to help update the software?
- Is the userbase big enough to ensure decent longevity of the product? (Safety in numbers)
- Do we need and can we get tech support that meets our SLAs?
There must be a bunch of other questions to be asked, but you get the idea. Again, I suggest you treat OSS as one tool to help you on a need-by-need basis, rather than the answer to your business' cost savings dreams.
What information do you think should be included to sell Open Source to management at the top-level of any corporation or business?
Ok, this is going to attract down-mods the way that posters named "I'mASingleGeekGirl" attract up-mods, but I have to say it.
Why should we care about "selling" open source for internal business use? Now, I don't blame Stokey for asking -- I'd do the same. And I guess if you're a *nix admin, the more companies using open source, the more business you have. Point taken.
But if you're not a *nix admin, why do you feel the desire to give free advice to a company that's never going to give you a dime? Why do we treat open source like it's a religion that we need to "witness" and proselytize for?
Sure, in a few cases, if a business starts using open source, they'll contribute code modifications back to the community, or maybe even hire a few coders from the community.
But in most cases, the company is just going to install linux and postgresql and Open Office and the open source community won't get so much as a thank you.
And besides, these businesses are forever telling us how much they know, how brilliant their management is, etc. If these men of brilliance can't figure out that $0.00 per seat is less than $200.00 (or whatever the figure is after corporate discounts), that few viruses and exploits are better than the never-ending waves of windows viruses, that never being audited is far less disruptive than repeated visits from the BSA, if the MBA geniuses tat run these companies can't figure this out on their own, why should we Slashdotters who aren't invited along on the expense account lunches sweat to convince them otherwise?
I mean, if no company ever used open source again, there would still be hobbyists producing open source code. and that's a straw man anyway -- companies that want robust servers already use linux in droves.
It's like we all grew up as geeks in hisghschool (ok, I guess we all did) and now that we have decent jobs and decent wardrobes and no more acne, we're still tripping all over ourselves just because a pretty girl -- the "legitimate" business -- smiles at us. How about saying to her, if you can't figure out why you should want me rather than the bloated slob from Redmond with all the viruses -- well, I'm no longer so desperate and lacking in self-esteem that I'll beat my head against a wall trying to convince you.
Again, I'm not saying we shouldn't try to convince companies to go with open source; we should. I'm just saying I think we shouldn't be -- we needn't be -- so desperate to do so.
Opinions on the Twiddler2 hand-held keyboard?
The first argument that I heard was "We will have to develop our own distribution" rather than rely on Redhat or SuSe or something like that. This is particularly true of financial institutions who must be very concerned with their ability to audit exactly what is on their machines at all times.
With open source comes the question from developers, "Will we be able to contribute changes back to the community?" The answer is almost always "No" in the big companies because they feel that it makes them responsible/liable for those changes. Worse, this sometimes develops into the black hole of "Get it off the net, integrate it into our stuff, then never say another word about it. Don't even get new versions [we don't want to be dependent on them], just treat it like it's been ours all along."
Lastly, in order to use open source app X, be able to show that a vendor exists who will sell you support for that app. I heard that almost verbatim from a boss once -- Why Tomcat over JBoss? Beacuse he knew where he could buy Tomcat support, but not JBoss. (Whether or not you actually can buy JBoss support is not the question -- the fact is that a manager's world is limited to what he has read in Business Week or who he has talked to at the latest trade show).
Oh, one more thing. Keep religion and philosophy out of it. If your company really does want to go open source, they are most definitely not doing it beacuse they want to contribute back to the community, or because they believe that it is the new way, or anything new agey. They are doing it to save money. Therefore, sell it like that. Don't push your luck.
www.HearMySoulSpeak.com
If a linux desktop is on the cards, why not do the better part of your presentation from a laptop with impress (open office powerpoint) and near the end of the presentation, you minimise open office and show them a ximian gnome, or nice KDE desktop underneath. Show them it is REAL.
I am a bit of a Gnome fanboy, but in the interests of OSS I'd say use a KDE that's been setup to be "windows-like" so they go "wow just like windows, but free".
On the server side, maybe setup a windows box and a linux one side-by-side and show them running a ContentManagementSystem (php+database) both on apache and say "the only difference here is a windows server license".
Sure IT overlords will want case studies and number crunching - but both Gnome and KDE and pretty impressive now for "wow" factor.
Detail how much of the size of Microsoft is also devoted to un-business like things - directx 9, games, drivers blah blah. And how there are people pushing a desktop "for business" that can have IMs, spyware, viruses etc. "locked out, so work can get done". Spartan systems are to your advantage here. "This isn't entertainment or home oriented, this is business oriented from it's base as a networked server operating system". Linux isn't a bunch of kiddies, it is system admins "trying to get work done".
Not to downplay the benefits an OSS VoIP/IM system could have on internal communication. Content management systems as "team work areas" that can be securely VPNed into to allow work from anywhere.
Play up all these things are corporate, not hacker made... even if they are not....
Play up Mozilla as an awesome productivity tool. "Funded by AOL and standards compliant this beast is all about a workers workflow management - take tabbed browsing for example".
"OpenOffice is driven by Sun as a standards compliant office suite - I am running this presentation on it"
"Redhat competes against MS server markets, and because they are specialised they do a better job"
"Novell is driving ximian to be the best work-force desktop - look at these colaboration options, compatible with MS servers too"
"IBM is putting their weight and experience behind this, and is swapping to linux internally themelves as we speak."
Get that "Unix industrial grade" aura rather than "community this and that".
I was thinking something similar. Starting your corporate Open Source proposal with "Well, the guys on this site called Slashdot said..." may not go over real well. :P
Social Engineering Expert: Because there is no patch for stupidity.
I don't think you're getting the point here. If you're talking about software that is so specialized that it's unique to your little niche, then yes, access to the source may only be important if you're equipped to do something with it yourself. But in that case a commercial version would likely be supported by one company, and woe unto you if they went out of business or chose to stop supporting it (perhaps to force you into an "upgrade"). With access to the source (and a license that allows you to use that access), you at least have the option of hiring someone to maintain or customize it. To say you'd prefer to put your business at the mercy of a single vendor, large or small, is just plain nutty, in my opinion.
For more generic applications there are several advantages to Open Source:
I personally don't care whether you or your company employs Open Source software in your operations, and I doubt that the developers of the software you're not using care very much either, since they're not selling anything (except occasionally support and packaging). If I were a shareholder I'd have some tough questions for you, though, because then it would be my money that you're farting away...