Bringing OSS Into a Closed Source Organization?

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

Comments

Play the game or go to a higher authority

[Noksagt]

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:

A single person who decides what software to approve and disapprove within the organization.

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

[tr_x_data]

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:Don't bother

[Curtman]

What processes are in place to protect users from malicious code?

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

[Jesus_666]

Not everyone gets write access to the repository. If you want your changes to go in you have to write a patch and an explanation of what that patch does and submit that to the appropriate maintainer. The maintainer then reviews the patch and is free to accept pr reject it. Obfuscated code will not make the cut as maintainers want the codebase to be readable so it can be better maintained (unless cryptic code is required for speed purposes, in which case you better explain it in detail). You might try to sneak in a subtle bug and that might work or not, depending on how many people review the patch, how thorough they are and how much testing the new release gets before it hits the web.

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.