The number one problem with wikis and all other systems that try to 'store' employee's knowledge is that it requires people to make their knowledge explicit.
In your daily life and in your work, many things (if not almost everything) you do is based on implicit knowledge. You implicitly know how stuff is done, but to describe the steps you take and the thought processes you have, takes a lot of time and energy of your employees/colleagues. And then of course there's also the issue of keeping the knowledge up-to-date. Adding it is one thing, but keeping it fresh and ensuring people update the explicit knowledge in the wiki, also takes time and energy. Especially in IT, because the way things work changes relatively often.
And last but not least, people are often not willing to make their knowledge explicit, because their implicit knowledge makes them valuable as an employee. Overall you could say that the intrinsic motivation for people to make their knowledge explicit is very low.
Many scientific papers have been written on this subject. I suggest you try to find some answers there, although they may not be easy to find.
The US is not (that I've heard anyway) using economic pressure to influence Ukrainian politics.
I think you are wrong here. The US uses economic pressure on almost every country in the world.
The guy I'd need to hire would have to know a lot of languages
There's your problem right there. If you are doing in-house development, you should stick to one language. Especially if you have a small company, but it kind of holds up for larger companies as well.
e.g. if you have four programmers, two proficient in C, two in Java and a Java programmer quits, then suddenly your single Java programmer needs to do all the Java work. If you have 4 programmers proficient in Java, then if one quits, you still have 3 Java programmers left.
In the end multiple languages just means less flexibility in capacity.
You see, before computers, companies used to have room full of people manually calculating and processing stuff. It wasn't until the computer came that they could fire all those people and save a ton of money on their collective salaries. Now, my question is: what happened to that money they saved?
This is largely incorrect, I think. Most companies that invested in computer systems didn't fire their employees. Instead, because of the computer systems, most of these companies suddenly had more capacity to deliver more of the product/service that they deliver. So companies that invested enough in computer systems gain more market share, while companies that did not invest enough in computer systems lost market share, went bankrupt and/or were taken over by a competitor.
If a company has a product that is only suitable for IE6, they didn't invest enough in maintenance in the last 10 years!
Working in the software industry, I experience daily that people think that if you buy a software product / application / website that you buy it once and then it "just works" until you want new functionality and it magically keeps working with newer browsers, etc. This thought is wrong. You need to invest money in maintenance to keep your software product up-to-date.
So when IE7 came out, the company should have invested in ensuring their product also worked with IE7. And the same for IE8, Firefox, IE9, Safari, Chrome and IE10. If you do not invest time and money in maintenance, in the long term you have a system that is not up-to-date, is a pain in the ass to deal with and needs to be replaced to ensure your company will not be stuck by legacy systems.
Really? IE supports VBScript, but I can't remember Firefox, Webkit or Opera having support for it.
If you calculate money in cents, you only need integers. This is valid for many programming languages by the way and can be applied in almost all situations.
Distributed => Disassembly
Somewhat related, but not quite the solution is the Distributed Bill of Materials (DBOM): http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=924533 (and related articles); The DBOM tells the devolvers how to devolve a product and what the resulting parts are made of.
Risk = Probability x expected loss
If expected loss is not (nearly) 0, you need to manage probability as well. So while the hazard (expected loss) may be less than estimated before, it says nothing about the probability. And in my opinion it is the probability in nuclear plants that is the issue.
This is of course besides the question what a "lower hazard estimate" means. A lower hazard estimate can still be pretty high.
In every non-trivial program there is at least one bug.