How Would You Argue for Open Source? 511
Nate asks: "I am currently working for an international corporation, and the site I am working at was (until very recently) entirely run on Windows. We recently purchased a Solaris server, and I am in charge of setting it up and resetting the global UNIX standard. The problem is that management doesn't want to install software that does not have 24 hour, worldwide support available along with it, yet they want the capabilities that only open source software can provide on a UNIX platform (VNC, OpenSSH, etc..) without spending insane amounts of money. I was wondering how the Slashdot community deals with convincing management that Open Source software is safe to use when creating a global standard, and what your solutions have been to supporting users working with open source software." Two years ago, Slashdot tackled the Enterprise Support question. Now, say you had that particular problem solved and the only thing left is that all-important pitch to Upper Management. What arguments would you use in your attempts to get their approval? What statistics and references would you point to, in order to back everything up?
changing minds, not easy (Score:3, Offtopic)
It usually ended up in me in a shouting match
Re:changing minds, not easy (Score:3, Insightful)
My approach is to address the FUD right up front. Fear of license, fear of lack of support. Guess what? We don't have any now!!!
Re:changing minds, not easy (Score:5, Interesting)
Anyhow, my tenure has been at a large document and imaging company, a not-for-profit professional organization, entertainment conglomerate, internet security development company, e-learning and training company, a small IT consulting firm, and now a large energy company. The easiest minds, at least I encountered, were at the small companies, less levels of crufty management to deal with. It also counted that I had a bit of autonomy in driving the technology vision, mainly because whatever I was tasked with "had to get done". So, I think size combinied with mission critical decisions may help leverage a case.
The "shouting" match occurred at the entertainment company and at the not-for-profit. The first was in the case of some top brass brought in to trim budgets, where we had everything successfully running on open source stuff (which used to run on expensively leased Sun hardware [E250] and software) but was moved to some discarded Acer desktops and FreeBSD. THe stuff ran better and without any hassles on the open source stuff, but because these jokers couldn't get out of their lease with Exodus for the hardware, I was told to support the Sun environment or walk out the door, I chose the door. The latter, in the not-for-profit, the shouting match there ocurred with one of the three (yes three) IT Directors we had there during my tenure. He didn't like the idea of open source at all, in fact, that old argument of "I can get a manager from Sun on the phone 24x7" for support was met with my retort "yes, but can that manager ever give you a technical solution. WHen was the last time he sat in fron of an E450 wondering what happened to the OS when it took a dump". It was later brought up that the organization supposedly didn't run any open sourced software for important tasks (he'd been there about 4 months at the time) and I think he took a look at our SUn, Windows, and Apple machiens at the time and thought that, but I said... "well, what about Sendmail...", he replied, "well, that's and exception...", "then how about BIND?","um, well", "and Perl?!", "well, that's not... but um..."... suffice it to say, making him look bad during a pissing contest in front of his subordinates in the meeting room was not a good way to intorduce myself. He later quit after not feeling he "fit in" to the organization (that, and he physically assaulted me when a hacker broke in through a few of their misconfigured Windows and Sun servers, then got yelled at by the president of the organization... I think his name was Terry White)
I think the best thing to do is to subtlely play to Open Source software's strengths... I wish you well.
Red Hat, et. al. have 24x7 support too... (Score:5, Insightful)
What options do you have with proprietary software? Well, you can guess at what's causing the problem and change configurations. If the problem is an actual crash or something, you can reboot, reinstall the offending program, reinstall the OS. If none of that works, you can call the vendor (who will start by having you follow those three steps, along with applying patches, blame the hardware, etc.). The vendor may or may not be able to help you. Further, it is entirely up to them whether they give you real support or not (for example, if behavior is considered to be a feature, you cannot make a software vendor change the behavior). If they choose not, then there is no recourse for you (other than switching software).
A university where I worked considered switching to one of those MS license all your software from us and we'll give you a really great deal. As part of that, they considered moving the yellow page servers to the MS product. The deal was sold, they were ready to start. They asked MS to make a tool that would convert a flat text file generated from the information stored in the previous software's format into the MS format and MS refused. They had a nice point and click interface, and they expected the university to manually retype 60 *thousand* accounts with it. An overnight batch job would have become a multi-month project. Yellow pages info now resides on OpenVMS boxes with a custom written interface that took a couple of weeks to design.
Re:changing minds, not easy (Score:3, Funny)
"d00d, LiNux iz ub3r!! M$ W1nd0ze sux0rz!!!"
when XYZ corp goes out of business... (Score:5, Insightful)
Worked for me.
Better have the resources though (Score:3, Insightful)
Re:Better have the resources though (Score:3, Insightful)
Re:good idea (Score:3, Informative)
SCO is a linux problem, not a BSD problem. Berkeley settled with SCO a decade ago.
You could start by asking them ... (Score:5, Insightful)
Re:You could start by asking them ... (Score:5, Funny)
Re:You could start by asking them ... (Score:5, Insightful)
Lastly, a lot of these management types are generally 'Net-illiterate and view everything outside of AOL as a cesspool of viruses, hackers and obscene pornography. Not the source of anything remotely resembling troubleshooting. I suspect this perception will remain a problem until the tech dinosaurs have all retired.
So you have to sell them a high-quality call center staffed with dedicated pros. Or as a previous poster said, ask management if they want to guide the company according to their business plan or according to the plan of their OS provider.
For stats, see "Why OSS/FS? Look at the Numbers!" (Score:5, Informative)
Re:For stats, see "Why OSS/FS? Look at the Numbers (Score:5, Interesting)
As far as arguing with upper management, when I was working in cubeville, I never worried about it. I just implemented it the best way I knew how, and presented it as a completed solution.
Once the solution is in place, nobody ever seems to worry about it. Then at some point in the future, it's easy to point to it and say: "but we've *been* using open source all this time, and don't have problems with it".
I think that's still the most successful implementation strategy. It's the one Microsoft used for pushing Novell out of mid-sided businesses.
Re:For stats, see "Why OSS/FS? Look at the Numbers (Score:4, Insightful)
What makes you think that those developers were making "off-the-shelf" applications? It's likely that some of them are, but I'd wager that most are meant for internal use.
Re:For stats, see "Why OSS/FS? Look at the Numbers (Score:3, Informative)
Of course, the results will probably be scripts and libraries, rather than full applications, because the full applications are generally very company-specific.
Re:For stats, see "Why OSS/FS? Look at the Numbers (Score:5, Insightful)
Heck, I expect to write a Linux app in the next year. Frankly, I expect to be doing it in under 6 months. And nobody will ever see it since it's the core infrastructure for a service my company is offering. Pure backend stuff.
The vast majority of software written is not written for the commercial marketplace. It's written for inhouse use.
Re:For stats, see "Why OSS/FS? Look at the Numbers (Score:4, Interesting)
Or embedded, or targetted at a specific industry. I've got *mumble* years of experience working on plenty of software that was sold to customers. It was written for specific target markets. It was never the sort of stuff that would fit in a shrink-wrapped box on a store shelf.
Anyone writing code that isn't targetted at desktop users (embedded, turnkey, server, etc.) who doesn't at least consider open source platforms is overlooking a possible area of cost savings.
Re:For stats, see "Why OSS/FS? Look at the Numbers (Score:3, Informative)
PeopleSoft [forbes.com] is on its way - a pretty significant addition to the Linux world, I think...
Yours,
tom
Documentation is the key (Score:5, Interesting)
Your company wants to make sure that anyone who might administer those servers has access to the information they need to fix any problems that come up if the person who initially installed the software falls off the earth.
A 24hour support line is one method of getting that support, you just have to show that there are other less expensive support routes that are just as viable.
If need be remind your boss that it is your ass on the line if something goes wrong with the servers and you'll be the one showing up to work at 4AM on a Sunday to fix the issue.
Re:Documentation is the key (Score:5, Interesting)
These are the real issues: there's a way that corporations work, a corporate culture which is comfortable with familiar things and very, very uncomfortable with unnecessary risks. Using the traditional vendors - Oracle, Sybase, HP, Compaq, Cisco, Microsoft, Sun, IBM, SAP etc. - means dealing with other corporations like themselves, with all the systems of accountability you associate with them. With few exceptions, dealing with open source solutions means dealing with grad students' summer projects - perhaps very well written ones, but with no real systems of accountability, no roadmaps, no certifications (except very questionable third-party ones) and so on.
The way to sell open-source is *not* to sell open source. It's to sell complete, integrated solutions built on open standards (that just happen to be free - although I wouldn't even mention it, since most everyone believes you get what you pay for) - you quote a cost for the *total solution,* hardware and software, training and support and TCO over n years, versus the cost of the existing solution, and you enumerate - and, if possible, quantify - the problems of an existing, closed source solution and the benefits of the new solution. That's *it.* If you want to go on after that, have case studies handy, the more the better. Do *not* talk about installers or Gnome or skins or distributions or customizability or network transperency or anything like that - you'll sound like an idiot.
Re:Documentation is the key (Score:3, Interesting)
And when they sent me install instructions it was often pages of: ln -s, perl scripts ( some of which I wrote ), etc.
So if someone is laughing at your install instructions because it is *gasp* box specific, then they really don't know shite about how stuff actually gets don
back down, tiger. (Score:5, Interesting)
I did not see anything about demos, installs or Gnome skins outside of your flames. Nor was there any good reason to flame free software as a "summer project".
Your points about presenting a whole solution are useful when you need to replace a whole system in a lethargic micormanaged work environment. All that "Oracle, Sybase, HP, Compaq, Cisco, Microsoft, Sun, IBM, SAP, etc ... certifications" blah blah is so much dated marketroid bable with good bad and out of business mixed up. Wake up boss, HP is Compaq, Microsoft is worthless, Sun is good and IBM uses Linux. Well, OK, You've got a point about selling a "solution" in such an environement. It's negligence to not do your homework about the bottom line anywhere.
At the same time, it's a good idea to talk to people you trust about what free software is all about. It is important that management understands that free software is simply a co-operative community of software writers and users. They should know that such communities have always created the software that some companies tried to comercialize in a closed source way in the 1980s. The closed source experiment is just about out of gas, becasue the free software community has ignored it to create viable alternatives. Corporate managers understand co-operative research as well as they understand bottom line issues. Free software is not such a great leap at reasonable companies and most people are tired of being jerked around by comercial software pimps.
Re:Documentation is the key (Score:4, Insightful)
Interesting claim. You think that a company with 800 stations can call microsoft and have them send somebody out to fix the problem. That's the size of a small hospital. Go ask your hospital how responsive Microsoft is to their demands for support of flaky software.
Re:Documentation is the key (Score:5, Insightful)
No kidding. Upper Management never seems to remember it's not THEM building the network, it's you. So they're concerned about how THEY will look if something does work, well, that goes both ways. If YOU are setting up a crap network, not only will you be the one coming in on off-hours to repair it, but your voice will carry less and less weight as it gets worse and worse..
That actually piggy-backs the consulting Ask Slashdot from a few weeks ago.. If you're going to get stuck supporting garbage, and you know it, speak up! While the money may be good in the short term, the company will probably pay someone else to put something new in because you've been associated with the garbage.
Begging the question (Score:5, Insightful)
Buzz words. (Score:4, Interesting)
She's right. (Score:5, Insightful)
So give her estimated labor costs of installing and supporting MySQL vs cost of purchasing, installing and supporting Oracle. Don't forget hardware costs.
Re:She's right. (Score:2)
Re:She's right. (Score:5, Insightful)
And don't forget to include the cost of porting your app to Oracle when some developer finds he has to use a subselect or a trigger or a distributed transaction
Re:She's right. (Score:3, Insightful)
Well, you know it's not gonna be the guy who suggests MySQL, because he/she doesn't know shit about databases. ('What's a trigger?').
Good post. Wish
Back to PL/SQL...
Re:She's right. (Score:5, Informative)
MySQL has many strengths, but reliability on an enterprise scale isn't one of them. MySQL is best suited for "edge" services, or for convenience services in-house. Oracle may gouge you for every cent they can, but there really aren't any databases that can compete with Oracle for enterprise features.
That said, TCO shouldn't be one of your arguments. In my experience, the best arguments address the suitability of the package/software to the problem, the ease of deployment, and scalability. Every time I've heard someone bring up TCO, somebody else asks about support. And USENET is not a suitable answer for most technical directors. If your company uses Oracle, BTW, you should point out that Oracle's recommended platform for new installations is Linux. You don't get a much better endorsement than that (at least, as far as your bosses are concerned).
#include "disclaimer.h"
Re:She's right. (Score:4, Informative)
No, it's GPL.
It isn't quite that simple. The problem comes if you want to distribute an application with a mysql backend. Because not only is mysql GPL, but the ODBC and JDBC connectors are also GPL. Which means your application has to be GPL, otherwise you have to pay Mysql AB for the license that let's you distribute a closed source application with a MySQL backend.
Read the licensing section on MySQL AB's site.
Re:But she's a bitch. (Score:4, Interesting)
My point - there are many more factors regarding Total Cost of Ownership and young support jockeys need to get with the program. This isn't some geekfest where we all trade D&D stories while chewing on the latest OSS install. It's called business and time costs money. You don't like that? Find another way to pay the rent.
Personally when I got into this industry I also swiped aside everything management spouted as just "BS". Then I grew up and realized that a lot is riding on things we take for granted. You might think it's easy to run a business but it's not. _Everything_ affects the bottom line and has associated risks and there is no way around that. Identifying and quantifying that risk is part of the process of making an informed decision. Would you rather they just shot from the hip and hope to hit the target?
You better learn these acronyms and use them to your advantage if you ever want to play with the big boys. OSS solutions CAN compete with proprietary solutions in the TCO arena. But who is going to get them into the arena? Learn the lingo and play hard ball, or go whine in the corner about how everyone else is a bitch like you do now.
Re:Buzz words. (Score:5, Insightful)
This is why most pure tech people generally cant get things done (or done "technically" right); because they sometimes have an inability to provide things that are asked for.
Management and Tech are two different languages. Your boss was telling you how she wanted to explain it to HER bosses, and you basically said "oh, I dont feel I need to". Well, when she doesnt feel like listening to your suggestions in the future, you will know why.
I get ahead by making my boss's job easier, not harder.
Re:Buzz words. (Score:4, Insightful)
Now what happens when you're on vacation? What happens when you've left the company? How does additional staffing (and training, since it may be very difficult to find a MySQL guru as smart as you might be) factor into your costs?
The point is, from an enterprise management perspective, things aren't as simple as some of us think. We think, yah, I can support this pretty easily. I haven't had a problem yet with it that I haven't been able to resolve (given enough time). Now ask yourself if that's sufficient for the project, or if you're going to need something or someone else to fall back on.
The "guru" support model works very well for smaller businesses, but frequently has major problems scaling to support an enterprise.
Now, I'm not saying that you (or someone else) might not have problems with this anyway (given that MySQL is actually fairly popular), but others reading this might not have the same luck with any OSS project. Just because the source is available doesn't mean it's cheaper to use than a commercially-supported product.
You can get that type of support (Score:5, Insightful)
.:diatonic:.
Put the developers on a retainer (Score:5, Insightful)
Re:Put the developers on a retainer (Score:4, Insightful)
First of all, this may not be possible at all. The people in question may have full time jobs, or other commitments that prevent them from offering personal support. In many cases, these people may not even live in the same country or even time zone as you.
Secondly, good programmers don't necessarily make good support staff. They may simply not enjoy the work.
Thirdly, you're imagining a low monthly fee for support. Big commercial vendors can afford a low fee because you don't really need their services most of the time, and the cost of their staff is amortized over many clients. A programmer who needs to stay on-call for you 24/7 may cost a lot more than commercial support, which can defeat the cost savings of using free software.
Finally, your idea obviously doesn't scale well at all, once more than a few companies do this.
Re:Put the developers on a retainer (Score:3, Interesting)
It may not work some of the time -- hell, it may not work most of the time.
But, if it works just a few times, everybody is indeed a winner. The developer (team?) gets some extra dough to work on what has been happening for free. The business gets some support. The developer gets feedback on what's buggy / slow / needs improving. The business knows it has the expert if it wants to spend a little cash and get additional features.
I agree, it won't be the ideal route very oft
Oooh I know (Score:2, Flamebait)
I'd whine and bitch about how bad M$ is, I'd point to the Developers Developers Developers movie, I'd make fun of Bill G's hairstyle, anything other than features or facts! After all, that's how open source is usually promoted.
Troll? Hardly, perhaps a flamebait, but go look at the longhorn story [slashdot.org], then tell me I'm wrong...
Superior! (Score:3, Insightful)
Re:Doesn't apply to GUI's (Score:3, Insightful)
Half-assed GUI's are not the exclusive domain of volunteer Linux projects. "Serious commercial enterprise applications" have the same problems.
Support and Code Openness (Score:3, Insightful)
Upper Managment does not grok Geek. (Score:5, Insightful)
Cost: Cost of rollout of a commercial product is comparable or more than the cost of 3rd party support contracts for open software.
Risk Management: Buying proprietary software gives you support, but the support is with a monopoly supplier who can then choose to charge whatever it wishes down the road for both software upgrades and support. Tying yourself to a monopoly supplier is a poor risk, since every move a monopolist will make will not be for the benifit of your company, but for the benifit of thiers. Similarly, with Open Source, since our company has the right to modify the software, every change you make will be for the benifit of your company.
Upper Management does not grok Geek. Upper Management groks Dollars and groks Risk.
Just keep that in mind.
-- Funksaw.
Re:Upper Managment does not grok Geek. (Score:3, Insightful)
It cannot be stressed enough how important those buzzwords and acronyms are. TCO. ROI. Risk. If you want to get a certain OSS software package to be put in, you need to make a case for it. Simply saying "This OSS x is tons better than this company's y software. w00t." is going to get
redhat (Score:4, Informative)
that only open source software can provide on a UNIX platform (VNC, OpenSSH, etc..)
VNC and OpenSSH are available for windows so they might not be convincing. Try using ROI and TCO as persuaders.
Re:redhat (Score:5, Interesting)
"Except as otherwise permitted by the NetMeeting, Remote Assistance, and Remote Desktop features described below, you may not use the Product to permit any Device to use, access, display, or run other executable software residing on the Workstation Computer, nor may you permit any Device to use, access, display, or run the Product or Product's user interface, unless the Device has a separate license for the Product."
Great grounds for an anti-trust suit... (Score:3, Interesting)
Triple damages, mmm.
--LP, who doesn't mind MS software actually, but *hates* the EULAs coming from that lawyer's-son Gates.
Re:redhat (Score:3, Interesting)
Except that it's not technically illegal: I'm not using the Product (Windows XP) to permit another Device to use/access/etc. the host computer, I'm using a different program. Similarly, their restriction on using other devices to use/access/etc. the operating system is so overly broad as to be completely unenforceable. Under the terms you quoted, technically you'd need another license for your monitor, mouse, and keyboard. Each. Additionally, do you really think they would get away with requiring separa
IBM (Score:5, Insightful)
I wouldn't even bother. I would call the local IBM Global Services office and ask them to pitch for the job, and dangle the carrot (whether it exists or not right now, it might to in the future) of outsourcing the management of said Open Source infrastructure to them. I assume that you don't actually care who runs it from day to day just so long as it's Open Source. They'll make a far more convincing argument that you can alone - remember they employ people full-time to do nothing but research and put together fancy presentations (as do all consulting firms... you don't think the slick performers doing the presentation will actually show up to do the work, do you?).
Re:IBM (Score:2)
Re:IBM (Score:3)
I've worked with IGS before. They aren't in any way constrained to use IBM technology, they're a completely distinct P&L. Last job I used them for was implementing BEA WebLogic on Suns! They'll do anything they can make money at.
Re:IBM (Score:3, Insightful)
IGS has a good reputation for supporting whatever you happen to use. However, you can't expect the fine folks at IGS to be real excited about selling your boss on the idea of using OpenSSH and VNC. Those guys are salesmen, and they will undoubtedly see that your boss is wavering on the idea of using Free Software to fill important roles. A few quick sales pitches from the folks at IGS about some really neat IBM tools and VNC and OpenSSH are torpedoed (never mind that VNC and OpenSSH would be cheaper and
Ask the right questions (Score:2)
1. For what kind of server[s] do you want OSS adoption
2. How many of them are deployed
3. etc etc
Then, rate these in order of importance, and your bullet point cost/benefit arguments to the director or executive will be more succinct. You see, you don't want a hodge podge of OSS evangelizing, you want relevant points given the specifics of your organization.
Or, if you just really want
Testimonials (Score:5, Insightful)
What you need are testimonials from others running mission-critical applications using FOSS.
One Fortune 500 executive won't achieve comfort with this kind of a spending and deployment decision (face it, they don't know the tech) until, unless, and, only if, they have seen more than one other Fortune 500 executive put their own necks on the chopping block, made a courageous decision, and have it succeed wildly with no glitches whatsoever.
Getting those testimonials might be hard for an individual on their own ("Mr. Big's office, how may I help you? Right...."), but the web is full of articles showing different businesses using FOSS successfully.
If you were tied into a vendor with a lot of FOSS contacts (eg, RH, IBM), then they could probably help you find those important reference testimonials. Sun is late getting on board the FOSS bandwagon, despite having produced a lot the standards and technology that has made it possible. Their Solaris servers will run FOSS just fine and interoperate with Linux machines, etc.
If they want 24 x 7 x 365 support... (Score:5, Funny)
Form a new company with you as the only employee.
Submit monthly invoice for $50,000 to your current company for "OSS Platinum Support".
Sit back and watch the money roll in.
This works to your benefit since they'll probably call you at all hours of the night to initiate the support call, anyway...
- Tony
Re:If they want 24 x 7 x 365 support... (Score:3, Interesting)
Re:If they want 24 x 7 x 365 support... (Score:4, Funny)
"Oh Gee, we're out of business. The SAMBA team decided not to work on it anymore, they're writing a Pokemon clone now".
Naaah. Won't happen. None of us likes Pokemon anyway
Now if you're talking Unreal Tournament.....
Jeremy Allison,
Samba Team.
Re:If they want 24 x 7 x 365 support... (Score:3, Insightful)
With the way which stock markets currently operate anyone assuming that a stock price tells you anything about the state of financial health of a company is probably a fool. Especially where there are no dividends being paid whilst there are all sorts of stock options in place.
When it comes to Microsoft, IBM or Oracle, there's little doubt that the company will exist lon
Closed Source Track record (Score:5, Interesting)
- Closed source has more bugs, and the exploits are typically more severe.
- Actual turn around time for Closed source is much slower than open source for new features and enhancements.
- Closed source hampers IT productivity as the fear of sharing "Intellectual Property" infects and permeates many people that work in closed source environments
one of my favorite all time articles is written by Clay Shirky, entitled In Praise of Evolvable Systems [shirky.com]
This article addresses what many people consider to be open source's weekpoint. It is however it's strongest point. This is a fantastic read and is a must in any presentation to management about open source and open standards in general.
Go look into a mirror.... (Score:5, Funny)
Use pilots and quantifiable targets (Score:4, Informative)
We have a number of clients, from mid- to large enterprises, who have switched to *NIX/Linux over the last 3 years following our advice. The key for us was to define quantifiable targets in terms of $$$ and time-to-resolution, and kept statistics of similar environments running Windoze or commercial *NIX software.
Two test cases that immediately come to mind are Samba and VNC. In the first case the monetary quantification was instant: $0 against licenses for a 75-person department. There were no calls to support at all once we switched the servers. For the VNC case at another company, we pitted it against PC Anywhere. Once users understood the new logon sequence, they began champion VNC by themselves because they realized that *NIX machines and Macs were opened to their control, some of which had been closed before.
Both of my examples focused on solving specific problems, with a set time line and quantification targets. Don't try to implement everything in one single deployment because if something non-mission-critical breaks that affects a mission-critical app or service you'll invalidate your own case.
Good luck and have fun!
E
Fellas, (Score:2)
We all know *NIX is easy to administer and troubleshoot. That's not the problem.
Consider a company that contracts out support and/or deployment. They'll be more or less liable for downtime.
Re:Fellas, (Score:3, Insightful)
The whole "gives us someone to blame" is a complete crock of manure. I used to write software for government apps... they always built a one year warranty into the product. Guess what we spent most of our time doing? Trying to prove a reported bug was actually a request for a new feature.
As far as contract support goes... tho
It was easy (Score:3, Funny)
Go with a vendor that supports linux (Score:3, Informative)
I like my cubicell mates answer: (Score:5, Funny)
You just can't beat (Score:5, Informative)
http://www.aaxnet.com/editor/edit021.html
That is his latest. Look around on the site a little. Lots of stuff there with many current references.
say to boss: (Score:2)
What Not To Pitch to Upper-Management (Score:2, Funny)
CIO: My techie's say that UNIX is the best and is backed up by the entire Slashdot community.
CEO: Your telling me that you trust techie's over marketing droid's?
CIO: Yes, sir.
CEO: Your fired. Have a nice day.
Updates (Score:5, Insightful)
With open source, you can patch whatever version you're running, or just upgrade whatever is necessary without the draconian eulas.
Jason
ProfQuotes [profquotes.com]
You know what's funny? (Score:2)
Please preach your religion somewhere else.
you = boy scout: be prepared (Score:5, Insightful)
They'll ask you "Why not Linux?" Have an asnwer.
They'll ask you "Will it work with our existing Windows infrastructure?" Answer that as well.
They'll ask "How much will the rollout cost?" Better have those figures handy.
They'll want to know "Why not just stick with Windows, especially since Windows 2003 is about to ship?" Have a retort ready for that.
They'll want to know (if they're savvy) how the data crunching numbers will compare UNIX to Windows, MySQL to MS SQL. You'll want that handy, too.
And finally, they'll want to know why should they switch to a different platform when they're already so heavily invested in Windows. Got an answer other than "Windows sucks"? You better know those things, becuase bosses aren't about to "just take your word for it" they demand facts, figures, and spreadsheets for proof--and if anything goes wrong it's your ass. Switching is fine, but you better be ready for the backlash and have oodles of proof ready or the resistance will be an unsurmountable chasm.
Stop talking about Open Source (Score:2, Insightful)
Use clear cut facts. Show the TCO, show the support channels, show the migration cost and schedules, provide a backup plan if things go pear-shaped, etc. Basically, the FACTS. And while you are at it, keep your own mind open. Y'know, often, closed sou
Cost Analysis, Sell, Sell, Sell (Score:5, Insightful)
Next find your open source "products". Then find developers who are very comfortable with the "products" that you are recommending. Factor in the cost of hiring them and their salary on an on going basis. They will be your "support" team. Also factor in hardware if needed.
The first hurdle is to prove that it will cost less or at the very least no more than the "off the shelf" products. Then you'll need to put your sales hat on and do a side by side "feature comparison" of the OSS alternatives to the products that you evaluated.
Most of all, be objective and very matter of fact about your presentation. Prove to them that OSS is the way to go becuase it costs less to aquire and maintian and has an equal or superior feature set. Apache is a great case study...
Good luck!
Comment removed (Score:4, Insightful)
Try Sun (Score:2)
My experience (Score:5, Insightful)
They had two concerns about open source solutions: 1. There is no company behind most open source solution. No company means no tech support. 2. OKI was just getting off the ground and would not be ready for prime time for a while.
Over a year later, the university finally chose a company to go with for their authoring system. We paid for a 30-day trial and got 5 days into it before we realized their marketing people had straight-up lied about its feature set.
So, we went with the company our university had ranked number two on the list. We worked with them for 6 months, hired one of their people to work for them on a university paycheck, and gave them a substantial fee every month for licensing. Then the company decided to get out of the authoring systems market, pulled our license and left us with nothing.
In the meantime, OKI has picked up steam, and the 11 universities that got on early with them have been developing solutions that will soon be GPLed.
The long-short is that having a company behind the product is a double-edged sword. Sure, they could give you tech support, but what happens if/when they're gone?
Examples like Apache & Linux (Score:3, Informative)
Red Hat "Enterprise" edition (Score:3, Informative)
If you're looking for "enterprise" level support (God I hate that word!), Red Hat [redhat.com] offers exactly what you're looking for, from what it looks like. Maybe you should give Red Hat a call and get one of their sales people to pimp themselves to your boss?
No contradictions.... (Score:3, Informative)
"Worldwide and 7*24h Support" and "Open Source" are no contradictions. I think we (NetUSE [netuse.de]) are not the only company to offer support for Open Source products like SSH, Squid, Apache etc.
Typical customers purchase support like helpdesk, patch services or (espescially for Solaris) packaging.
It's not a lot of work to offer SSH packages that you can remove and install in a newer version without a new host key. But it's those small things a lot of customers pay gladly for.
Thanks to Open Source and the community, companies like are ours usually faster with patches than a lot of other big software companies i could name.
On the other side the Open Source products get a benefit when enhancements on the request of customers (LDAP support here, there another command line option) find their way back into the community. I believe this is win-win at its best.
Open Source says "you can patch/modify/package it by yourself". But it's not a holy duty to do so.
Yours, Martin
P.S. If you want to use OSS and don't know where to spend your huge support budget, feel free to contact me ;-).
24 Hour Linux/OSS Support (Score:5, Informative)
No, I don't work for them, but Linuxcare [linuxcare.com] has a professional looking website using the CEO-lingo that might comfort the big-wigs you need to convince. There are other companies that support Free Software too, check out Red Hat's Support Services [redhat.com]. A site called OpenEnterprise [theopenenterprise.com] looks to have a ton of resources on exactly what you're asking for.
Also, take a look at IT Management's special report on Linux [earthweb.com]. It offers a lot of ammo to you in making a presentation. You can point to the other heavy-hitters that are using Free solutions and have concrete examples of success.
The same site even has an article entitled Selling the 'Suits' on your IT project [earthweb.com] which looks to have some good advice for you.
Maybe management has a point? (Score:5, Interesting)
Most Open Source advocates really need to think about something before they go charging in assuming OSS without vendor support is really better for all situations: Management wants 24x7 support not because they think the software is unstable, but because they cannot afford downtime when that software does fail.
"So what?" you say, "I've been using this stuff for years and I can solve pretty much any problem they might run across. I am 24x7 support!" What happens when you're gone? On vacation? What happens when you get burned out and sick of being the only guy capable of supporting an application that's taken off in the enterprise and now has a hundred installations all over the world? What happens when you have trouble finding someone with the skill sets needed to replace you?
This "guru" support model simply does not scale. This is why management wants 24x7 support: so that no matter what happens to their gurus, they always have a toll-free 800 number to call to get someone that knows what they're doing on the problem. If that person can't solve it, a good maintenance contract might even involve getting the vendor to fly an engineer out there to fix the problem. This is very much about making management feel good about getting the support they need to solve their problems.
The alternative is to spend an exceptional amount of money training a staff equivalent to the staff of the vendor to be just as smart and available as a vendor offering 24x7 support. It's not just about hiring two or three strategically-placed gurus.
Now, with that out of the way, OSS can still work in the enterprise, provided you approach the situation intelligently. Can your organization staff up a support group internally to support this application without requiring a maintenance contract with a vendor? (And can you keep them busy enough to make it cheaper in the long run?) Certain skillsets are pretty common nowadays, such as administration of Apache. It may be perfectly realistic to be able to staff up a small group to support common OSS applications in an enterprise. If someone leaves the company, it's realistic that they can be replaced or someone else trained to fill the vacancy, but you can never count on being able to hire a small army of "gurus" capable of adapting to any OSS application at the drop of a hat. This is very unrealistic (not to mention extremely expensive).
But not all OpenSource projects fit into this category. Frequently they'll be smaller projects that might be used plenty on the Internet, but either because there's a guru out there actually setting it up and administering it (that can adapt to just about anything), or because the author made it exceptionally easy for a novice to get it running. Neither of these options is acceptable in an enterprise setting! Your guru won't be there forever, and your army of novices won't have a clue how to fix a novice-friendly application when it breaks.
The bottom line is that you need to consider your company's true support expenses here: if an application needs 24x7 support, you either need to have a staff of people on-hand to guarantee support for this application (across your enterprise), at a significant expense, or there needs to be a vendor out there willing to assume 24x7 support for a fraction of that cost.
Dont lean on technical points. (Score:3, Insightful)
Personally, in your position, I'd build several possible scenarios...
That would be a minimum, the important thing is that every one of them has to achieve what the company needs. The costs will differ, the risks will differ, the long-term implications of things like scalability will differ and these will all play into the management viewpoint. They dont care how "good" the software is or isnt. All you can do is the risk analysis and the cost/benefit presentation, making them aware of precisely the levels of risk each solution exposes the company to and precisely how much it will cost to avoid those risks. Every software package is a risk, whether open source or not. Every piece of hardware is a risk. Lose your main production data server and how much business do you lose per hour whilst its down? How long will it take to get it back in each of your scenarios? How likely is the outage in the first place? Since every solution you present meets the same needs, does it matter which one they choose?
Now, my personal opinion based on experience in the past is that when the analysis is complete the case for open source in at least some of the application areas of a unix environment will be a complete no-brainer. As you work up the results, however, you might be surprised at some of the places it doesnt give an appreciable benefit. Remember that the time you spend scripting and configuring stuff is part of the cost, as is employee learning time. Dont leave anything out. Be absolutely straight presenting the best comparable info you can and dont try and slant it either way. If they make the wrong choice and it bites the company in the butt it then wont be your fault, even if the wrong choice was your recommendation too.
CIO magazine: great stuff for top management (Score:3, Interesting)
"We will guarantee the same [service-level agreements] for Linux that we do for proprietary OSs," says Dan Frye, director of IBM's Linux Technology Center. "Response times, fix times, uptime--we'll sign all those same contracts for Linux."
That pretty much says it all: 24/7 support with contractual guaruntees for Linux. There are plenty of other places willing to do similar for other open source software. Best point though: if you don't like the vendor you first choose for that support, you can actually pick up and move to someone else WITHOUT changing your software too!
The Fait Accompli Route (Score:3, Interesting)
I was once working for a leading financial information provider (>16,000 employees), and I was tasked with setting up a listserver, at minimal cost (read no expenditure beyond the cost of my own labour). I ended up opting for an open source SMTP-based listserver, which was far cheaper than the closest closed-source equivalent (free as in beer vs. over 11,000 pounds). I also used Mhonarc to provide a web interface to the message archive, with Perl bits bolted on to add functionality.
I had to put the listserver on the far side of the SMTP gateway, since the company was using some really fucked-up mail system. When I told one of the company software architects that SMTP played a role in the listserver functionality, he told me that SMTP was forbidden on the internal network. He then (very helpfully) pointed out that I should go ahead anyhow, since by the time the PHBs found out, the listserver would be up, running and proving its worth.
I left the company five years ago, but as far as I know the listserver still sees a great deal of use. The moral of this story is this: if the PHBs tell you to solve a problem, don't start evangelising about open source. Just implement the solution in open source, and after six months the software will have proven its worth. Hell, in my case I'm not even sure whether the PHBs realized the listserver was a) using SMTP, or b) using open-source software.
Open Source Free = Your Time is Worthless (Score:3, Interesting)
Nowadays, management has a very different spin on IT. Gone are the days where IT wrongly drove business and the CIO had the company by the privates. Management teams are now IT savvy, and no longer write blank cheques to IT based on IT's requirements.
The argument that, if it is broken we have the source and we can fix it is no argument at all. Unless you are an IT company, your core business is not the business of IT. Why would you pour resources into IT to develop a skillset in your company to maintain software? How does that improve profitability? It doesn't. The cost of having one expert to fix a handful of problems, will never be competitive against an organization who's business model revolves around maintaining their product.
Take a look at how commercial software is built and maintained. Direction is driven by customers and revenue. How is open source driven? I don't know, maybe someone can help me. Who manages the product life-cycle in open source?
I am not anti-open-source, nor anti-Microsoft. I believe that for your case, you should ask management for their requirements. If one of their answers is 24/7 world-wide vendor support. You just have to accept it and move on. Sometimes their answers are not technically driven. Remember you are probably working for a company built on capatilism. Again, accept it and move on. They sign your paycheques not the other way around.
-Many recipes are "open source." Why do people still eat out? You'd pay less than half, and have control over the source if you cook yourself!
support (Score:3, Insightful)
I mean really, you don't need to pay millions of dollars for support, though it is more difficult to find 24x7x365 support with 4 hour turnaround when you're talking $10,000/year instead of $250,000.
Then again, does your company really *need* that level of support? I would venture to say that they probably don't. If you build redundancy into your systems, you should be able to get by in most cases, albeit under heavier load. For 24x7x365 support, expect to spend $$$$.
Here's a suggestion! (Score:3, Insightful)
Why not, then, do your job by finding and implementing packages that fit their requirements, rather than wasting their time trying to shoehorn in unsupported crapware because you happen to think it's K-Rad?
As a rule, companies that have requirements like the ones you describe have them for very good reasons.
Present OSS as a risk management strategy (Score:3, Insightful)
Consider this: Digital Equipment Corp. was once the #2 IT company in the world, with a huge software portfolio supported by an army of "world class" IT professionals. In the late 80's their products and support were awesome. Then it got ugly. By the time Compaq bought the remaining scraps, the "world class" software portfolio was sold off in bits and pieces. Where are those products now? Where is the support? If I had invested heavily in any DEC's software development tools, it would be a total write-off today. GNU is still there, isn't it?
When you buy a commercial software product, there is a real risk of failure, for all the reasons described above. When a manager makes a committment to a commercial software package, he or she can expect to be held accountable for what happens to that investment. If you start with open source products, the approval chain is generally short-circuited because the expenditure of $0 is with almost everyone's approval range. If the product fails to perform, you walk away from your investment of $0 and migrate to a commercial package. Of course, the people who sell commercial products are well aware of open source, and each has a reasonable migration path. Try calling Microsoft and tell them that you want some help in switching from Samba to Windows 2003 and watch them open the floodgates of support. On the other hand, if the OSS product performs well, you demonstrate the success to every level of management that will listen, calculate the ROI and deploy even more open source products in the future.
Now let's consider the risk the other way around. You buy Windows 2000, Microsoft IIS, and SQL Server because M$ has wonderful 24x7 commercial support. But Code Red, Code Blue, Nimda, Klez, and SQL Slammer come along and now your server is now owned by a 12-year-old who is renting it out as a spam gateway. The criticism for a technical debacle is bad enough, but then you get the CEO asking why it was necessary to spend big money AND face this nightmare when open source alternatives are proving to be somewhat more secure at a much lower cost. I doubt that my CEO would say such a thing, but open source is now getting coverage in Forbes and WSJ, so you never know. If you had installed Linux/Apache/MySQL and the same thing happened, at least you don't have to explain how the purchase price is now a total writeoff.
There are many people who use risk as their logic in support of closed source. Having seen more than a few defuct products and vendors, I say that risk really is the central issue, but that open source risk is more managable.
Converting the management (Score:3, Informative)
My best suggestion to you is do your research. Show those benchmarks. Show the community support (which is far better than 24 hr support because when you post to a news group, IRC channel or even a bulletin board, your solution will be found in a matter of minutes).
Also, show them the vast amounts of documentation freely available online (and with each product). Trying finding how to configure the intracies of IIS in comparison with Apache.
Also, look for product comparisons of software packages. For instance, MySQL vs. SQL Server; in recent benchmarks, MySQL was rated alongside Oracle 9i for speed and comes with it's own ODBC-to-ODBC bridge which SQL Server does not (and which can be purchased for $5400).
Make as strong a case as you can and gear it towards their pocketbook and level of tech experience.
And if that doesn't work, remind them that Code Red and Nimda took out 80,000 Windows machines; that's 80,000 machines that run proprietary code which is not cross platform compliant. Does ASP work on Unix, Linux, BSD or MAC? How about Visual Basic? IIS? You get my point. Cross platform compliancy is another good one because if they want to ever move to a different OS, they are screwed if they go with Microsoft.
The savings in cost, the community support, cross compliancy... what is there argument?
This one is easy to answer (Score:3, Funny)
Make them think it's THEIR idea... (Score:3, Funny)
My strategy: Make the case to the management plain and simple. Open source software is constantly being improved and will [potentially] always be free (unless the author goes to the dark side...). Tell them they can save XXX dollars and get great features. If they still argue, say OK fine. Get quotes from all the major vendors of high-dollar commercial apps (i.e. Citrix Metaframe instead of VNC (yes there is a Unix version), commerical SSH (yes there are plenty) instead of OpenSSH, etc.) Compile all the costs, slap it on the CFO's desk and say "Ok I'm ready to implement all this just buy all that stuff." Then the CFO will scratch his head and say "Maybe this open-source stuff isn't such a bad idea after all."
Reminds me of a very similar battle I went through wtih a client some time back. The CEO *insisted* on M$ ISA Server (becasue people with "MCSE" after their names are a dime-a-dozen. Trust me, I know, I have one as well, only because my employer paid me to go get it) I told him that it was a waste of money. He didn't believe me. So I set up two servers -- one with ISA Server and one with Linux and IP Tables. He quickly saw the light when I dropped the $2400 quote on his desk to buy the license for ISA when the demo expired, and had no such quote for the other server.
Sun Tzu.
24 hour support (Score:4, Funny)
Tell them for about $40 a month, they can buy you a cellphone and make you their 24hr on call person. And of course since you'll be salaried, you won't get over time for those 2am calls. They'll like that.
*Which* open source software? (Score:4, Insightful)
For some of the very well-known open source projects -- such as Apache, much of what constitutes Linux, sendmail, Perl -- the documentation is excellent, the online resources are extensive and up-to-date, there are many opportunities for simple customization, and above all, there are full-time consultants and consulting firms who know the stuff very well and can be hired to help. In fact, if the latter is true, then your management can get exactly what they're looking for: full-time support.
Many other open source projects are obviously someone's part-time diversion, and it shows. There are many missing features and a few bugs, and no one who can get around to fixing them. The options for configuration and customization are limited. The documentation was done as an afterthought, it has whole critical chapters saying nothing more than "TBD", and it was apparently never proofread by a native speaker of English. (Sorry to have to add that last one, but unfortunately it's an all too common problem.) This is the stuff your management wants to stay away from, and they have good reason.
You mentioned two specific services you need: VNC and SSH. So why don't you research the quality of the available open source solutions? Evaluate them with respect to project maturity, online resources, quality of the documentation, and especially, find out if you can hire someone to provide support. I personally don't know what you can get, but if you're lucky, you can present your management with a professional solution that will satisfy their needs. And if you can't find that, then you shouldn't be going with the open source stuff anyway -- then your bosses may have saved you from a lot of heartache.
How to argue for open source: don't. (Score:3, Insightful)
Your battle should be about choosing the best tools for the job.
Yes, the fact that a tool is open is a plus... but seriously..
The reason many of us would rather use linux over solaris is NOT because of the cost.. it's because linux is more flexible and has more tools readily available. IF linux cost the same amount, we would still choose it.
Run OOS on solaris or buy RedHat (Score:3, Insightful)
Last install VNC ans ssh on solaris. Don't tell them. First look at the sun cd full of extra's. If its there then its supported by Sun and its no big deal.
Also look at there website and make downloads for solaris there. If they question the software tell them its from SUN.
They invested alot of money in hardware and bussiness has no sense in sunken costs or bad investements.
If arm twisting was used just to ditch Windows then by all means keep you mouth quiet. Someone likely betted his reputation and his job on Sun.
Solaris is a good OS. Expensive but good and is a Unix just like Linux or FreeBSD.
Running open source software on SUN will let Linux or FreeBSD later on after they get used to running it.
Re:First ask a few questions (Score:2, Insightful)
Also,
Re:First ask a few questions (Score:3, Insightful)
You haven't dealt with many "tech" managers, have you?
In my entire career (roughly a decade doing primarily firmware engineering with an assortment of "normal" coding as well) , I have had exactly two managers with a clue.
One I consider really decent, he knew what I did, and more importantly, he knew what he didn't know and wouldn't