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.
Agreed. I take a dim view of managers that demand I "sell them" on what I think is the right choice.
It's their job to make decisions wisely, not my job to force what I consider wise decisions down their throat. I try to be honest about the pros and cons. If the choice lies within my authority, I try to make the best choice. If it's within their authority, then I hope they make the best choice. If they don't, that's their problem.
I guess this response must reek of someone who has little patience for foolish managers, and other job prospects if necessary. So be it.
Its easier to get forgiveness than permission.
Not always. Not everywhere.
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.
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.
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
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.
and you have no company to make a data confidentiality agreement with
Why can't you execute a data confidentiality agreement directly with the main developer as an individual contractor?
And without a repro, and bad data to test with, the need for the fix is not obvious.
If a patch is made with the intent to correct misbehavior, this implies that a cause of the misbehavior has been found. And once a cause is found, it shouldn't be too hard to generate fictitious data that likewise trigger the misbehavior.
.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.
It depends. In my experience they have heard of freeware, which often comes with a "non commercial" clause and the legal department said that is evil. Free software is freeware right? The better educated managers know about the GPL and that makes all our software free software, but we wanted to sell that software. All free software is GPL right?
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
You hit the nail on the head. That is one of the big problems indeed.
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
You hit the nail on the head. That is one of the big problems indeed.
There is sometimes overlap between the two groups. For example, Linux.
Project leaders usually come to me with a vague and changeable list of requirements, a very short turnaround time, and no budget for anything other than wages.
- Writing from scratch takes too long, plus the requirements change too late in the game
- Buying off-the-shelf means squeezing blood out of someones stones, and is not customisable
- Evaluating several open source solutions and taking the best, then modifying as needed hits the sweet spot
The only time I really needed to put a strong case forward to switch to open source was when I took over an in-house solution just after I started this job. The new requirements were simply too much, the deadline too close, and I had too many other things to do to realistically change the custom written code on time. I found a mature open source solution with an active developer and user community which was far more capable and customisable than anything I could single handedly accomplish. I told management that if it didn't do what we needed then in the worst case we could always fall back to the old in-house solution (god help me). Best decision ever, saves me hundreds of hours ever year. I still add the odd feature or bug fix when needed and submit back to the community, but usually by the time we think if it someone else has already done it for us.
Having basically no budget means I couldn't accomplish half my job without free or open source software.
Human Rights, Article 12: Freedom from Interference with Privacy, Family, Home and Correspondence
True. Those are good pieces of software.
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.
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.
Well, why put the extra effort into justifying it, then? What's the real answer? Is it because I have been brainwashed to like it, and must turn everything into OSS just because it's so awesome?
While cost is often a reason for many things in big corporations, certifications and training are too. There is no universal "Linux router", many specialized Linux distributions for routing purposes do a lot of configuration and setup vastly different from each other. IOS on the other hand is pretty uniform and will likely have a wider selection of employable candidates with Cisco certification than Linux Router specific certification.
Change is certain; progress is not obligatory.
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.
'academic librarian doesn't know how to proofread or use spell-check'
Because decreasing the risk in employing more people to handle the systems is fairly important. Especially in today's corporate climate where people tend don't tend to stick around and have a long term career in a single company. You also generally want it to be easy to look for replacements and understand that the person is capable without having to be an expert in the matter yourself. Also depending on your industry, you may have compliance requirements that require certain types of certifications to prove eligibility.
In my experience, red tape.
Change is certain; progress is not obligatory.
Consider the scenario:
Product A has technical features X,Y,Z
Product B has technical features X and Y (not Z).... but it's OSS!
Most decision makers will then ask, what's OSS? And when you get into the weeds of explaining nuanced differences in licensing, they'll quickly decide that the features outweigh the license benefits.
I'm out of my mind right now, but feel free to leave a message.....
One of the big problems is that people actually believe that stuff. In this reality, "backing the product" doesn't mean accepting blame or necessarily fixing your problems with it, or in fact anything guaranteed useful.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Generally speaking, I haven't met someone with a CCNP, CCIE, Novell Certificated Linux Engineer, MCSE that didn't have the know how to do their job. But maybe that's because those certification also have a practical element to them. I suspect you're confusing MCSE with MSCE, which is deprecated and previously had no practical element to them.
If I follow the money, I find that in corporate culture, very few appear to be using alternative non-corporate vendors. Most of the time in large enterprises, you end up with companies almost exclusively buying from one company due to having a support contract that pretty much covers everything they provide. This does come at the detriment that other solutions might be better in various circumstances, but because support is already paid for, approval is automatic, you still go ahead with company X's offering.
And they still get it, even when the company is doing poorly.
Change is certain; progress is not obligatory.
How is my reproduction of incohesive rambling of managers relevant to the TFS. I get away with allot of Free Software libraries (Apache/MIT/BSD licensed) integrated in commercial products. But each time I have new manager it takes a while to get them up to speed with the realities of licensing free software. All libraries used in out software needs to cleared with legal, so in the end it does not matter what the manager thinks.
As have I, but the specific certifications I noted haven't disappointed. Some certifications are more equal than others, maybe?
What do you do exactly?
World doesn't revolve around what we want sadly.
Change is certain; progress is not obligatory.