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.
Nobody ever got fired for buying $big_corp (Score:5, Insightful)
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?
Re:Nobody ever got fired for buying $big_corp (Score:3, Insightful)
Unless you can find a written policy forbidding it, just do it.
Its easier to get forgiveness than permission.
Chances are you won't find any policy, unless you work for a big bureaucratic compartmentalized organization. Even then, in the absence of a written prohibition, cost savings can sell the day as long as you provide a support contract. (Some how bean counters become blind to expenditures on support contracts that never ever get exercised).
My experience (Score:1, Insightful)
In my experience, showing a side-by-side demonstration of performance followed by the price will get your foot in the door. From then on, deliver and keep foot out of mouth. The low cost of setting up a demonstration of FLOSS makes this fairly simple with no need for a line-item on any budget.
For instance, in one school, I discovered the paid ILS was not working two years after it had been bought. The supplier just didn't bother to fix the problems. I installed KOHA in 15 minutes and showed it to the librarian. Within days, the supplier of the paid system made its stuff work. Several years later, that same supplier was doing the same with another school. It's software would not accept the supplied "key" after weeks of discussion. I installed a FLOSS ILS and in short order the paid supplier fixed its problem. The sad thing is that both schools paid $thousands more to get similar performance to a FLOSS application that didn't let closure of the source code or anything else get in the way of performance. It's just so much simpler to use FLOSS from one end to the other.
In another school, the CD that bore the "key" was missing/lost and an expensive bit of software could not be made to run and the supplier would not bend. He wanted to be paid again for the same performance. We replaced the OS and the application with GNU/Linux and Moodle and several other FLOSS applications and had better and more agile IT thereafter. FLOSS is the right way to do IT for education. We are in the business of educating, not making monopolists rich. We don't owe them an extravagant living.
Cost is irrelevant, support is everything (Score:5, Insightful)
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.
Re:With a small company, this is easy. (Score:4, Insightful)
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.
Re:With a small company, this is easy. (Score:1, Insightful)
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.
There is no free lunch. There's just economies of scale, and sometimes a free ride.
It's like hitch hiking. If someone stops and picks you up, and is going the same way, you might get a free ride, otherwise it's "cash, ass or grass". If someone's already made some OSS that does exactly what you need, you get a free ride, otherwise you still have to put the work in or pay someone else, to turn it from what it is, to what you need. Sometimes that's a short walk, and sometimes it's a year long trek.
I've been on the other side of this argument, working for OSS obsessed managers, trying to convince them of the merits of buying a commercial product rather than engaging in a year long project to modify some OSS into what we need. And I won that argument.
I tend to favor BSD and MIT licensed software over GPL or commercial software, all things being equal. If I use PostgreSQL
and I need some fancy feature like horizontal partitioning or synchronous multimaster replication, I can buy one of the commercial forks of Postgres that has added those features. If I use NetBSD, and I need lockstep execution, again, there are commercial vendors who provide that. And if my company begins some great work on a BSD project, we can make an intelligent business decision on whether to open that work up, or productise it. We can even have a version that we release as BSD, to capture the value of third party contributions, and make money on the value-added components that people are prepared to pay for.
I can't see anyone buying PostgreSQL if it was a commercial product, unless it was nearly give-away prices. It's a good database but so are Firebird and MSSQL, the first being OSS, and the second being nearly give-away prices. What sets Postgres aside is the large community of commercial editions that could not exist in a GPL community.
I agree that Blender is awesome, being an avid Blender artist myself, but it's important to remember that Blender's genesis is not in OSS and especially not in the GPL, but as a commercial product for IRIX, which became a commercial freebie for multiple platforms, and there was an enormous fundraiser ($1M IIRC) to buy Blender from NaN and release the source code as GPL. I'm not totally sure "all the commercial alternatives are slowly fading", as while my personal opinion is the UI and usability of Maya totally sucks, there is a huge community of commercial extension vendors around Maya, and it's not clear the GPL license of Blender allows commercial (not GPL) extensions, and I can't see all these vendors turning around and releasing all their extensions under a GPL license. More simply, I don't see the huge number of extensions for Blender that Maya or AutoCAD have.
Re:GPL (Score:4, Insightful)
.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.
Managers read that as... (Score:4, Insightful)
"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.
MOD PARENT UP! (Score:3, Insightful)
Particularly the STFU NEWB part. This is exactly the reputation open source software has.
Re:MOD PARENT UP! (Score:3, Insightful)
Except often it goes like this:
NEWB: I have . How do I solve it? .
List doesn't reply within 10 minutes.
NEWB: Look, I have to have this fixed by Monday. How do I solve it? If you don't solve it for me then I have to move to
List doesn't reply within 10 minutes. NEWB gets angry
NEWB: Its such a simple issue. I can't belive nobody can solve it. (Oh the irony). Bump bump bump.
List: STFU NEWB.
Don't expect support-contract-like behaviour from a list - remember they're volunteers, there's no "SLA" and they don't work for you.
Some simple steps for success: Make the effort to properly describe your problem and the steps you took to try and solve it. Make doubley sure you're posting to the correct list - many projects have development and user lists. And always be polite.
Re:MOD PARENT UP! (Score:4, Insightful)
You're absolutely right. However on a lot of high profile projects, that won't get you anywhere.
I remember a while back I was using a very high profile/popular data access library which shall remain nameless.
I found a fairly breaking bug in a semi-common scenarios. I poke at the mailing list, not asking for it to be fixed, but simply if it was a known issue, as again, it was a fairly common case, and I could pin point the exact snippet of code in the source where the issue was (but, being unfamiliar with the code base, couldn't easily fix it myself).
Instead of a simple "yes or no", I was more or less told to write a failing unit test or shut it, in not so nice words.
So I write the unit test, after taking several hours to find the exact guidance on how to write it (making a test for a database access framework that stays within the realm of unit test and not integration test differs wildly from project to project), I do so, submit it...all around half a day of work.
In the meantime, I patched up something on my end that worked (but it was a hack, so I couldn't really submit a patch) in a few minutes.
2 _years_ later, I see in my email that my bug report just got rejected because of a small mistake in my unit test (that still didn't change the main code path it was testing), and to this day the bug is still present, and whenever this is raised in on Stack Overflow or whatever, people just say its a scenario that isn't supported, even though you can see in the code that it should be, and its just a naive sort order mistake when looping through some array.
I wish it was an isolated case, but it basically is always like that unless you're inside the project's "clique" or you happen to find a bug that is particularly interesting to fix. Yes, they're just volunteers, but if they don't want their project to be of world class interest, then don't promote it as such.
TL&DR: Big projects with a lot of marketing pushes saying they're great for real production use, then don't support it as such, are far too common.
Re:Nobody ever got fired for buying $big_corp (Score:3, Insightful)
Oh, plenty of people have been fired for buying Oracle.
Yeally?
Their enterprise apps are a bad joke.
Yes, but they're such an *expensive* bad joke that it is too embarressing to too many important people to write off the cost, so usually, the system is kept and forced to work and declared a success.
If you fuck up a $100k contract, you'll be fired. If you fuck up a $10,000,000, people will work very hard to find a way to make it not look like a fuckup, especially if they've been involved in any way at all.