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.
Comment removed (Score:3, Insightful)
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.
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.
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 support definitely is lacking in the open source world.
The last thing a pointy-haired boss wants to hear is that you're waiting for someone to reply to your post on the forums, or that you're getting on IRC to find out if someone ran across the same problem and what the solution was.
For example, ZenOSS is a great monitoring tool, but the documentation is complete garbage, filled with errors, omissions, and even broken sentences. Mind you, this also includes their Enterprise version, and their support is also lousy. You'll be lucky if you get a response within 24 hours from when you submit a trouble ticket as a Enterprise customer.
Redhat, on the other hand, is much more responsive. You'll get a reply or at least an acknowledgment that they got your email within 20 minutes, which at least is enough to give management the 'warm fuzzies'. They're really just another Linux vendor, but they have a support line, and they have the fancy brochures and certifications, and that adds legitimacy. It tells the business world that they mean business, and are not just some long-haired smelly CS grads with a pet project.
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: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:Open Source means there's LESS chance of malwar (Score:1, Insightful)
And your assured solution could be, say, have a glaring security issue.
Fortunately, software companies aren't asses that sue people for disclosing things, want all bug reports public so companies can take precautions against problems, and definitely will fix bugs in a timely manner,
If the company goes under or is largely unresponsive, we'll simply use a different software. Any data that we may have used, we'll just convert away from them. This will be a walk in the park too, since we'll definitely have an option to export to many other programs (to avoid vendor lockin, of course), or we'll simply read the proprietary data file format ourselves using a script to convert the data!
There are so many examples of such honourable companies, like... uhm...
err... :D
Just tell his boss the cost (Score:5, Insightful)
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.
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) are significantly higher.
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.
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.
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]
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: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:Other concerns: OSS creep into commercial code (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:great advice! (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: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.
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: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:It's not about malware, support, or quality... (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 infringing code will be replaced by non-infringing code. You could even pay someone to do that for you if it was a priority. Unless the whole project is blatantly stolen code, which you probably would have noticed already when comparing it to similar offerings.
Comment removed (Score:5, Insightful)
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:Follow the Money (Score:4, Insightful)
Re:Other concerns: OSS creep into commercial code (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 final product.
A better formulation would be that no OSS which has licence implications on the final product, or attribution required, is present in the product".
Re:Other concerns: OSS creep into commercial code (Score:1, Insightful)
"Do you think the "legal ramifications" of that action would be more or less serious?"
It would be less serious.
Microsoft would either settle for a sum that was high, but not ridiculously high (one gazillion dollars), or sue, and if they sued, the judge would very likely deny any request to publish the entire source code, and simply award a sum based on how core/complex the code was. And the more core/complex code is, the more it's reviewed, so there's a nice proportional relationship between potential damage and damage prevention.
The OSS and Stallman would on the other hand want to see blood, because getting rid of proprietary software is a goal of many within the movement. Money wouldn't satisfy. They would press for maximum disruption to your company, maximum loss caused, maximum "making an example", and dance on your company's bankruptcy statement. Please, convince me otherwise.
I would far rather have an ill-defined liability towards someone who was less interested in me and more interested in money, than someone who hates me and delights in making me feel pain.
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.
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)
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, 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:1, 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)."
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.
Open source projects have no risk. They can put out buggy or insecure code (look at projects like oscommerce or wordpress as an example) and if there is a problem, the most you get is a "my bad", and the hope of a fix (or you can spend days trying to weed through the source and fix it yourself). Also, since most open source projects are hobbies, sometimes you don't even get glaring bug fixes finished for months (filezilla has a nice feature that deletes your files when transferring..I lost an entire weeks worth of work one time. The main programmer there also has denied any issues).
This also doesn't account for all the GPL liabilities. As a company, it's just better to stay away from open source 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: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: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:I don't get this (Score:3, Insightful)
In any event, don't dismiss the capabilities of soccer moms and business men with pistols. When the shit hits the fan, when the lives of your friends and families are on the line, people can do some amazing things. But, when you get right down to it, the reason the Right to Bear Arms is there is to (hopefully) prevent the need for such actions on the part of the population. So far it's worked pretty well.
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:1, Insightful)
I have heard this argument before: losing your job is enough deterrent.
If only that actually had the desired effect, then I might agree that paranoia is the best action. Unfortunately, I thought it was a well known statistic that the most dangerous security risks to a company are its employees, bar none.
If the incentive is high enough, someone will have a go. In fact, they might go out of their way to get a job there to fulfill their goal.
With most self-proclaimed geeks, money and/or getting caught is not always enough of a deterrent; sometimes the incentive is just to see if they can get away with it...
But anyway, the main problem is that if a employee has attempted to do such a thing, and installed some "bad" code, then the likelihood is fairly high that they've already done it several times before, and only got caught because they became over-confident... And how likely is it that the software vendor is going to tell their customers they've had an internal security breach?
Zero to none?
Re:Don't bother (Score:1, Insightful)
Well of course that's not an easy task, it is in fact a problem that's undecidable, from a computability theory point of view.
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.
What the OP really meant to say (Score:2, Insightful)
Re:Three words: Throat to Choke. (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 performance fix in can pay off this month.
Comment removed (Score:3, Insightful)