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
...is explaining it all to end users
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.
RISK
THE BOTTOM LINE
The latter is of course, tantamount in a for profit organization. Focus your research on these two items, and shy away from the "thousands of eyballs reviewing the code" arguments, as those are unlikely to carry the day.
Toodles!
Stop corporate
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.
I believe that the thing that needs to be addressed and stressed are the recent KNOWN vulenrability "outbreak". The fact that in order for one to keep up and deploy all the security patches that come out almost on a daily basis on all clients. One has to have dozens of man hours per patch. Which obviously translates to quite a bit of money.
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.
Simply couch it in terms that most big biz managers can understand, the days when mainframes, dumb terminals and programmers ruled the earth. The largest data center I've ever worked in was First Chicago - National Bank of Detroit's Haggerty Rd. Tech Center, and based on that experience (and at smaller data centers) I see no problem with Open Source taking over most of the software functions from the OS to applications to custom programming for one-off jobs. The main thing to remember about Linux and OSS is that most of it needs to be used as large Lego's, nice blocks of code that do their job damn well, but need smaller custom machined parts if you need to go outside the boundaries. This is the reason IBM is behind Linux and therefore OSS, you can still make a hell of alot of money actually making the whole thing work. I hope your tech team is like most of the ones I work with; love to read and learn new things, enjoy long hours in the night and weekends spent with keyboard and mouse, and the courage to kludge and break things in a test environment, but the control to leave out the kitchen sink if the plumbing stinks.
Jonah Hex
Horror & SciFi Erotic Nudes
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.
If your company seems resistant to Open Source for whatever reason, include a package from Redhat or Suse that includes support (such as Redhat enterprise.) Business types will prefer buying into a product/service package as opposed to a solution/process package. Then you can ease them into the idea of running pure open source software over time.
My Other Computer Is A Data General Nova III.
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.
I wouldn't do it, it does not save money in the long run. I tried to run open office in our Manufacturing Plant during a run that required Excel to log data, it didn't work out. The program it self didn't allow sharing of documents, and I couldn't auto save it, unless I did so in it's Open Office format, so then I had to save each days run as an Excel file.
In business I can count on other companies having Microsoft Office products, I can count on them having Adobe Acrobat. When you start getting into something that isn't the 'norm' you seem to run into problems. Granted, I am sure no one else on Slashdot will agree with me, due to the nature of Slashdot, however, business is business, and in most cases (outside of IT) it needs to be done now. Not when the next free version of software comes out with X feature you depended on before.
Look you want to cut costs? Don't upgrade, don't buy into software assurance, cut spending drastically, your already 'taking time' researching 'open source'..
I think Linux and the whole open source genere have their place, its in the server farm, not on desktops, at least, not right now..
Many will disagree, however, I am just speaking from my 'work for a manufacture, been there, hoped I could save money, found out I couldn't, done that'...
> 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
Policy is great, so is open source philsophy. But what sells the idea to management is the presentation of a cohesive plan for implementing the new software: variant & feature selection, configuration controls, distribution to & training of users, support needed. Comparing these to the existing way you do business will show the pros&cons of changing over.
The devil is always in the details...
Is it a rule, that there's an exception to every rule?
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.
Linux
Apache
Mysql/Postgresql
Perl/PHP/Python
Simply make it okay for your employees to install this technology on their computers, because it is great technology, it won't lock you in, and it is becoming a global standard.
It will be much easier approving a couple good Open Source technologies than creating a general policy for Open Source technologies.
Once management sees how great the above work, they will be much more open to additional addons to your list of approved Open Source programs.
The future is Open.
Sdelat' Ameriku velikoy Snova!
Just this morning on the news, the talking heads were yammering on about the alleged leak of NT source code. On comment jumped out at me: "some [security researchers] are worried that hackers will be able to use the source code to find new vulnerabilities."
Chew on that for a moment. If the only thing keeping Windows from being 0WN3D on a daily basis is that hackers can't see the source code so they know exactly what function is vulnerable, then how secure is the code? We call that "security through obscurity," and it's really no security at all.
Of course, Open Source means that those same hackers can read the Linux or *BSD code to look for vulnerabilities, but so can a lot of people who are interested in making the system more secure.
Consider the scenario: a F/OSS developer discovers a huge security hole in the code for the FooBar 1.1 release. It will take a huge amount of effort to fix, and so the F/OSS community will have to continue using FooBar 1.0 for 3 more months. Irritating, but manageable.
Now consider if it's a programmer at MS or any other commercial software outfit. Will your customers wait 3 more months? Will your boss appreciate the impact you just had on the company's finances? Might the bug be "papered over" in order to not impact delivery to customers? Is that really in the best interest of the customer, especially if the customer is a large finance company?
-paul
Pistol caliber is like religion: everyone has their favourite, and theirs is the only right choice.
There is an additional issue that I have not seen discussed here. That is the Total Cost of Liability (which I will call TCL ;-).
Microsoft has gotten into the habit of suing companies for installing software on machines without licensing. So you own say 3 valid licenses, one of the staff needs a version of MS Office to do a presentation, they install it in a hurry and forget to tell accounting to purchase another licensing. If M$ finds out you could be in big trouble -- you are a company and are preceived as having deep pockets. Now lets say that your admins are diligent and everything is purchased but in a tidy up someone throws away the little proof of purchase stickers... You are just as liable as you were in the case of "illegally" installing the software or intentional "piracy". Just to make sure that I am not paranoid, look at the costs various school systems and cities around the US when M$ audited them, and make sure to account for downtime (if/when they lock you out of your own systems for the audit), staffing redirection, and fines in the event that someone installed to much software on even one machine.
Read his post again. You're saying to select a product because it's reliable and problems discovered in it will be quickly repaired, not because "they can see the #includes" - he said the same thing. He said not to select things because they're open source or not, but because they provide the right features regardless of whether they run on Mac, Windows, or Linux boxes.
-N
I've nothing to say here...
The issue that you will have is based on cost. Most large corporations (like the fortune 100 company I work for) have a mentality that open source is free. The code is free, the software licensing is free, but is there a cost?
Most people don't understand why they (being large corporations) call things open source instead of by the name of Linux or ___BSD. What it comes down to is what they are considering. They define many projects that use "free" or "open" software as open source in an implied type of meaning relating to support cost in most cases.
What most people fail to realize is that with a commercial "closed source" product, the company that sold it to you is expected to support that product. If it has problems and the wizbang features they market to you break, then you go back to them and tell them to fix it. After all, you paid them for it and it should work. One other thing to consider is that many software companies have a very strict QA testing environment. This doesn't mean the software is better, but rather that the company that purchased the product has someone to point a finger at when it breaks and someone who will be more obligated to correcting the issue.
With open software, it is quite different. Most of you know that bug fixes are done mostly on spare time of coders helping with projects. There is no solid support of software like you have with commercial software. You may consider mailing lists and bug tracking pages to be support, but thats not quite the same as being able to pick up a phone, call the developer and say "Fix this!". While many developers in the open source community have a sense to help out, many don't. So you are not garaunteed support from them. The other thing to consider is with such a large environment, who does the end support? Most large corporations pay for end support through their vendors they bought the software and products from. With Linux, what companies can provide that?
There are options like getting with RedHat or some others offering "Enterprise" solutions, but if the goal is not to pay for software, then you will pay dearly for support. Then again, it's my experience working with RS/6000 systems that my company pays for the OS/Systems and for support both, so who knows. Just keep in mind that support is a major fact.
root 10956 5164 0 Oct 22 - 0:23 sendmail: rejecting connections: load average: 70 (isn't sendmail just too kind)
Now I have to state before I make my comment, that I work for a small college with around ~5000 students. And working in Academia is a bit different than working in the corporate world. We use opensource software here (Linux, apache, squirrelmail, netsaint, and a few others...), and it wasn't that hard to get in the door. Mostly because it's cheap (budgets are tight) and it gets the job done. Plus, both the network admin and I know Linux, so the college does not have to spend money training people who can use opensource software. I don't care what microsoft says, if you already have a linux/unix admin employed in your company, then your TCO for Linux over windows is practically nil.
But anyway, with that said, one thing that I've noticed here at the college, is not so much a hesitation to use free/opensource software, as there is to make sure that it's supported properly. See, our budgets are stretched tight with microsoft products, so if we can save money or even go with a free solution, then it actually is welcomed. But what they really want is someone to point the finger at if it breaks. Now if your solution is homebrew, then they point it to you and you have to fix it. (not necessarily a bad thing. That's how our account-creation on campus works. Buying a product would have been too expensive) But being able to rely on another company for help is a big plus.
I know that companies like RedHat and IBM may have their own interests at heart (like RH not releasing new free versions outside of their fedora releases) but if you can get a support contract from these guys that says that they will back up their software, then that's often what you need to turn the tide. So long as the software does the job, and does it well. All you really need to do is just get its foot in the door. Once you do that, if the products work just fine, then you'll have much less resistance to getting more software in the door from there on out.
-Through the server, over the router, off the firewall... Nothing but 'Net!
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.
This was modded Insightful but it really should be a troll... but anyway, here's a cautious response:
With an OSS solution you don't have to pay to have the software built; it is already built. If it needs to be customized at the code level, it can be done and yes it can be done cheaply. The alternative is to write a proprietary app from the ground up, which takes forever, has lousy support options, and costs a fortune.
Or go with a premade proprietary solution. If it needs to be customized at the code level, it can't be. If it has bugs that need to be fixed, you have to beg and threaten to even be heard and unless you're really rich and powerful, they won't listen to you. If there's a security flaw you will be at the mercy of a company that you have no control over, and they are under no obligation to provide a fix for it.
The real question is, why would anyone choose a proprietary solution in a business where software runs the company?
-JemWhy 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.
1) Make sure that every point you make is backed up with fact and research. Avoid religious level proselytizing. Just becasue you (and I) are already sold on FOSS doesn't mean they're going to accept that information without supporting data. Remember, as a senior leader in any organization, their jobs are to play devils' advocates and plan for the worst case scenario when evaluating now projects and expenditures. Allay the fears that they may already have. It would be wise to read Microsoft's anti-OSS propaganda pages and rebut, in your first paper, all of those claims that relate to your organization.
2) Write with a hefty respect for "What could possibly go wrong?" Anticipate objections and rebut them in your initial report. For each FOSS product you're planning to use, explain how you can make it redundant (ie. failover web-server/database serveR) and how you can recover your backups in the case of data loss. If you can make your current backup solution work with your alternative OS servers and apps, that's a big benefit! As you can imagine, protecting their large, director level salaries is a big concern for the PHB's today. Make them understand that support and recoverability are not the exclusive domain of proprietary vendors. They might approve switching some in-house app from SQL Server to Postgres if they know you will still have full functionality and recoverability without spending a mint ripping out the backup software/hardware and starting over.
3) Make the point that FOSS is perfect for some needs, while less suited to others. You have a better chance of having your ideas accepted if your message is "right tool for the right job." Is there any reason that file and print server should run Windows 2003 Server and require 2 gig of RAM and dual XEON procs when Mandrake, Samba, and Webmin would achieve the same goals on a lot more modestly appointed system.
4) Don't forget about hardware! Point out that software that uses fewer hardware resources will require less frequent hardware replacement. A new linux kernel doesn't mean everybody needs new hardware... Compare with each new iteration of Windows having an ever exponentially-increasing list of hardware requirements.
Beyond that? You're on your own. Oh, and to quote Bob from "That 70's Show": "Hit him with a banjo."
Who did what now?
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.
No... your security, and your job, relies on what people do on their jobs. People who work for:
IBM
Sun
HP
RedHat
Mandrake
SuSE
Sendmail, Inc.
...and many more companies that support OSS. There was a point in time where OSS was largely written and maintained by people in their spare time; these days, there are people who have jobs that revolve around developing, maintaining and improving OSS.
There's still crud out there, of course. Remember Sturgeon's law: 90% of everything is crud. This goes for both commercial and open source software. You should evaluate OSS the same way you evaluate commercial software: who wrote it, what's their reputation, does it have the features we need, how stable is it, etc.
You wouldn't judge Microsoft's capabilities based on the kind of software that Sun produced, would you? Then why would derive your opinion of Apache, Sendmail, Bind, Linux, XFree86, BSD, KDevelop, Gnome and the like based on the fact that some other, completely seperate OSS project isn't worth dreck?
"Great men are not always wise: neither do the aged understand judgement." Job 32:9
The other reason is you can distribute the cost of paying those 20-expert-geeks over 2,000 companies who pay you for the service. Othewise those companies would each have to hire the 20 themselves costing a colletive 40,000 geeks worth of salaries to the buisnesses involved.
Yes, some of those companies might release those patches back to the other users of the software, but think about it... amoung those others using the same software your company does are likely a good number of your competitors... Are you going to trust a patch your competitor released to you without haveing your own team of geeks check it out? It's still going to cost you. Distributing the cost of the support-contract-geeks is a good thing. You get a better return on invetment.
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...
A "Policy" is not a selling document, nor even a how-to. It provides guidelines to make decisions, biased to what the corporate executives want. In this case, a policy should contain items like:
1. When planning a new software activity, see if there are any open source candidates.
2. If there are any candidates, they must be investigated (with criteria like the parent of this comment proposes): risk, history of support and bugginess of releases, real adequacy for the task, TCO estimates, etc.
3. Produce a report comparing and contrasting the proposed solution with alternatives, and the rationale for a choice.
I.e. in terms business people can understand. Other information should be elsewhere.
Linux (IBM, SUSE, RedHat), MySQL (themselves), and other open source projects are supported commercially. Just because the product is developed by a loose group of people doesn't mean that others won't support it.
You may not be used to this, but in real computing land our web browsers aren't part of the OS kernel. We can change a line or two of source in sshd and recompile it, leaving the rest of the system untouched. Have you ever wondered why so many IE "critical updates" require a reboot?
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"
In my opinion the greater risk is the risk of not moving to open source in a dignified manner. As time goes by licensing from Microsoft is bound to get more restrictive, cumbersome and expensive. With open source your organization is secure in knowing that current apps will be continually improved and there won't be "licensing surprises" in the future. As organizations gradually move to open source Microsoft will have fewer customers from which to derive its profits and, to maintain revenues, prices will go up - leading to yet more people moving to OSS. When the tipping point is reached every organization had better have an open source contingency plan in place. The longer they put it off the harder it'll be at crunch time. In essence it comes down this. Looking into the future 5-10 years from now there are nothing but blue skies in the direction of open source and a lot of dark clouds and uncertainty in the direction of MS. Any large organization would be fool hardy indeed to stick their head in the sand while the predictable market forces play themselves out.
if something breaks we want it fixed, not in a couple of minutes, not after discussion on a newsgroup, but Now.
And how do you get that from Microsoft [I'm assuming MS is the current closed-source base]? Microsoft only releases patches once per month (if that often).
The only reason we have the rights we have is that people just like us died to gain those rights. -- Cheerio Boy
Also, some important points: 1) remember to constantly tell non-IT people that you are not going to change the desktop (assuming you aren't right now - most depts are only considering servers) 2) As per above, point out the numerous open source packages already in use (even financial companies do transaction data with open source) 3) Come up with a review process to approve specific products. DO NOT just let locals willy nilly choose random packages. Everything must be best of breed and supported. This means settling on one linux (Suse or Redhat probably) supported by current hardware vendors (IBM or Sun and kind of HP). 4) Make it clear that this does not mean people can start using obscure .8 versions of sourceforge products. The honchos will be happy if you are conservative and are only allowing the use of established and supported products with long lifecycles (MySQL, Redhat/Suse, Qmail).
Bottom line, this is the real power, to obviate the allways tenous vendor client relationship. You are your own vendor, and bottom line, no-one in the world can meet your own needs the way you can.
You can push that theme in lots of directions, but it all seems to tie back to being able to control your own destiny with your software acquisitions.
Hell that what finally convinced my employer to begin in-house dev again in lieu of buying from an external vendor. (Well, the vendors ridiculous pricing didn't hurt either...)
"Talk minus action equals nothing" - Joey Shithead, D.O.A.
"Talk minus action equals
Is open minds. I have found in my wanderings around the IT world in the companies that I have worked for that there a large number of people who are only capable of rote tasks in a sandbox of M$ products. The concept of being able to generalize from M$ office to Star Office is totally beyond them. Heaven help them if they see a different gui for their mail program. In that case they are totally lost. This is in contrast to folks who master a number of enviroments and understand what happens when they hit return.
I suggest that these M$ only folks are NOT the folks that a company benefits by hiring unless you want an army of mindless drones. Some places may want that sort of person, but I doubt that they are the companies that suceed in life.
Features that are demanded by users may be quickly developed if the developers agree that the features are needed and/or the developers find it interesting to develop them.
There's a reason why a lot of the nitty gritty features of spreadsheet software isn't in OpenOffice yet. No one who could do the coding cares enough to put it in (we'd use another tool to do what we need to do; or we look at it and go "why do you need to do that for?" because it's all flash and no substance). But the General Business User who can't quickly write a script but uses the hell out of a spreadsheet (and thinks that when they do something in a spreadsheet they've "written a program") would kill for some, say, graphing features, because the people they work with can't visualize a graph to save their life and those same people need a pretty picture to make a point.
Showing poor QC to a multi-million dollar client - bad
Save As PDF
Need edition on the client side?
Save as HTML (it does convert most stuff to nice CSS and all).
NO SIG
" ... nearly every workstation needs to have QB installed so we can get our job done. ..."
... is it really true? Do you need Quickbooks on every workstation? Because if it isn't true, then you have a world of options.
If that's true, then you need QuickBooks and Windows on your desktops.
But, I as you
QuickBooks is a glorified database. A database could be described as essentially the oldest application use for desktop computing; it was around on the Apple ][ and is on the list of the first 3 apps you need to launch a platform. Everybody's got one.
What do you use? QuickBooks. If you look at it that way, it's the only answer.
What do you do? Aha. Way different. You are using a database to manage your business. Now you can move to damn near any platform, including Linux, and get "double-click" functionality. It's all how you look at it.
Make sure you ask the right questions, and you get the right answers.
Well of course you're right... If developers are going to perform this kind of service gratis, they will have to perceive it as useful and maybe even interesting. There's also the need to avoid software bloat, which can easily happen if there's no gatekeeper keeping an eye on things. It follows that there will be more OSS options in areas where software is fun to write than for more nitty-gritty things. You may not - and, for highly specialized purposes, probably will not - find an acceptable OSS solution for every particular need you may have. But when you do, there are many good reasons to consider it.
By the way, if there are many businesses that would use OSS package X if only it had feature Y, there is usually nothing preventing any enterprising programmer from starting a new branch that better meets needs that the parent branch is ignoring. Under the GPL you can even sell the derived software (so long as you also provide the source code). Couple this with a support commitment and it's probably not a bad way to make a living, if demand is high.
A software company is a special case. You have to prove your OSS code does not contain pieces that belong to your company's intellectual property (IP).
However, take us at IBM. Employees have to comply with a short OSS-and-IP training program, and we have a process in place for open-sourcing projects. IP checks are in place. That works fine.
Very large financial companies such as Merril Lynch have started deploying OSS massively (servers and desktops) and they don't seem to have a legal problem with it. They happily mix OSS and non-OSS, e.g. IBM proprietary products running on Linux along with Apache.
As for sueing someone, this is pure BS. Read the contractual agreement that comes with your MS Windows copy. Short version: MS isn't responsible for anything. Good luck suing them after agreeing to that. Most other software providers have similar provisions. How are these clauses different from the "no responsability" clause in the GPL? Your lawyers are not giving you proper counsel.
Folks,
PDFs aren't open source, the reader is free (as in beer $$) but closed tight. Also, you can't cut-n-paste from a PDF to anything. Adobe (lest we forget) is the company that put Skylarov in JAIL. For opening their closed eBooks format so blind people could use it!
So do youself a favor, don't ever send anyone any PDFs.
rant mode off, now.
Thanks,
jr
"Abandoned software does not mean it is has no use, simply that it may be limited in future plans. But if it works now and does the job, why not use it?"
I totally agree with you, _BUT_, having worked at a medium-large sized non-profit(700+ employees, 4 locations across nothern cal) and trying to sell them on Open Source, I can say that this does not represent peoples perspectives. It DOES represent logic and reason, but not peoples perspectives.
I could not sell them on Open Source because even though they did not deal with support issues(that was my job), even though they did not deal with deployment issues(that was my job), even though they didn't have clue 1 on how to deal with either of these issues, they still would not go Open Source becasue of the fear of not having a company available to contact.
I had over 300 desktop PCs I was in charge of, and we could have saved 10s of thousands of dollars per year in licensing costs(don't even get me started on the servers), but I could not get them to see past their fear. It was not reasonable, it really shouldn't have been their concern at all. Especially given they had no idea the amount of times I had to call for support(other than a wierd problem with a Cisco 2600, I never called a vendor for support). They had no idea at all what my day to day job was, I was the magic computer fairy, who simply granted IT wishes in accordance with their desires.
Part of the problem is what I call the "common sense" fallacy. These people do not sit down and reason through anything when it comes to IT. They go through "common sense", which isn't common, and it isn't sense. And I KNOW I am not the only person who has been stuck working in organisations like that. And that's really the problem.
You can preach to the choir all you want, those of us who keep arguing the support issue aren't arguing from our own perspective, but we're arguing the arguments that were given us by people who are more content to make decisions through fear of the unknown, than through logic and reason.
And that's why open source is great!
Instead of moving completely off of this software which you've invested time and energy into training and upkeep,
(and here's the simple part, folks!)
PAY SOME DEVELOPERS
to implement the features that you would like to have. What are the odds that you'll save money in the short run (no large capital expense for licensing fees, training classes, support agreements) and in the long run (no forced upgrades, no discarding this application for a new -completely-different-app because the old company went under)
Plus you've added benefit to your organization in that they've got a(nother) skilled developer in house, or at least available under contract when they need him. Or not! Just hire somebody else to make the next changes. Keep those PFYs busy during the summer, coding instead of causing havoc.
Support FSF: Stop thinking with your wallet, and think with your imagination. (cc/non-commercial)
I am familiar with most of the arguments for OSS on the desktop, having made them as a sysadmin in a M$ dominated network at my previous job. You look at the services deployed on the server, the applications running on the desktop, the database and start thinking... hey, I know! We'll run sendmail instead of Exchange, OpenOffice instead of Word, Mozilla instead of IE and mySQL instead of SQL server! And we can probably all consolidate it onto one system which also acts as a gateway and a firewall with ipchains--
I'll save them about a billion dollars over the next 10 years and they'll worship me as their GOD!
And even in a small environment, that would take some time. Interoperability issues aside (document formats, drivers for that old tape backup-drive? forgot about those) you're looking at a whole new psychology change (getting used to a new GUI, "Where's my internet" kinds of questions), and that will make the end users hate you and the management hate you as well (as everything will seem "broken" to them). Sure, *if* you got them migrated seemlessly, you'd be saving money. Eventually.
But in an enterprise? Forget it. I mean sure deploy OSS on some test servers where they're used to UNIX anyways or whatever, but replacing all the desktops across the entire enterprise would be just crippling in (re)training costs alone. Not just for the users (wasted time) but for the Tier 1 folks as well.
My (admittedly unsolicited) advice would be to give OSS just enough of a reputation that someone says, "Hmmm. We should look at this." Then it'll be piloted somewhere in his organization. Once the kinks have gotten worked out, then he could actually have the company-specific data to induce a global change.
--Have a good night's sleep. Don't forget to brush your tooth.