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.
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
There IS no such thing as a free lunch.
Free as in speech, not as in beer.
There are many advantages to Free software, such as Freedom, being the microsoft doesn't have leverage over you. If your a large enough corp, you can write whatever features MS will never give you, or pay red hat to make them for you.
.Avoid terms with negative connotations, such as "GPL" and use the more acceptable term, BSD. As a hiring software developer, I know of what I speak.
That wouldn't work with my old boss, who would take any unfamiliar word and enter it in Google, and then hit the "Images" link for screenshots or easy to understand slides.
Suggesting BSD would then be career suicide.
The best way I know of suggesting free (as in breasts) software is to present it with the pricing for someone who sells support. If you can buy the support through the hardware vendor,all the better.
Which is one reason why there are so many IBM / Red Hat systems out there.
"No support contract."
Thus what they see is the possibility of problems that take days or weeks to resolve, while getting told STFU NEWB on some mailing list.
That's the experience many clients have had with FreeBSD, for example.
Futurist Traditionalism
Particularly the STFU NEWB part. This is exactly the reputation open source software has.