Bringing OSS Into a Closed Source Organization?

Piranhaa writes "At the major corporation I work for, there is currently a single person who decides what software to approve and disapprove within the organization. I've noticed that requests from users for open source Windows programs get denied, nearly instantaneously, on a regular basis. Anything from Gimp, to Firefox, even to Vim don't make the cut due to the simple fact that they are open source. Closed source programs from unknown vendors have a much better chance at approval than Firefox does. The whole mentality here is that anybody can change the source of a project, submit it, and you never know what kind of compiled binary you're going to get. I'm a firm believer in open source code, but I also know closed source has its place. So what would be the best way for me to argue, with all the facts, to allow these people to come to their own conclusion that open source is actually good? Would presenting examples of other big companies moving to open source work, and if so what are some good examples? Or can you suggest any other good approaches?"

Comments

Don't bother

[nyet]

Either live with your idiot bosses and stop complaining, or ditch that miserable excuse for an employer.

Re:Don't bother

[dfetter]

"Some men, you just cain't reach." http://www.youtube.com/watch?v=1fuDDqU6n4o
Since you don't have the option of clubbing this guy, get your interview on and find a job where they're not insane. This won't be the only, or even the biggest, moronic decision these people are making.

Re:Don't bother

[Kethinov]

I'm inclined to agree.

The whole mentality here is that anybody can change the source of a project, submit it, and you never know what kind of compiled binary you're going to get.

If someone important in the IT department at my company said something as grossly fucking stupid as that, then one of two things would happen. I'd either get him fired, or I'd quit and go work for a company that hires qualified people.

Re:Don't bother

[Ed Avis]

If you think that anybody can change the source code, then just try it. Get a line or two of your code into Linux, Firefox and Openoffice.

Re:Don't bother

[EvilRyry]

What's to stop a commercial vendor from putting evil code in? All it takes is one disgruntled employee and some poor review processes (which certainly isn't uncommon in smaller companies).

As a sibling has mentioned, most open source projects don't just allow everyone to commit changes all willy-nilly. Generally you send patches or pull requests in by email then the maintainers will review your changes. Eventually they might just give you the ability to commit directly (or they'll pull from your repository without extreme scrutiny in the DVCS world) if your code is consistently up to their standards.

Re:Don't bother

[Stormwatch]

If you think that anybody can change the source code, then just try it. Get a line or two of your code into Linux, Firefox and Openoffice.

Well, anyone can do a fork. I guess what those people fear is: someone takes the source and makes a near-exact replica of a program, but with some malicious function hidden there. Of course, anyone with a clue would know that Linux companies keep repositories, and they won't let such fakes in. Also, those malicious functions are often present in unadultered closed software.

Re:Don't bother

[SausageOfDoom]

My point was that it was similar to what security experts have been saying about the TSA - if a terrorist gets caught trying to smuggle a gun onto a plane, the penalty is high, they'll go to prison - there doesn't need to be a 100% success rate for detecting that to be an effective deterrent. However, if they get caught smuggling in a lighter and 500ml of petrol, they just chuck it in a bin and they get to try again - the TSA have to be 100% effective.

My concern was that it's a similar situation with closed v open source; if someone working for a closed software company puts malicious code into a project and they get caught, they lose their job and face legal action, difficulties finding employment in the future etc. There doesn't need to be 100% detection for it to be an effective deterrent. However, if someone wants to contribute a malicious patch to an open source project, if they get caught they can just set up a new persona and try again - there has to be 100% accuracy in detection of malicious code, and the various C obsfucation contests show that's not an easy task.

As with anything, it's an issue of trust. As Jesus_666 says below, since only trusted people will have direct write access to the code repository, they'll be ones who have invested a lot of time and effort contributing to the project in the past, and that would hopefully be a high-enough barrier to entry.

However, I think the danger in the open source community is that we might get complacent; as more people move to use open source software, the incentive and payoff for investing the time to breach the trust barrier of certain projects may reach the point where we shouldn't ignore the threat. Indeed, I worry that that point may already be here.

And we're not talking about someone breaching the codebase for the kernel, or Firefox or OpenOffice, although the risk for those is still there. I'm more concerned about peripheral projects which have more access than they should, such as google gadgets, or firefox or jquery plugins - get a couple of lines into the right place and you can hijack the browser. I'm sure there are similar weaknesses in other applications.

I guess what I'm saying is that the risks are real, and I can understand where the OPs manager is coming from. Although clearly extreme and I don't agree with the opinion that no open source project can be trusted, I can't help feeling that we arrogantly dismiss the risk altogether at our peril.

Re:Don't bother

[quanticle]

My concern was that it's a similar situation with closed v open source; if someone working for a closed software company puts malicious code into a project and they get caught, they lose their job and face legal action, difficulties finding employment in the future etc. There doesn't need to be 100% detection for it to be an effective deterrent. However, if someone wants to contribute a malicious patch to an open source project, if they get caught they can just set up a new persona and try again - there has to be 100% accuracy in detection of malicious code, and the various C obsfucation contests show that's not an easy task.

While that point of view is certainly a valid one, it doesn't really seem to fit with my personal experience (your mileage may vary). I've found that all of the major stories I've read about "logic bombs" and other malicious functionality being inserted into programs are about closed source, rather than open source.

I guess it comes down to motivation. If you've got an interest in an open source program, its likely because you're genuinely interested in helping the program and making it better. Also, you're already a user of the program - why would you want to make it worse for the next guy to use it? Finally, you're not depending on this program to provide you with a paycheck - if your code gets rejected or you get "fired" from the project, the sting isn't as painful as losing a job.

In contrast, the motivations behind closed source programming are a lot more diverse. If you see your (programming) job as nothing more than a paycheck, if you think your employer sees you as nothing more than a number on a balance sheet, if you never interact with the customers or users of your program, it can be very tempting to put in a logic bomb or virus as a sort of "farewell present" when you get laid off.

Find out who this person is and why they deny stuf

[Antique Geekmeister]

Seriously, you need to find the person and find out what their concern is. Is it a maintenance cost? A desire to avoid mixing and merging tools in-house? Are they concerned about who will be responsible, or liable, for problems with open source tools?

If their concerns aren't justified, and they can't be negotiated with, then they may need to be fired, or you may need to leave in order to get the tools you need. But their concerns are sometimes well founded: I've seen people who need a 99.999% uptime who were absolutely terrified of open source tools, had implemented closed source and very robust tools, but didn't realize that it absolutely prevented new development. That was OK, their requirements were very stable indeed. But it meant that they could not support projects from other parts of the company.

You've Already Lost

[TheWanderingHermit]

I'm sorry for posting as an AC, but the /. login doesn't seem to be working (no matter what I type in to the captcha, it doesn't let me verify my password!).

This guy is God as far as software at this company goes. He can do what he wants and unless there's a major catastrophe, his supervisors will let him continue to do so. If what you say is accurate, then he's made up his mind and there is no reason to change it at all.

You ask for "the best way for [you] to argue..." That's it right there. As long as you argue, you lose. He doesn't want to argue, he wants to be right and that, by definition, is what he is for anything he says at this company. He doesn't want to hear from you, doesn't care, and in any argument, if he so much as listens, he is indulging you.

True, he's an idiot, but that doesn't matter. He has no reason to change so he won't.

If you want him to change, remember he's like electricity: He takes the path of least resistance. For him to change or even look into change, then that path has to be made easier than him not even bothering to look.

When you can make it easier for him to look at FOSS than it is to ignore it, he'll start looking, but not until then -- and likely not even then if he has a grudge against it and doesn't want to admit it.

Re:Open Source means there's LESS chance of malwar

[setagllib]

Purchasing Windows doesn't give you an "assured" version either. The industry has learned that hard lesson over and over. You're much better off just licensing an open distribution like Red Hat, because you get the corporate support side as well as the community audit side.

The fact is that even if you don't have time to read the source, other people do, and a complete distribution has the unique level of multi-party quality assurance money can't buy.

Microsoft is probably the worst possible example anyway. They regularly put in their own malware. There's no audit required to know that WGA is pure and simple malware. It's absolutely moronic to name them as an example of an "assured" solution vendor.

Just tell his boss the cost

[AYeomans]

Doubt you will be able to change your control guy's mind with reason, so you have to play politics. Find an example where expensive software was bought instead of OSS and tell his/her boss how much the policy (note not "the person" - bosses can work it out) is costing the company. Of course, if the guy IS the boss or is related to the boss, just find another employer if it's that important to you.

great advice!

[lysergic.acid]

so either learn to live with the problem, or just run away from it? you must be a real winner.

most socially/emotionally healthy individuals have a powerful tool at there disposable called "interpersonal communication." by honing your communication skills, you can exchange thoughts and opinions with other people, perhaps even persuading them that FOSS is a viable alternative to proprietary software. but this is generally not a tactic used by people who spend their entire lives as a powerless passive observer.

assuming you know to speak up for yourself, there are a lot of ways to introduce FOSS to a close source organization.

1. start small. compile a list of FOSS software that you use at work to help you be more productive. personally, i use WinSCP, PuTTY, MySQL, PHP, YUI Library, etc. i would not be able to do the work required of me without these tools, at least no without paying much more for less efficient results.
2. document all of the proprietary software your company licenses which could be replaced by FOSS equivalents providing equal or better results--this includes desktop applications and sever software. emphasize the TCO that could be saved.
3. write a proposal. come up with some small non-vital applications that can be migrated to FOSS without disruptive business operations. for instance, set up an intranet site using FOSS software; perhaps a company wiki running on a LAMP server; or switch all IE browsers to Mozilla Firefox.

Re:great advice!

[unlametheweak]

most socially/emotionally healthy individuals have a powerful tool at there disposable called "interpersonal communication.

That only works if you are dealing with a socially and emotionally healthy individual that has interpersonal communication skills. I've seen very little of this in Management. In fact if management did have any type of skills in this situation they wouldn't have such unfounded biases towards open source software developers or the products they produce.

Re:Leaveve it alone

[turgid]

I used to work for BNFL (now the Nuclear Decommissioning Authority) and this was exactly their attitude. I tried very hard to explain things and not over-step my authority or sound like I was trying to undermine my superiors but the reply was always patronising, "We'd rather pay for a software license and have support when things go wrong." Note I'm not talking about nuclear safety-related software, merely office and programming tools.

After a few years, I got sick of the stifling environment and lack of direction and left for a better paid job.

I went to work for a big US computer company. Things were totally different there.

After another few years, the office close and I had to get a new job with a smallish British company. They were very open-source friendly although the Director of Software really admired Microsoft. There really was trouble there since as the skill base left due to fascist management, and the Director of Software tightened his grip, things went the other way. I quietly, discretely and politely offered to save the company £1000 that they were going to spend on some backup software for servers that essentially just did a dd of the root disk. I got a flame back telling me to keep my pathetic little minion mouth shut and I resigned like the 16 others before me. Two more resigned during my month's notice.

I'm much happier at my new place. It's a big company again with lots of rules and process, but their hearts are in the right place - the right tool for the job - and they appreciate ideas from their technical staff.

The moral of the story is be prepared to move on if the company doesn't suit you. It may take many months to find something new, but it's worth it. Work is a substantial part of your life. That time is too valuable to waste on something that makes you miserable.

Re:Play the game or go to a higher authority

[Bert64]

The problem is that large companies are packed full of people with little or no problem solving skills...
They either don't want to, or are incapable of trying to solve problems themselves, and would rather pay extra for someone else to do it...
Yes, they're basically not doing their jobs, and yet these blatantly incompetent people end up being paid a lot of money.

On the other hand, those people who are smart enough to solve problems (and it really isn't that hard) can set up support consultancies and employ people to do what you're doing on behalf of other companies.

I've seen countless situations where relatively simple problems were unable to be solved internally, and the people who's responsibility it was to fix them just wanted to hand them off to a third party as quickly as possible, and simply didn't have the skill to diagnose what was wrong.
The issue took a few seconds to diagnose, and a few seconds to fix once someone with the right mindset started looking at it.

Re:I don't get this

[jcr]

Isn't this the reason you own guns: to defend yourselves from utter tossers in the workplace?

No, we own guns to prevent the government from having a monopoly on deadly force. Governments have different options available to them when the people are armed, than they do when the people are unarmed.

-jcr

Re:The RIght Way to Look at it

[Johnny Loves Linux]

I think the better way to look at the problem is to start with this question:

"How do you know you can trust *any* software project?"

Well, how do you do answer that question? There are lots of ways of answering this question
but the one that stands out for me is this:
1) Trust, like respect, has to be earned. Has Project "foo" screwed me over in the past?
Yes or no, no equivocation?
2) If the answer is Yes, was it an isolated event? Was it an accident? Did the project people repair their mistake quickly, or did they let it linger and left me hanging?

a) If it was an isolated event, and they stayed on top of it, then yeah, I'll give them a second
chance.

b) If it was an isolated event and they left me hanging, screw them, they're out. Next!

c) If it was not an isolated event, then that's it, they're out permanently. My time is limited and I can't afford to wait for them to reform themselves.

Now that's *my* criteria for deciding. Your criteria is ... your criteria. Based upon *my* criteria and my *experience* I can say the following:

1) Most of the Free Software (GPL, MPL, BSD, etc. licensed) that *I* use is excellent --- it does what I want, it's well documented *for me*, it has a good *publicly documented* record of fixing bugs and staying on top of things.

2) Most of the Proprietary Licensed software that *I* have used has been crap in the sense either it does *not* do what I require, or it's buggy, or it's poorly documented, or it has legal encumbrances that make it problematic to use, etc.

I want to be very careful here. I am *not* asserting that most Free Software is awesome and most proprietary software is crap. I'm only asserting that the software that *I* have *tried* from those models of software licensing have pretty much been: Free Software == Awesome, and Proprietary == Crap.

Now *why* is this true? Because I don't use Joe Random Free Software and don't use much Joe Proprietary Software.

The Free Software has been vetted by my OS of choice: Debian Linux. If it's in Debian's repositories then I'll give the software a shot. If it's not in Debian's repositories I don't want to look at it. I'm not interested in ever having to manually download, configure, make, make install software. I trust Debian as my big ass filter of crapware. If some Debian developer took the time to package some Free Software then it must be good, because Debian's guidelines for getting software into the repository is not for the faint of heart. That and the fact that their bucket brigade of QA ensures that when the software makes it into Debian's stable branch it might be obsolete but it's rock hard stable.

I don't use much proprietary software today. The only thing that comes to mind is Adobe's flash player. I used Microsoft Windows before Windows 2000 came out and by that point I had given up on them for being flaky once too many times. I used NVidia's kernel module for accelerated 3D graphics, and it was ok for a while, until I got burned once too many times when I upgraded Linux kernels and Nvidia hadn't kept up with Linux. The final straw was when Nvidia declared my hardware as legacy. In the case of Adobe's flash player, it's gotten better I think. The only thing that bothered me about it was its tendency to crash iceweasel, and not work very well with konqueror, and stealing audio (oss sound driver I think). The only reason it's still with me is because of youtube and because I'm waiting for gnash (Free Software) to be stable enough and not
suck up too much CPU usage.