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.
It seems like the best bet is to not raise the question in the first place. Management doesn't need to know that Apache is free, for instance. And there are commercial and free versions of Nagios, Tripwire, Sendmail, and so forth. We have over half of our prod servers running Red Hat, for which we buy maintenance, but in the lab we run CentOS. The Open Source community realizes that companies have a compulsion to spend money, and there are companies that will sell you free software (think about that phrase for a minute...) to satisfy this requirement.
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
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.....
Not where I'm working (a giant company). On the contrary, we are rather suspicious of commercial solutions — because their costs tend to run up pretty quickly (we have a large user-base) and their license terms often enough turn out to be rather enslaving (Oracle is particularly scary in this regard, from what little I've overheard from the company lawyers).
Sure enough, free software has its rough edges, but so does the commercial kind. And we have enough bright people to fix the problems (bugs or missing features) in the open-sourced packages, whereas with the proprietary stuff you are usually at the mercy of the vendor. We still use some commercial programs, but, when choosing a software solution, the program being proprietary is a negative, rather than a positive factor.
I wish, it remained possible to get the source for the commercial packages as well, but with modern attitudes towards theft of intellectual property as well as the wide-spread propensity to use the terms "free" and "open source" interchangeably, this is not an option...
In Soviet Washington the swamp drains you.
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
My first instinct when a geek summons up a Slashdot meme to make his case is to do precisely the opposite of what he suggests.
But it isn't a slashdot meme - it is a Grace Hopper quote well known long before Slashdot existed, and rarely encountered on slashdot.
The web service stuff is in AGPLv3, and GPLv3 and AGPLv3 are separate licenses. The only ways they're connected are that most of AGPLv3's wording is copied from GPLv3 and that the GPLv3 has an explicit exception for linking to AGPLv3 code.
.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.
Wait, so they do work, and you have to pay them? What a scam!
Except for the really edge cases most SAP installations cover the exact same grounds. What are the chances that, for example the accounting, which is strictly governed by laws, is radically different from one shop to the next? In few cases a shrink wrapped solution would have done the job too.
And provided it works, what's wrong with that?
Except that you are billed around half a million for the "integration" efforts.
What SAP sets itself apart from shrink wrapped solutions, is integrating with existing legacy or non administrative systems. For example the sales order triggering an entry in the production system. But in the case of SAP that definitely will not be cheap and you are effectively contracting software development work out to SAP. This is all fine and well when you are a shop that has totally no background in software development. But then you can also contract it out to a different and cheaper developer.
I assume you wouldn't have to train users when implementing other system, either made in-house or bought?
Yes you need to provide some guidance. But wasting a day of a room full of IT professionals on how to fill out a spread sheet like form, so they can log their hours. This includes on how to install the application, log into the SAP, typing in values and hitting submit. With the added excourse why basics of account and why logging hours is useful. You know something that one page e-mail would have done with a "I mananger comand you to log your hurs" and here is the step by step explanation. The entire thing at the tune of 10 thousand bucks to train something like 200 people. Not to mention the fact that hours where logged beforehand.
and remodel your business processes around the paradigms those tools are designed
Except that deploying SAP also meant that most processes where changed around anyway, so yea whatever.
I have seen 3 SAP deployments, two first hand and one second hand. There is some benefit in using SAP as a one stop solution, but it will definitely not come cheap.
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.