How To Approve the Use of Open Source On the Job 123
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.
Pet projects and the hidden skunk-works. (Score:5, Interesting)
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.
With a small company, this is easy. (Score:5, Interesting)
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.
Don't sell Open Source, just present the options (Score:5, Interesting)
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.
Re:With a small company, this is easy. (Score:4, Interesting)
i have been working in two of theand really big companies (both > 100k employees), one Japanese, one german.
in the Japanese company there was no strategy regarding software and "whatever works" was fine, which included open source.
the German company had the strategy to explicitly manage the obligations from open source. effectively the rules were:
Apache style, bsd style licenses and LGPL where white listed
GPL 3 was blacklisted
GPL needed special consideration (so kind of blacklisted)
Generalize much? (Score:4, Interesting)
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...