Slashdot Mirror
How To Approve the Use of Open Source On the Job
New submitter Czech37 (918252) writes "If you work in an organization that isn't focused on development, where computer systems are used to support other core business functions, getting management buy-in for the use of open source can be tricky. Here's how an academic librarian negotiated with his management to get them to give open source software a try, and the four phrases he recommends you avoid using."
"Open Source," "Free [Software]," "Contribute," and "Development" appear to scare managers away.
Old saying. Nobody ever got fired for buying IBM. Nobody ever got fired for buying Microsoft. Nobody ever got fired for buying SAP. It's a simple cover-your-ass game.
Managers, unless they have a very special bond with the company (like, say, they built it from the ground up) don't give a shit about the company. They care about their ass. And when the question is whether to blow a million of company money for software they don't know jack about but has a big name behind it, or to save the company a million bucks using software they don't know jack about but has no name to it, they blow them money.
Because they needn't explain why they did it. It's IBM/MS/SAP, how should he have imagined that it's no good?
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
In small businesses - often the best foot in the door for open source software is a pet project, something you can do transparently to design something to show management about the advantage of the software has over more traditionally licensed fare. Being able to speak the language of IT management helps - Cost of Ownership, Return on Investment, being able to present facts based on license costs is also helpful - management listens to dollars and sense, followed by legality.
Of course, if your business deals with large vendors who have a stake in keeping things locked to Microsoft, Oracle, IBM or HP - you are fighting a steeply uphill battle.
When I tried this with bigger companies, it was H*** on earth to try them to embrace Open Source. One of the business managers simply doesn't understand the concept of a free lunch.
However, with every SMALL company I ever worked for, introducing Open Source software...was a blessing from above to them, it's free, it's cheap...and the programmers are enthusiastic idealistic & proud of their work, so bugs gets fixed faster and new features are introduced frequently as opposed to the commercial bug ridden bloatware where companies are afraid to admit ANY wrong doings as they're afraid of liabilities and such.
I've been using Blender (3d Software) for over 10 years now, making a living of it, and all the commercial alternatives are slowly fading away with their fanboys. Long live Open Source, it really is true freedom.
What this world is coming to - is for you and me to decide.
So in other words, put Open Source on the table just like any other software. Don't try to differentiate it as "Open Source", because if you do, decisions makers and stakeholders will wonder why you're putting extra effort into justifying it.
Put it up with a support contract and necessary consultants just like any other piece of software and you'll get approval.
I'm out of my mind right now, but feel free to leave a message.....
Most managers who have had any dealings with a software rollout know two things:
First is that they won't actually get what they think they have specified
Second is that there will be problems (see point #1), overruns, differences between what's required and what's delivered and that getting the software functional is only a small part of the job. The rest is integration, training the users, supporting the thing for 5+++ years, implementing upgrades and bug-fixes
These managers also know that once a project has been signed off, the money has, just that moment, been spent. Companies don't think of money, they think of budgets - so once you have gone through the approvals process and got your budget and your go-ahead the project is effectively a sunk cost, but one that has not yet delivered anything. As a consequence the manager in charge of the project will be deemed to have failed if he/she needs to go back and ask for more, in order to deliver the project.
So, in their minds they want insurance - and indemnity - above all else. Even above cost savings. They want to know that in return for $<megabucks> that when things start to go wrong, their commercial relationship with "the vendor" entitles them to get support, advice, expertise, fixes, customisations, training, documentation and upgrades. Those will all form part of the cost-case and whoever approves the case will expect, maybe even require, that those items are included and form part of the contract. As they know that there will be the need to call upon those services. If all they get for using "free" software is a pile of code, then that is usually the smallest part of the project and often the least expensive, too. The real cost, over the project lifetime comes with all the extras and services they get from their vendor - but which "free" software is very poor at providing, and absolutely does not guarantee.
If you go to get approval for a project of any significant size, not having included those items will mark you out as, at best, a newby and at worse: completely unsuitable to be managing a project. It's like if you buy a car. The cost of the vehicle is only one aspect. The cost of servicing, fuel, taxes and depreciation are major factors that should be included in the plan. That they aren't is just an indication of how poorly most people approach a major purchase - and why they'd never make a project manager.
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
Good idea, but incomplete:
exactly lay out the facts:
product A is owned by commercial company with billions of dollars and developers backing the product
product B is written by some really smart people in their free time that may help you on a forum or in an IRC chat room if they can
Product C is free, maintained by a mid sized company, and they sell support contracts
Product D is proprietary, owned by a company that might be bought by the competitors, who may or may not keep supporting your product
Product E is a great software product, proprietary, but your company is not in the target market, so licensing and support don't match your needs
Product F is proprietary, and you might need small development tasks on top of the product. Only can buy from the owner.
Product G is free, and you might need small development tasks on top of the product. You can buy from the developer, build your own, contract, whatever.
Add to that, whether there is an easy way out should the unthinkable happen (end of life for products). Does the software support industry standards? Are there alternative implementations of these standards? Have you tested compatibility?
I'm not hiding the technical or strategic advantages some proprietary products might have over free ones, but they are stated everywhere, only trying to lay out more aspects you need to care about.
I think regarding the article you just need to do your job, and lay out all the things you consider. Free software is almost always better in the long run, but it's only sensible to lay out everything you considered, so others can make the best decision.