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.
> may be cheaply modified to fit your specific needs.
I question this since how much do you think its going to be in man-hours to have a programmer fix something in Wine or OpenOffice if my insanely complex budgetting Excel macro fails?
How many people in the world even have the skill to do this within in a few days? Is it possible, yes. Is it cheap? No.
>Open-Source Software is more secure because there are more people reviewing it.
Pretty bad argument for business. "So our security, and my job, relies on what people do in their spare time?"
>It's cheaper to use Free/Open-Source Software.
It might not be if you have to retrain people to use it. Even with free training, the employee's time cost. They already know how to use their existing OS and applications.
The surprise isn't how often we make bad choices; the surprise is how seldom they defeat us.
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".
And if not -- has anyone pointed this out to your lawyers?
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.
Biting this troll, I ask:
Why is it better to pay for a support contract to use another companies geeks than your own? The other geeks are looking out for their corporate bottom line, not your bottom line. They have no vested interest in your success or failure. Every customer is just like the other.
In-house geeks should have a bit of loyalty to the provider of their next paycheck, they are focused on one company, and since they are already on the payroll, use these talents.
As a 3rd tier support geek, I spent many a fruitless hour on hold to the commercial-entities. It was more cost efffective to send us to vendor training than to rely on the vendor's helpdesk. Many of the issues ended up being resolved on the vendor's public forums. Why should the corporation pay big bucks for what is essentially a vendor supplied forum reader.
The step from in-house Cisco, Lucent, Openview/HP-UX and MS support to adding in-house linux, mySQL, and mrtg support was a natural, easy step. Searching the Microsoft KnowledgeBase or searching google for a SQL server error takes about the same time and effort - having to parse the google responses balances out the hoops MS makes you jump through.
The Subject matter experts tend to be those who use the product daily, not those who just read canned answers from the helpdesk ticket system. Sourcecode has nothing to do with it.
Why is it better to pay for a support contract to use another companies geeks than your own? The other geeks are looking out for their corporate bottom line, not your bottom line. They have no vested interest in your success or failure. Every customer is just like the other.
Ok. The support contract is like insurance. You use it if you have problems, you don't if you don't. The alternative approach to buying insurance is to self-insure. Essentially put a stack of money in the bank to spend when you have problems. Only really big companies can afford this. Likewise, if you have a sticky problem with software, you need some expertise. You can either pay to have that expertise at your disposal when you need it by calling the vendor or pay to have that expertise stockpiled in house. If you never use it, you lose. Further, since we're talking knowledge, not money, it's easier for the vendor to stockpile that knowledge. Gaps in any individual's understanding are more likely to be filled by somebody else on that team.
A large corporation may be able to self-insure with knowledge as well. They have a ton of people babysitting products and get to learn them very well.
The downside to that from a manger's perspective is that if something ever goes seriously wrong, they don't have anyone to blame but themselves. There's no lifeline to grab onto and force to make it right. It is because the vendor's people act with the vendor's best interest in mind - they need to keep your contract - that they are strong. Clearly some vendors and some contracts are better than others about this sort of stuff.
Remind me again why you'd send off a .doc file in the
first place. You want to send a document to someone,
why not pdf it. It preserves formatting more consistently
than Word, which can even crash opening docs saved in
Word. Save your customer some grief and use pdf.
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...
This is tangentially related, but the seven areas in which he measures benefits to a business of going green can give you ideas about selling OSS to businesses.
There's a good chance we could make a case for OSS in the three main drivers he identified:
One last, important point: the author pointed out how many of these companies (and he only surveyed high-tech ones) kept finding high-ROI opportunities. Go after the low-hanging fruit, stuff that makes a measurable impact in under a year. You'll get better at finding them.
Information: "I want to be anthropomorphized"