- by Paul Murphy, -
One of the bigger risks facing Linux is that explosive growth can destroy it as people who don't understand what its for, install it as a Windows substitute rather than replacement, discover that it isn't Windows, and then denounce it.
The underlying issue here is that people become captive to what, and whom, they know. That happens in almost all areas of management, not just technology, and is perhaps easiest to illustrate in the realm of executive head hunting.
Senior executives are usually recruited by committees which first hire consultants to winnow the field down to a list of people judged competent and then make a final selection based mainly on the candidate's social credibility in the role. Thus a committee charged with recruiting a new vice president for marketing usually starts with a list of people with the core skills and then gravitates toward the one whose personal credibility with customers and colleagues is expected to do the organization the most good.
Unfortunately this strategy, which fundamentally replaces "not invented here" as a basis for rejecting new ideas with "not known here" as a basis for rejecting people, can back fire badly because the people making the decision and the potential recruit can form a closed social loop, trapping the organization into taking on someone who cannot break free of his former network and thus acts like a trojan: attacking the organization from the inside.
For example, the Canadian sales organization of a well known American company recently hired an ex-IBMer as president because he's widely known and respected in the industry. They expected his name to open doors for them; and it did --except that the doors he opened led to others of the faithful because, of course, those were the people he felt comfortable with. Since he also knew what they bought from IBM, he focussed his new organization on meeting those same needs; turning an effective selling machine for breakthrough hardware and software into one focussed on under-selling IBM on services. In that process he lost key people, hired and promoted his own clones, and generally positioned his company to quite dramatically underperform on new sales over the next few years, all the while numbing head office to his activities by turning in decent monthly numbers on the strength of increased service volume.
The underlying issue here is that he brought his new employer to his existing social network instead of bringing his network to his new employer. This particular individual is on a first name basis with most of the senior data center managers in the country and had racked up an impressive record as an intermediary in their purchases of IBM products and services. Unfortunately, his new company doesn't sell the hardware or software those customers buy and the people who do, don't know him. Worse, his relative success in selling services among his former colleagues quickly affected opportunities in the company with survivors polishing up out dated skills and others interviewing elsewhere. Meanwhile, of course, the smaller, more aggresive, customers the company generally caters to were left to wonder what happened to the enthusiastic sales and technical support they used to get and are consequently looking elsewhere.
For most of the company's employees and customers the results are tragic: they see the company rotting from the head down but are unable to do anything about it other than leave or wait until head office notices. For the uninvolved, however, there's a lesson to be learnt here and a prescription to be offered. The lesson isn't about some Machiavellian scheme to destroy competitors by encouraging them to hire your people as trojans, it's about the degree to which Linux is exposed to the same fate as Windows experts try to install and use it without changing their ideas about how computing services should be used or provided.
The prescription follows directly from the analogous behavior among executives. It's true that hiring committees don't usually care about social networks when recruiting technical staff, but you should. Recognize that what drove the ex-IBMer in the example cited above to focus all his efforts on the same people he sold to before was really that he knew no one else, and you can see that an MCSE who only knows other MCSEs may have much the same problem --and its a problem you can help with.
Specifically how you do that, depends on who you are. If you're an MCSE who would like to know more: read some books, find good some people to talk to, expand your horizons beyond running servers on servers. If, in contrast, you understand core Unix philosophies like user empowerment or how small, effective, programs combine with large scale systems to produce extraordinary results, then you should spread the word: become a Unix mentor; find some benighted MCSEs and quietly coach them --but make sure they don't see you doing it because that would destroy the effect.