Bringing OSS Into a Closed Source Organization? 427
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?"
Don't bother (Score:5, Insightful)
Either live with your idiot bosses and stop complaining, or ditch that miserable excuse for an employer.
Re:Don't bother (Score:5, Insightful)
"Some men, you just cain't reach." http://www.youtube.com/watch?v=1fuDDqU6n4o [youtube.com]
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 (Score:5, Interesting)
Forgive me if I'm being stupid, but this is actually something I worry about. I'm a heavy user of open source, but surely it is true 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" - isn't that kinda the point of open source? And we just hope that someone else notices if the changes are bad?
I know this sounds like I'm trolling, but I'm not - it's a serious question. How do you know you can trust open source projects? I've always assumed that large projects - particularly linux distros and their package repositories - have some kind of QA and code audit system in place, but how do they work? Are a couple of naughty obsfucated lines really going to get caught?
Sure, many eyes on the source code and all that, and there would be the same risk from employees at closed source organisations - only difference being it's easier to get to work on an open source project, and if you get caught adding bad code, you don't lose your job.
This sort of thing is becoming an even bigger problem with the web in general; facebook apps, igoogle gadgets, even things like firefox and jquery plugins - the more I think about it, the more paranoid I become.
What processes are in place to protect users from malicious code?
Re:Don't bother (Score:5, Insightful)
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 (Score:5, Insightful)
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 (Score:5, Insightful)
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 (Score:4, Insightful)
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.
It's like anything else ... you have to make a risk/benefit analysis. Most people aren't very good at that, especially people that are part of a corporate hierarchy (they'll pick whatever the prevailing winds tell them will preserve their job.) Whether the technology under discussion is nuclear power, vaccinations, or open source software, the reality is that you have to accept some risk. That, or spend your life cowering in a cave. The problems come in when people believe that they can have the benefits of high technology with zero risk. That's just not possible, not at the current state-of-the-art, and will probably never be.
So, yes, there is a finite possibility that someone will, or already has, compromised a major open source application in some way. People have tried in the past, it's true. But it all comes down to that risk/benefit ratio again. So far as browsers are concerned, if you choose an Internet Explorer, you know that you're at a substantially higher risk of external compromise in spite of the closed source nature of the program. With a Firefox, you have to balance the risk of a possible built-in exploit with the fact that it's otherwise a much more solid product security-wise. Where does the greatest risk lie? Sure, there are other browsers, but as products of the human mind they are also imperfect, so the same rationale applies.
All you can do is take your pick and hope for the best.
Re:Don't bother (Score:5, Insightful)
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.
Re:Don't bother (Score:4, Insightful)
I think your ignoring the fact that creating malicious software is illegal for the most part. People who write virus's are actually criminals and often do get caught. If someone were to contribute something like you suggest, they would/could be prosecuted under the same grounds as the author of a virus in many jurisdictions.
As for C obfuscation, it is near impossible to do so because the code submitted is reviewed before going into the project. Unless the author of the malicious code was the project leader (then your in no different of a situation then with a closed source business), the code will be reviewed by others and they will have to understand it's function. You also have standards that simply wouldn't allow obfuscated code into a project- this is a benefit of being open.
Even when someone has write access to the repositories, those repositories aren't in the production line. The code contributed to them will still be reviewed before being committed to the active product if for no other reason then stability. But again, if it is a project leader who is doing it, your in a worse situation then with closed source because others can and will look at the code. It might take a while but there are record of who did what that are preserved and the culprit will be caught.
I think your risks are being overstated a little. True some of the less successful projects will be more lax in their security, but then the moral is to just use the larger and more trusted projects or just check out the projects your going to use thoroughly. I personally don't even do MS updates until they are out at least 3 months and I can find out if or how they borked someone else's systems. Of course I have firewalls and adequate virus protection so it isn't like I'm flying blind for three months.
Re:Don't bother (Score:5, Informative)
The same ones that protect us from malicious proprietary software, execept there is many many more people doing it, and it is a hell of a lot easier to do.
Re:Don't bother (Score:5, Informative)
That's really the only way to accept outside patches bcause without this system the code would soon become a convoluted mess full of incompatible code and patches against ancient versions of modules that no longer exist.
Re:Don't bother (Score:5, Insightful)
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 (Score:5, Informative)
a commercial software vendor could get sued (or lose credibility among people purchasing it..and lose the business) if there is malicious code in place, so it is in their best interest to make sure it's not there.
Not necessarily. Its pretty standard practice among software companies to put a clause into the license agreement indemnifying them from losses caused by the program. Every closed source program I've purchased has had that clause, either in the click-through EULA or on a slip in the box.
Re:Don't bother (Score:4, Informative)
It's entirely possible that malicious code could be inserted into an OSS project. But it's far more difficult, and far more obvious than in closed-source projects. There, one programmer can make one change, and if the others on the project never look at it too closely, NOBODY will ever see it. The simple fact that someone *could* see your submission to an OSS project keeps out most of the malicious code.
Re:The RIght Way to Look at it (Score:4, Insightful)
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.
Re: (Score:3, Interesting)
I know it's a cliche, but unless you actually audit the code (and don't miss something) you can't really trust it. The best that you can
Re:Don't bother (Score:5, Insightful)
I'm inclined to agree.
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 (Score:4, Funny)
That would be my plan as well. But before I did that, I would make him some "brownies" and not tell him what was in it and only a vague idea of who it's from... (muhahahaha!)
If he eats, you might later tell him what might have been in it and who might have made it.
great advice! (Score:5, Insightful)
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.
Re: (Score:3, Insightful)
so either learn to live with the problem, or just run away from it? you must be a real winner.
Some kinds of disagreement point to problems so fundamental in the higher-ups that it's not worth trying. Visceral rejection of free software is one of these.
Re: (Score:2)
Addendum: As for your time consuming suggestions I would say it is a waist of time. One might as well just have a suggestion box (which is a euphemism for a garbage can). In my experience people don't get into Management because they are smart or hard working (willing to read and analyze these suggestions). A good Manager will smile and say thanks a lot before ignoring you. A bad Manager will just condescend.
Re:great advice! (Score:5, Insightful)
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: (Score:3, Funny)
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,
Wait, let me write this down.
Theorically could this "interpersonal communication" be used to communicate with the opposite sex?
Re:great advice! (Score:4, Funny)
Then, send a request for some of these applications. The high prices and abusive licencing terms you added to the packages will lull them into a false sense of security, and you'll be all set!
Please note, I do not actually recommend this.
I don't get this (Score:2, Funny)
Sorry, I'm an outsider to the US, and I keep hearing this thing about the right to bear arms.
Isn't this the reason you own guns: to defend yourselves from utter tossers in the workplace? What's the point in all this gun ownership, if you can't kill middle-managers?
Re:I don't get this (Score:5, Funny)
The reason you don't get it is because you don't fully understand. "The right to bear arms" doesn't mean you have the right to hold a gun. It means you have the rights to wield arms of a bear. Unfortunately, they're a little cumbersome, so no one really uses them.
Comment removed (Score:5, Insightful)
Re: (Score:3, Insightful)
Re: (Score:3, Insightful)
Re:Don't bother (Score:4, Funny)
At the major corporation I work for...
I agree - I think the fact the poster is working for Microsoft is at the root of the problem.
Re:Don't bother (Score:4, Insightful)
I was going to suggest something similar.
Assuming the company has a testing process in place for new software, why not just take a particular version, test it (same as you would in any commercial software) and "freeze" that version in your company's Definitive Software Library. It actually reduces the cost of testing, because the software will continue to be available for however long it's useful and you don't have to test every single ^%&^ing revision that some half-@r$3d supplier plonks out every other month.
Your boss's "anyone can update the binary" is immediately nullified -- your tested version can't be externally changed. If there's a branded source rebuild it's obvious when anyone installs an unauthorised version.
HAL.
Play the game or go to a higher authority (Score:5, Informative)
Some people/companies just want a name to blame if something goes wrong. Rather than requesting the right to install Vim, request the ability to purchase a license for Vim. Many projects have already setup mechanisms to do this or are willing to do so.
If this doesn't work because:
then go to your manager and also the person or people who decide to how good of a job the "software evaluator" [single person] is doing. Point out a real business need for a particular application: "Vim has XXX feature. It is not available in any other software. If I had this feature, I'd be able to do YYY, which will [save/make] our company $[insert figure here]. Did I mention that it is written by a google employee, and that our competitor, ZZZ is probably going to use it if we don't? Here's a list of other companies that use Vim [insert fortune 100 here]. Can you please make [single person] justify why he is putting us at a competitive disadvantage?" Cost is rarely a concern. So save the fact that it is free as an additional argument that you can make if [single person] suggests some other app.
If you are passionate enough about your tools, you can always walk--some companies hire talented employees and understand that they will be more productive with their preferred tools. (If you find yourself in such a company, don't spoil it--produce results with your tools, so that the company will be rewarded for this wisdom.)
If you want to be a dick, point to comparisons of some no-name proprietary program that [single person] approved that turned out to have a security hole and that your app does not suffer this hole and try to pull other tricks to demonstrate that [single person] is incompetent.
Re:Play the game or go to a higher authority (Score:4, Insightful)
You know, sometimes these guys are above 'your manager'. Way above.
From what the OP says, it sounds like the person he's referring to is something like a Chief Compliance Officer [wikipedia.org] at his company. If that's the case, tough luck.
There is a possibility that the reason why open-source software is not approved for use is because it doesn't meet the compliance standards that were put in place, whether because of simpler and easier application support, patching, or just plain liability.
Open-source software often times as very poor support options. Forums and IRC are not substitutes to a dedicated phone support line that's manned 24/7.
User all the open-source software you want on your free time, OP. During work hours, play by their rules or find another job.
Re: (Score:3, Informative)
We can speculate about his company's org chart forever. I did state that the poster should go to the boss of whoever is giving him grief. I disagree with your reading of the situation; I take the claim "programs from unknown vendors have a much better chance at approval" at face value. There might be some chance that an unheard of company is making "compliant" software, but I doubt it. Given that there is some mechanism in place to get some software approved, this doesn't really smell like a CCO to me (
Re:24/7 support (Score:2, Insightful)
Honest question here, does the 24/7 support ever solve problems? The only time i ever bothered to complain about a faulty product ( a television set that was under guarantee ) all that happened was i got dicked around for 18 months while it got taken away, brought back, failed again, taken away etc. I assume the job of 'support' is to occupy the customer until they get bored of complaining/die/find a work-around/buy a different product.
Re:Play the game or go to a higher authority (Score:5, Informative)
Open-source software often times as very poor support options. Forums and IRC are not substitutes to a dedicated phone support line that's manned 24/7.
That is simply wrong. A wide used and successfull OSS Software (CMake, Subversion, Apache, Vim, Eclipse) to name just a few of those we use in our Company (a very Big Company with more than 700K Employees) have excellent support. It comes in forms of Forums, thousand of Google hit's on every problem and of course IRC and Mailinglists.
As main user or tool responsible person of some of those applications, I never encountered a Problem that I couldn't find quality problem solving information for.
CSS support via closed ticket systems that aren't even indexed by search engines simply can't provide a similar support in my eyes.
Open Source Software comes along with "open problem solving" and that is a big advantage over their closed source counter parts.
Re:Play the game or go to a higher authority (Score:5, Insightful)
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:Play the game or go to a higher authority (Score:5, Interesting)
If a company has a chief compliance officer, they are likely bound under some corporate regulation like Sarbanes-Oxley, HIPAA, or something else. To keep the officers from going to prison, one of the things they need to do is "due diligence".
This is making sure that every product in a chain is certified by a vendor in some way. For example, operating systems must be FIPS and Common Criteria certified, encryption products must be listed in the US Governments certified AES libraries, and so on.
Yes, some open source products make this list. SUSE and RedHat Enterprise Linux both have the certificates. However, not many open source solutions do, which is why businesses just go with a Microsoft stack for their applications.
For example, if a business is running a MS stack, and there is a serious data breach, said business can show their policies in place, show that they have done due diligence by using commercial software everywhere, with certified configurations, they will not have to worry about civil stuff like stockholder lawsuits, or criminal stuff like the SEC coming in with audit papers and handcuffs.
Unfortunately, should a similar breach happen with a company that has an open source stack, and can't really prove due diligence by showing that every piece of their IT puzzle was certified by someone (usually a US government agency)... well, they are facing a world of civil and criminal liability.
To be honest, the chance of getting open source software into an environment that has to be so heavily audited and regulated is almost zero. Commercial, closed source software dost cost, but part of the cost is insurance and the ability to blame someone else other than the company or its officers and staff should something bad happen.
Another legal issue of why businesses choose closed source solutions is patent indemnification. If a software company doesn't have this protection for its customers, should a patent violation occur with the software, not just the software company, but all its customers can wind up being sued for obnoxious amounts of money, and possibly shut down. Again, RedHat is one of the companies that offers this protection for an open source product, but few others do.
None of this is related in any way to the quality of programming of open source software. Its all security theater, but its what keeps a company in business and its officers out of prison with the regulations in the US.
Re:Play the game or go to a higher authority (Score:4, Interesting)
SOx has actually produced almost the opposite reaction, with OSS you can validate the code path, but with CSS you cannot and almost every vendor in existance has explicity information in their EULA that states that they are not responsible for anything basically related to any type of "protection"
Re: (Score:3, Insightful)
That's what CFOs want to hear: that in the however-unlikely eventuality that there's a serious problem with software, you have a Throat to Choke.
I understand the theoretical value of this, but I have never heard of anybody suing their way past Microsoft's EULAs, or getting any sort of compensation for bugs, no matter how heinous. If you can point me to documented cases of that, I'd be fascinated.
Until I see that happening on a regular basis, as far as I'm concerned it's a distracting fantasy. Much more valuable to me has been the ability to pay people to fix bugs and add new features. A lawsuit might pay off five years from now, but getting a perfor
Re:Play the game or go to a higher authority (Score:5, Interesting)
In my case it is the owner of the company where I work.
While I cannot speak for the personality of the OP's boss - mine is at least a very decent person.
So I walk into work and inherit an old Dell Latitude D600 running WinXP.
A month into the job I trash it and install Linux. I am now the only person in our company using Linux/OSS for everything I need to do.
I inherited a desktop PC that still runs XP - our control software is written in MS Access so I could not run that on Linux.
One day my boss remarked in a meeting that "You know you need to be able to run Windows dependent software on your laptop" which is his roundabout way laying down a kind of challenge to me.
So I set up our proxy server to allow me to SSH in and rdesktop to my desktop when I am on standby. The other tech's needed to make an offline backup of the control DB and then merge it with the "live" DB.
A week later in another meeting he reminded me to merge the database. "No need, I run the DB live"
So two months ago I was offered part ownership of the company and promoted to tech manager in the interim.
Sometime you need to play on the ragged edge for a bit in order to get your point accross.
I still run Linux on my laptop, and my whole tech team goes for weekly training on Linux with our sister company who is a Linux solutions provider.
Re: (Score:2)
Most open source products have 24/7 support available if you're willing to pay for it... If you don't want it, you pay nothing and still get to use the app.
Similarly, most closed source products come with little or no support by default, and you then have to pay even more to get a decent level of support.
But more importantly, closed source typically gives you one choice for support - the original vendor, third parties don't have sufficient access to the app to provide a proper level of support. Open source
Re: (Score:2)
You're a bigot. Either that or a lying astroturfer. Let me fix that for you:
Closed-source software often times has very poor support options. Unanswered phone calls and "we'll fix it in the next release in a year's time" are not substitutes for email messages often returned with fixes in hours.
The reality, not the fiction that you're spouting, is that you can get support for any software, closed or open. Except that with open source you have more competition and more options.
---
Open source software is ev
Re: (Score:2)
> Cost is rarely a concern. So save the fact that it is free as an additional argument that you can make if [single person] suggests some other app.
Was (fiscal) cost mentioned at all here? Sure, all the open source products mentioned also are cost free, but Open Source != Cost Free.
Also, Open Source doesn't mean anyone can 'just change the code'. You can *fork* the code and change that, but I don't see how you can change the code in, for example, Red Hat Enterprise Linux, to name but one, even though it
Comment removed (Score:3, Insightful)
Re:Open Source means there's LESS chance of malwar (Score:2)
That is simply not true in practice. Most people do not audit the source code of their favourite Linux distribution. Even if they did, there's no guarantee that the code they have installed from the DVD was compiled from the source that they looked at. Contrary to popular opinion in the open source community, most people don't want to compile all their software themselves.
It's not even as if having availability of source code means you will find all of the hostile code that is in it. Debian managed to d
Re:Open Source means there's LESS chance of malwar (Score:5, Insightful)
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.
Re:Open Source means there's LESS chance of malwar (Score:4, Insightful)
My sister-in-law worked for a huge company, one very similar to Dilbert's employer. She was at least partly, if not fully, in charge of the decision to reject all open-source software. I had a long debate with her on this topic, but she's completely unwilling to move. She firmly believes software is worth no more than what you pay for it, and those promoting free software are dangerous socialists, anti-free-market crusaders trying to tear down America.
I've also tried to convince her over the years that George Bush is a poor president, who has in fact made some mistakes. While she's a super-bright energetic well educated woman, my sister-in-law is incapable of thinking any republican president has ever done any wrong.
I think people like my sister-in-law are firmly planted in important corporate positions throughout our country, insuring that Dilbert-Land will continue unimpeded. To them, free-as-in-speech is a silly concept for children. You give it lip-service, but never put any money there! What counts is free-as-in-market. These free-as-in-speech programmers are just more Vietnam protesting nit-wits who will ruin the country.
Re: (Score:2, Funny)
Where were you when she was marrying your brother?! Always make sure to get their views on open source before, it saves any nasty surprises later on.
Re: (Score:2)
You are missing the point between what you consider quality software and software that passes a government audit. Just like the parent said, if we are looking at a product and it doesn't pass regulations - we can't even really look at it.
Now the question you should ask here is what passes regulations. With the laws being so vague and having so many contradictions, the real answer about what passes and what doesn't is what the big third party auditors say passes. So what you consider assured is much diffe
Find out who this person is and why they deny stuf (Score:5, Insightful)
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.
Follow the Money (Score:5, Interesting)
Sounds like this person has a deeply vested interest. I would guess that the real problem with open-source software is that it's free (as in "beer"!) so no chance to cash-in by playing favourites.
Find out where the kickbacks are coming from and blow the whistle.
Re: (Score:2)
Re:Follow the Money (Score:4, Insightful)
Leaveve it alone (Score:2)
Re:Leaveve it alone (Score:5, Insightful)
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.
You've Already Lost (Score:5, Insightful)
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.
Get the roadblock out of the way (Score:4, Funny)
Re: (Score:3, Funny)
Find another job (Score:3, Insightful)
Get support agreements in place (Score:2, Insightful)
I've worked in several large corporations, and was faced with similar challenges.
Often times, open source software is not viewed as a serious option because (depending on what software you're looking at) there isn't a singular reliable source of support, and due to legal reasons, a large corporation just cannot afford to take a 'gamble' with open source. You need to pick your battles and pick them well.
I'm not implying that open-source software is better or worse than commercial software, but the dedicated
Re: (Score:2)
The idea of a singular source of support is pretty offputting to me...
A single source of support is a monopoly, they can provide half assed support at premium prices and you have no choice but to suck it up.
ZenOSS is a good example here, does anyone else provide support for it? Do you think their enterprise support would improve if someone did?
RedHat is also a good example, many other companies provide a supported Linux distribution, if RedHat provided lousy support they would lose customers very quickly.
Other concerns: OSS creep into commercial code (Score:5, Interesting)
While I was working for a former employer, we were engaged in negotiations with a very large company that would act as a distributor (to a certain market) of our products. Said unnamed company in the distribution contract wanted us to sign off that "no open source software products were used in the development process, and that no OSS was present in the product".
Why?
Frankly, I understand the concern. If you are a development shop, then if OSS creeps into your product (due to a careless (and thoughtless) developer copy-pasting code, for instance) then the legal ramifications may be grave. Potentially, depending on the license, you are required to disclose the entire source of your product, and provide a usage/distribution license to whomever receives that code -- basically, a single minute action can sign off your rights to your software. your distributors have also violated copyright, and are in similiar hot water (e.g. their efforts in promoting your product are now potentially worthless).
The result? Some companies are so afraid of this "poison pill", that they simply don't let any OSS in their gates. Does this promote OSS? Maybe. IIRC, I recall that some friends working for the dark side (M$) report that no OSS is allowed there (or in some parts thereof).
I use OSS extensively. The former company I worked for had a whole heap of OSS in its development process (but not in the developed chip/product). Actuallly, considering that a non-OSS company (Altera) used OSS in its supplied development chain (gcc, for instance) that we were using, there really was no conceivable way that the company I worked for could've signed off on the "no OSS" bit of the contract.
Addendum: OSS hunts in commercial products (Score:2, Insightful)
As a small addendum, remember those fellows that found OSS in the infamous sony rootkit (by various strings present, IIRC). A week or two later the same guys (or someone else) found OSS in some other commercial software product. IIRC, there was some legal action (from FSF?) following this.
It used to be, that if you screwed up and placed OSS in your product that the chances of being caught in the act of theft were fairly low. Currently, the chances of being caught (even if your act was inadvertent) ar
Re:Other concerns: OSS creep into commercial code (Score:4, Informative)
If you are a development shop, then if OSS creeps into your product (due to a careless (and thoughtless) developer copy-pasting code, for instance) then the legal ramifications may be grave.
Why do you think this problem is unique to OSS? What if one of your developers has access to a Microsoft source license and starts copying and pasting code from there. Do you think the "legal ramifications" of that action would be more or less serious?
Compared to using an LGPL library, this could leave you open to huge liabilities.
If you don't control what your developers are up to, and have frequent, in-depth code reviews, then you're asking for trouble, OSS or not.
Rich.
Re: (Score:3, Insightful)
"no open source software products were used in the development process, and that no OSS was present in the product".
I understand that the company may be afraid of being infected by the GPL and their software becoming a zombie or something, but that's a huge overreaction. I use Winmerge [winmerge.org], (which is GPL'd) to compare files "in the development process", but it has no implication on the licence of the final product.
If I work from an example that's under BSD licence, it has no implication on the licence of the f
Re: (Score:2, Informative)
> Frankly, I understand the concern. If you are a development shop, then
> if OSS creeps into your product (due to a careless (and thoughtless)
> developer copy-pasting code, for instance) then the legal ramifications
> may be grave. Potentially, depending on the license, you are required to
> disclose the entire source of your product,
Bullshit.
If OSS "creeps into your product" by mistake, you won't ever have to
disclose the source code you have written. You just lose the right to
distribute the pr
Re: (Score:2, Insightful)
If the OSS advocates were really acting in the public interest, they would permit resale of open source code. This would not damage OSS, but would increase the variety and quality of software on offer, either free or not free. Instead they have progressively taken the licence in the opposite direction. Embrace, extend, extinguish indeed.
IMO killing proprietary software is a Good Thing so they're acting in public interest. Nothing prevents current proprietary software businesses from embracing FLOSS model and sell support instead.
Re: (Score:2)
Yes, killing proprietary software would be good...
Proprietary vendors have time and again proven they cannot be trusted, getting their customers locked in to proprietary formats so they can't leave rather than competing with a better product.
We'd gain the ability to modify code, switch to other providers at will, choose who we want to provide support or even choose not to have paid support if we have the skills and save the money.
OEMs would gain the ability to customise the software as much as they wanted t
Resale of Open Source (and GPL) code is permitted (Score:2)
There's absolutely nothing in any OS license I'm aware of that restricts resale of code.
Just tell his boss the cost (Score:5, Insightful)
Re: (Score:2)
You're absolutely correct. If someone excludes options it means they have their reasons for it, political, imposed policy, vendor goodies or maybe just being nervous to go unchartered waters (in itself not a bad thing as long as it occasionally involved re-evaluation of the underlying decisions).
Plus, the guy may not have the mental strength or clout to get into a battle he can't win [boycottnovell.com] because companies are presently as little controlled for their abuse and malfeasance as bank and politicians are (and we kno
Re: (Score:2)
I'd argue that in a shrinking economy, being known to your boss as "the one that went over his head" might be detrimental to your career.
Even if he gets an order from above to take F/OSS seriously with no hint as to what prompted such an order, he's going to wonder what prompted it himself - and "that guy who keeps asking to install Firefox" is going to be #1 in the list of suspects.
Open source issues (Score:2)
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.
That's why open source has source. You can examine the source code to see if there are any strange patches. Compile it yourself and then you know what kind of binary you're going to get.
That's also the big benefit of open source. There are thousands of eyes looking through it for the larger projects. You also get the benefit of customizing the source for your own purposes (and if you don't distribute the end results, you don't need to distribute the source of your changes, either, for the software under
Start at the bottom, and top (Score:2)
1) Convince his superiors that a particular open source program is the best available for the job. If this works, try with another one, but make sure you point out the open source nature of the program.
2) Talk to your workmates about open source software that you use, and try to get them to request some of this software to be available to them. For bonus points, try to get them to complain (with email evidence) when software is rejected to the people who evaluate the performance of staff.
It'll take a long t
What's in it for the company? (Score:3, Insightful)
As with any idea you want to sell, you have to pitch it in terms of what the company wants. Most companies aren't going to be motivated by a philosophical argument. You have to ask yourself: If the company started using open source software, would it have a significant postive effect on the bottom line? If not, your unlikely to succeed.
They probably already use OSS anyway (Score:5, Funny)
In the end, the best way to make these non-technical PHBs see sense was to simply point out all the OSS they were already using, without even knowing it.
Those HPUX servers? Running Samba shares.
That F5 SSLVPN network appliance? FreeBSD!
The most priceless moment was when I discovered the main OSS opponent was an avid Firefox user. He referred to it as "Microsoft Firefox".
Create OSS adoption guidlines (Score:3, Informative)
In my organization I wrote up a risk analysis for Open source and closed source software,
detailing the risks in each.
How does malicious or dangerously buggy code get into each type of project. how do you assess the threat in both types of software:
What is the review process?
How big is the project?
did you compile the software yourself? who did?
how did you get the software/source code. etc.
This document was picked up by other people who eventually turned it into company guidelines for OSS adoption.
Me.
Re: (Score:2)
Yes, the risks of incorporating open source under licenses such as the GPL into a proprietary product you distribute are valid, however...
There is also the risk of incorporating closed source code or linking to / distributing a proprietary library.
But this is assuming your business distributes closed source software, which most don't.
If you do get caught using code in violation of it's license, those enforcing the GPL will usually want you to stop infringing, whereas a proprietary company will often want a
Have Him Fired (Score:2)
Seriously, after all these years of success and reliability, anyone claiming Open Source software is an organizational threat is simply in the tank for Microsoft. Firefox, a threat? VIM, a threat? While Internet Explorer and MS Word are paragons of safety? The man is provably out of his fscking mind.
Schwab
Travel the official Software Acquisition Path (Score:2, Insightful)
In my experience, your best bet in these cases is to walk the company's official path for software acquisition.
If no such path exists, your first step is to convince management to create it. Your common goal is to get the best sollutions for the problems at hand.
Here is a very usefull link of the dutch government on making FLOSS a viable option for software acquisition:
--> http://www.ososs.nl/files/acquisition_of_open-source_software_-_text.pdf [ososs.nl]
Defence Department (Score:2)
Give up and/or move on (Score:2)
These folks usually need a near death experience to change their mind. You won't change it. It's only when competitors are closing in, that's when folks like these give up their superiority complex and do what the engineers say. But by then it's already too late.
Use your enemy (Score:2)
Step 2. Maneuver yourself into being next in line for his job.
Step 3. Encourage end users to complain about the software as much as possible. Plot behind the scenes to make sure his bosses know he is responsible.
Step 4. Once he is fired, take his job and replace the closed source software with op
Ask Slashdot (Score:2)
Shouldn't this have been in Ask Slashdot instead of News?
Re: (Score:2)
Absolutely.
There's not even a link in the summary, so even a /. editor should be able to tell a question being asked from news being submitted...
np: New Order - Elegia (Low-Life Extras)
Cluetrain boarding now... (Score:2)
Your open source software blocker is being paid off by the vendors. Maybe not in cash, might be just in dinners, trips to "conferences", or perhaps just in building his ego.
This is one of the barriers to OS software adoption that is not yet recognized.
oh hai (Score:2, Funny)
At the major corporation I work for, there is currently a single person who decides what software to approve and disapprove within the organization.
Give Mr. Jobs my regards.
Address the facts (Score:5, Informative)
It sounds like his argument against FOSS is fact-based, not political. Address the facts.
He believes that anyone can change the source of an open source application and recompile it. That is TRUE. He is right to identify that as a vulnerability. The mitigation is to only download binaries from trusted sources and verify them with checksums, or to download the source, inspect it, and recompile.
His conclusion that applications from proprietary sources are therefore inherently more secure because they cannot be recompiled, however, is INCORRECT. From a security standpoint, using a binary file requires a higher level of trust because it is more opaque. It is far easier to to hide an attack in a binary file precisely because one cannot inspect it as easily as one can a source file.
The threat order, from most threatening to least, is:
The point is, NOTHING should be accepted without verifiable trust. Being able to personally inspect the source code provides an additional level of protection, and is therefore SAFER from a security standpoint.
For personal use, I trust everything at level 3 and higher (binary from trusted agent, no checksum). That's fairly risky, but acceptable for a single machine. If I were in charge of the corporate desktop, I would elevate to level 4 (binary from trusted agent, with checksum). This is the level that Microsoft products are distributed at, for example. If I really were concerned about the security of an application -- say, if I were in charge of writing voting machine software -- I would insist on elevating all the way to level 6 (source from trusted agent, with checksum, scanned by me and recompiled with a new checksum.)
Re: (Score:2)
Note that 5 and 6 are only less of a threat if compiled with a compiler for which you have the source code. But hold on, how do you compile your compiler? You better do it by hand:
http://it.toolbox.com/blogs/puramu/ken-thompson-and-the-selfreferencing-c-compiler-16142 [toolbox.com]
Clueless... (Score:3)
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.
What, and all the viruses that can attach themselves to existing binaries clearly have never existed?
If you have the source code, then you have the opportunity to compile your own binary and be sure what's in it.
Don't bother. (Score:2)
Don't bother. Go get another job elsewhere.
Or as someone posted earlier, "Either live with your idiot bosses and stop complaining, or ditch that miserable excuse for an employer."
We use OSS almost exclusively where I work... the only commercial software we use is Microsoft, and even that we try to avoid as much as possible.. (there's only a very few window's pc's with MS office for example.)
It's not about malware, support, or quality... (Score:5, Informative)
- Malware? We were confident enough to see there were sufficient controls around code changes.
- Support? Easily handled by our existing channels, even for elaborate changes and additions.
- Quality? Millions of users can't be wrong...
The one thing we struggled with was: liability. Our own, our manager's, the software approval guy's. The problem is this: what if that bit of open source software contains proprietary code, and the owner of that code suddenly starts asserting his rights? At best, we will be forced to stop use of that software.
You can argue that this is also a possibility with commercial software, which is true. But with commercial software, the owner of the infringed code will go after the creator of the software. Better yet, we too get to sue his pants off. In the case of open source, they are likely to sue not the creators or distributors of the software, but the people using it. That means us, and the legal eagles don't like that, oh no. Remember the old maxim "No one has ever been fired for buying IBM"... that goes doubly for OSS. OSS exposes you to lawsuits, and when the stuff does hit the fan, the buck stops with you.
In the end, OSS was allowed in our corporation, provided that it isn't used for mission critical purposes if no commercial drop-in replacement exists. If the software develops issues, there's still no vendor to blame for me, but I can live with that, personally.
Re: (Score:3, Insightful)
Why is that "better"? Very likely a software developer (anyone smaller than IBM) in that position will declare bankruptcy, or just disappear. You're very unlikely to get a cent back, no matter if you win your case or not.
Anyway: what if that bit of open source software contains proprietary code, and the owner of that code suddenly starts asserting his rights? At best, we will be forced to stop use of that software.
No. At best, after a brief hiatus the infri
Re: (Score:2)
It's not about getting our money back or claiming damages, in fact it's unlikely that it would ever come to a lawsuit. But having someone else to blame to the point where you could sue him, means that there is that much less blame to apportion inside the organisation. Cynical? Yes, bu
My Uni (Score:2)
I happen to use many OSS portable apps, like firefox winscp and open office (even thought word is there) but I used to install gimp portable, and no longer have to as someone requested our computer tech guy to install gimp on all the computers!
So now I can introduce my colleagues to open source software for their simple/mid level image editing and they don't have to stuff aro
Dont bother (Score:2)
"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 that is their mentality, you have already lost with all arguments.
You cant try to understand that not everyone can get code to applications, only a trusted onces. Altought, everyone can send patches and new code, but it will _always_ get viewed by at least one truested coder and even can get easily modified someway in the process if the code is not so good already.
It is as easy to get a malware code to opensource software, as it is to get to closed source software. But you, as client, has better change t
evaluate OSS and CS on the same benchmark (Score:2)
My advice is to evaluate the merits of your software shortlist on EQUAL basis. Get your decision makers to agree criteria for the selection of software BEFORE starting your evaluation and then choose the best scientifically. Factor in initial capital spend, running costs, feature-match and roadmap. The best software might not always be OSS although I've found many OSS and quasi OSS to have a very compelling business cases.
In case you are interested (in various contracts), The following have been the on
The answer depends on you ... (Score:2)
It would work like this: you see a need that could be addressed very well using OSS package X. You also ensure that there is budget to buy software.
What you do next is to get a software consultancy you trust to take that piece of OSS software, modify it slightly (e.g. a new splash screen) and sell it to your
Re: (Score:2)
I know several people who work for companies that sell proprietary software, and most of them don't use that software themselves, even tho they could get it for free (without pirating it).
You really have to worry about the quality of software when even it's authors don't want to use it (and forcing them to use it doesn't count). They say programming is like an art, but there's no passion involved when you've no interest in what your working on, it becomes purely a mundane 9-5 job.