Nikolai Bezroukov. Portraits of Open Source Pioneers

For readers with high sensitivity to grammar errors access to this page is not recommended :-)

Summing up

• Linus Torvalds as an accidental creator of a new BIOS

• Outsourcing and Linux

• Additional Reading: "Vanity Fair" of Linus Torvalds

• Where its all going

Please note this is a "slightly skeptical" chapter and you need to take it as such. As I already stated several times the main reason for writing this chapter was the desire to prevent "cult of personality"  exaggerations with Linus as a supermen that was in the center of events of a very important OSS project. I tried to demonstrate that essentially events were far larger then Linus and soon after he allowed independent commercial distributors  he became a pawn of powerful commercial forces he cannot control ("Let the Genie Out of the Bottle" so to speak).

I would like to stress it again that there was a kind of historical necessity for the kernel with free access to the source code to emerge, but the success of Linux was to certain extent political (it happened to be associated with the rise of outsourcing) and in no way based on its technical superiority. We should definitely respect and support other OSS projects, including FreeBSD, Open BSD and Hurd. Please remember that BSD project were more advanced for the period covered and achieved more then Linux using a tiny fraction of the resources.

Actually after version 1 which was a tiny and pretty capable kernel, Linus made no contributions to the state of the art of OS development. From this point of view it looked almost like a Microsoft project and at the end the level of bloat made it indistinguishable from commercial offerings. 

I think that as Linux commercialization had shown, the commercialization of open/free software under licenses that prevent creation of closed source derivatives (like GPL) produced a highly unstable and in many way internally contradicting  situation (what is so open about Red Hat Enterprise Linux other then PR hype ?) that negatively affect not only commercial software developers, but the software ecosystem as a whole.  Unlike software licenses under classic BSD license (with the attribution clause) GPL creates the situation of "law of jungles" where only the strongest survive (as IBM crushing of tiny Linux startups that tried to profit from selling Linux support had shown).

The 10-th anniversary of Linux kernel is the event on which this chapter ends. Technically is was a challenging year, not as successful as previous and the problems with kernel architecture were more evident than before. It would be interesting to look into the future, but our resources are limited and we will move to the most technically interesting area of open source, the area were open source communities managed to make a real contribution, the scripting languages.

As a final touches we will mention some aspect of the most explosive problem connected with Linux: "Outsourcing and Linux.". There is a deep irony in the Linux development.  When in 1991, Linus Torvalds created what became the Linux, it was an act of rebellion against the commercial software and IT giants who were raking in millions of dollars a year from their closely protected operating systems and applications. Who would have thought that, less then one decade later, the same giants he sought to undermine would give him (via Linux startups that they financed)  stock options and he embraces this opportunity to became rich with a passion Don Juan would have envied? And that IBM became the godfather of Linux and set  up a billion dollars fund to grow its (largely outsourcing-based) business in India and elsewhere.  Who would ever think that Linux would ever became symbol of both "brain drain" from Europe and symbol of programming jobs outsourcing to South-East Asia ? As David Lancashire aptly observed in the "The Fading Altruism of Open Source Development" (First Monday, volume 6, number 12 (December 2001))

...the very communities so quick to celebrate the open source movement have in the past been those quickest to "cash-in" on the phenomenon. Slashdot is part of the Open Source Developers Network (OSDN), and it is hardly coincidental that the site cheerleads for sister company Sourceforge when the stock price of parent company VA Linux swings with the productivity of unpaid developers. If cultural arguments hold merit, it seems equally plausible to argue that the true causal arrow points the other way, and that dynamism in the open source community is the product of wealth generation in the American software industry. Hackers may flock to open source largely because of the wealth potential of programming. Corporate interests might influence developer behavior, and culture may be better conceptualized as an intermediate (and not true casual) variable.

... ... ...

Historically, the United States has always been the country most commonly associated with the free software movement. From the late 1960s through the early 1980s, it was almost singlehandedly responsible for the vast majority of free software produced around the world. Early programs were given-away without-thought by academics and research scientists at leading American universities including MIT and UC Berkeley, and private research facilities such as Xerox PARC. The modularization of computer architectures around open standards in America further encouraged software-sharing in ways which never materialized abroad. Development in the rest of the world (and particularly in Europe and Japan) remained hidebound even into the early 1980s. At a time when Microsoft was gaining dominance over the American consumer market with early versions of MS-DOS, leading European firms such as Micro Focus continued to produce software for proprietary hardware architectures in "outdated" languages such as Cobol, and to target their goods to corporate - not consumer - markets [26]. Backing this record of technological leadership, the United States is also the undisputed center of an increasingly global culture prone to equate free software with political liberty. It is home to the world's most notable free software advocates, from Richard Stallman to the San Francisco Cypherpunks. As this record of cultural leadership is already well-documented in the work of Steve Weber and Stephen Levy, it suffices to ask a single question: how can we explain the apparent erosion of American support for free software development?

... ... ...

Primarily, it should be clear that if the opportunity cost of working on open source projects is lower for European developers than their American counterparts, the potential benefits Europeans gain from working on them are much greater as well. In a global economy lacking perfect labor mobility and characterized by wage-inequality across countries, we expect individuals to produce free software if doing so can help them shift to a higher wage-level. This "fixed-cost" analysis implies (as Lerner and Tirole suggest in their paper) that developers may embrace open source work as a way to tap-into lucrative corporate networks abroad. This may explain why open source development is more popular in Canada than the United States, although the data from Europe is inconclusive on this question. This also helps to explain why the majority of open source developers are relatively young [40]. Older, settled programmers have less need to establish a monetizable reputation than their younger, more mobile counterparts, given less time in which to amortize its immediate costs.

In other words, the appropriate analogy for open source development may not be to "cooking-pots" and "cauldrons" so much as to the Mayflower. Addressing the similar debate over the causes of migration to the New World, Hatton and Williamson propose that:

"Those who emigrated had the most to gain from the move, and were likely, therefore to be the most responsible to labor market conditions. By emigrating when young they were able to reap the gains over most of their working lives. By moving as single individuals they were able to minimize the costs of the move, including earnings forgone in passage and during job search" [41].

Conceptualizing open source work as a "fixed cost" young programmers face in order to establish a quantifiable reputation offers a convincing explanation for the peculiar demographics of open source development, and helps explain in particular why the phenomenon seems prevalent among young college-educated men. This nicely supports the observation made by Bezroukov that the romanticization of the open source movement in academic circles may have played a vital role in fuelling its early growth.

The analogy between open source development and historical migration is hardly perfect, but it is useful to consider even for its obvious differences. The most striking of these involves the type of labor assuming the fixed costs. Historically, the bulk of international migration has involved the extremely uneducated - those with few capital-invested skills, and little ability to earn a reasonable income in their local communities [42]. In contrast, contemporary open source programmers can accurately be thought of as "hyper-skilled" and in many cases "over-qualified" for national markets. A programmer extremely knowledgeable about thread-management and memory protection under Unix, for instance, may find him or herself employed by the private sector in a completely different manner - writing Web-based applications or producing software through a mass-market integrated development environment (IDE). Establishing a reputation as a skilled specialist may help programmers transcend the limitations of their local markets - a pressure much more likely to influence decision-making in niche European markets with a less diverse production base.

The truth is that commercialization of Linux (especially after Red Hat IPO and related Linux gold rush) drastically changed the movement. Linus himself became a hostage of investment banks and venture capital firms that first were trying to milk the Internet bubble and then switched on moving jobs oversees.  Some characters depicted in this chapter became very rich. Some got petty cash. No one went jail. Still this commercialization of Linux presented some interesting moral problems and challenges to Linus Torvalds and his participation in Linux IPO craze and the process of conversion of poor Finnish researcher into newly minted millionaire presents (with his personal participation in layoffs of his colleagues in Transmeta in between) an interesting illustration of why  "Ye cannot serve God and mammon".

In a sense Linus betrayed the key idea of open source: " keep it simple" or to be more correct sold it to the highest bidder.  In its acquired due to the commercialization complexity (and lack of stability) of  Linux kernel that makes it now is so non-distinguishable from the close source rivals (in a sense opening of Solaris by Sun was a really cruel joke on Torvalds ; that's why he is so adamantly opposed to it.  It's like reminding him that in Orwell's story pigs eventually became humans.  Nothing was left of the initial simplicity of the initial versions of the kernel that really was a breath of fresh air in early 90th. Drunk with power, flush with cash and convinced that he is on the right side of the history, this "mission over complexity" at the end became the same megalomania that is characteristic of the Larry Ellison: it's the same will to dominate that used to drive 19th-century followers of the nihilist Sergiy Nechaev, upon whom the author of The Possessed modeled his characters.

Despite minor legal troubles "Linux IPO pioneers" turned multimillionaires nicely escaped jail. In 2003 Red Hat founder Bob "Get rich without making any profits" Young moved to his new venture, Lulu Tech Circus. He said that the idea occurred to him a year ago after he argued with journalists about whether the open-source story was over or just beginning. "The implication of all of their questions was, "Now that the bubble around the Linux phenomenon has burst, are you going to have to get a real job?" Young said. Lulu Enterprises is also created a custom publishing arm that will produce customized textbooks.  Another superrich Red Hat founder who recently got a "real job" is former CTO Marc Ewing. He founded a glossy $12.50-per-issue climbing magazine called Alpinist, set to launch in November 2002. So much for the "liberation"...  The luster continued to fade on that buzzword, but we will stop here. The first ten years of the development were over and with them this chapter is finished too.

I would like to stress my final conclusions:

• The main technical achievement of Linux Torvalds is "BIOSification" of Unix: creation of standard extremely low-cost (almost free) OS platform that is "good enough" and like good old PC BIOS can serve for others to add value to the mix.
   
• Socially Linux started and promoted not only "the culture of sharing", but also outsourcing as the method of software systems development (that later has became a component of the general "outsourcing" movement, see below).
   
• Linus became a co-inventor of a commercial software cult (somewhat similar to Herbalife cult; the Helbalife cult image of clean living has been tarnished by evidence he smoked cigars and died after a four-day drinking binge) and as a more moderate figure largely displaced Richard Stallman in this role. The cult doctrine is characterized by its rejection of commercial software, devalues commercial programmers and their commercial programming work. Here is a relevant quote from an "Anonymous Coward" posting in a Slashdot discussion

Although I agree that open source software is better, and I enjoy using and working on it, are we all just enabling large corporations to make loads of dough off our work while we starve in relative obscurity? Are we acting in our own self interest when we basically work for free and allow anyone to use the fruits of our labor?

I wonder if this is the end of programming as a career that you can live off of. Garbage men don't go pick up garbage for fun in their spare time, the problem is programmers enjoy what they do and don't think of the economic consequences of doing so.

Someone please explain how programmers will make a wage they can live off of in the future. I've heard a lot of pie in the sky types of explanations (as I did about the Internet). Sure I believe that companies can make money off of open source, by selling supported and packaged "solutions" but that doesn't mean they need to pay the people who created the software they sell.

I think its time for us to start working in each other's interest. It seems that programmers are the new exploited class, and perhaps it is time to organize for better labor conditions and stop screwing ourselves over.

Real money losses of those who boldly and naively invested in Linux companies stock and folding of dozens of "Linux" companies in late 2000 and 2001 definitely contributed to the growth of realism in Linux community and quick depreciation of honk-ho evangelists (especially Raymondists: members of the "Linux cash community"). But the cult itself survived.

As Brett Glass mentioned at Linux Today forum the whole situation with "Linux is replacing Windows" promises reminds of the situations of numerous doomsday cults that have forecasted the end of the world -- or the New Testament "Second Coming" -- for a particular day.  The day comes and goes, and the world does not end. But what's amazing is what often happens next with the members of the cult.  If the cult is not a suicide cult, its members nearly always regroup and reset the deadline for a later date. (The Jehovah's Witnesses did this twice before they deciding to abandon the idea of a fixed "doomsday." They now preach, in much more vague terms, that a doomsday is coming, but do not attempt to specify the date; in fact, they even deleted all references to specific dates from their writings and their logo.)

Faith so completely triumphs over reality and common sense that the failure of the first prediction does not hurt the cultists' faith in the next one.  Many people were so blinded by the rhetoric that they fail to recognize that it outside implicit outsourcing that using volunteers for development of their product as Red Hat exemplify creating a viable business strategy for GPLed product is a non-trivial task and that any company that sell GPLed product is not very scalable as they are more selling services then the product.   As one Slashdot reader noted in the discussion of my paper in First Monday:

... critique the whole essence of which, IMHO, can be phrased like so:

OSS is not exactly such a novel thing--it has been known in scientific community for a long time. Current hype and success of it has to be largely attributed to Linux, but it is too naive to claim that OSS as a new software development paradigm means the total obliteration of any other way of developing software.

Before you flame, I know that I have left much of the article out. But I think that pages and pages that are left behind are just illustrate and support the above stated points.

Bezrukov does attack ESR as much as having his name in the article name. Why? Because ESR represents exactly this naive, on the border of blind-folded chauvinism, view of OSS. ESR, propaganda is one thing, reality is whole a lot different.

Yes, Linux popularity grows and it is the only OS rapidly gaining ground. This growth is not solely canibalistic (at the expense of other *nixes) as Microsoft would want it to look. But there are problems as well: there still are problems with fitting Linux in a business environment (office productivity suits like StarOffice, Applixware are not exctly a good match to Microsoft Office, while they may actually be as good if not better than Lotus SmartSuit and Corel PerfectOffice). I am not sure that making Linux easier and easier to install will matter as much to success: good publicity, applications, credibility will make a much better job than a no-pain-five-minutes-see-mom-no-hands Linux distros. After all, if business community is the target, their users will not be installing the system--IT people will. Home user is a whole another matter--and a topic for a separate discussion.
... ... ...

Huge social success of Linux became a definitely important historically important phenomenon, similar to success of DOS (with its first BIOS). As nothing succeed like success. In fact has many technological revolutions were a success of  the "good enough" technical solution not the best one. Classic example is  DOS success against very similar and somewhat technologically superior CP/M-DR/DOS.  This "tragedy of technological innovation" now is replayed in Unix/Linux space: a copycat implementation became more viable that the original. 

I think that Linus Torvalds succeed first a foremost as an author of a "new BIOS", a POSIX-compatible kernel implementation which became a de-facto standard, creating a kind of new Microsoft: driving down the cost of  software, and promoting the outsourcing.  Even Linux marketing is not unlike BIOS marketing: what we have on the marketplace is not Linux but carious distributions that are based on common Linux kernel but might have completely different "software personalities". 

Like Microsoft with DOS and later with its Office applications,  Linux opened a whole new market. In case of Microsoft it was personal computer market, in case of Linux it was software outsourcing market.  Of course, the displacement of expensive proprietary systems with commodity hardware and software and outsourcing is not a new story in the computer business and the history of companies like IBM (mainframes) and DEC (minicomputers) are good historical examples of  this trend. 

Still, it was Linus Torvalds who managed to be at the right time in the right place and to fire this new spiral of diminishing costs. This time due to distributed world-wide poor of developers (free or low paid) connected via Internet and working of low cost (due to Microsoft success) but very powerful PCs that constantly improves.  And I would like to stress that we all should be grateful to Linus "Unix BIOS" Torvalds  And not only to him but, what is more important, to all developers of the Linux kernel as well as to Stallman and all the developers who participated in GNU project: the precursor of Linux development.

Linus decade-long marathon for the stable Unix-like PC BIOS stands out like an achievement similar to the creation of  Phoenix BIOS.  Like creators of Phoenix BIOS made possible the PC boom, Linux distributions actually make outsourcing a business reality. 

One thing is clear, the success if Linux as a new PC BIOS is intrinsically connected with the success of Intel architecture and the success of Microsoft. I think that a large part of the Linux success was and still is connected to the fact that it is the most PC-friendly and Microsoft-friendly Unix implementation. As Microsoft creates and distributes without charge its "reference PC standard" Linux can piggyback of hugely discounted due to Microsoft success hardware.

From the user view of a Unix, the operating system has changed surprisingly little in the last 30 years. Users still "run programs" -- either by typing in a command line or through a graphical user interface. Programs read data from files, write and create files, and then terminate. Data files stored on disk are generally viewed as static repositories for information. Virtually all of the work done by a computer on behalf of an individual is done as the result of an explicit command. The keyboard, screen and mouse remain the dominant forms of human input/output.

While key architectural concepts of the Unix operating system  have remained largely static, the computers have changed dramatically. Desktop computer of 2001 is a supercomputer of 1972.  And what was pretty heavy footprint OS in 1985 became quite suitable for BIOS in 2000.  Linux kernel now  is a pretty standard kernel. "Almost" Posix-compatible (never certified) with IO subsystem, some services on top and some standard utilities. Everything else was moved to packages and despite being an example of a monolithic kernel Linux accelerated this modularization trend. In a way Linux kernel can be considered as a new incarnation of microkernel if you wish (that's why probably Linus so passionately hates Mach kernel ;-). This new generation of BIOS provides much more capabilities than old CP/M BIOS. Among them:

• Messaging, a set of routines to help applications (processes) or parts of applications (threads) talk to each other;
• Scheduler, to give the many applications (or parts of applications) some processing time to get work done;
• Memory management, so that applications have an area in memory in which to run, protected from other applications' bugs that might affect them.
• I/O management (but the filesystem is an installable component)

There are supporting elements on top of the kernel, such as drivers, libraries, etc. But almost everything else outside the Unix kernel is considered a driver, a utility or something extra, not part of the core BIOS.

That means that in a technical sense Linux was and is a very conservative operating system kernel, not a revolutionary one like many incorrectly assume.  To covert an OS into "new BIOS" you need to be conservative, otherwise it will be rejected. Standards should always be behind the current cutting edge technology. 

Technically Unix kernel was and still is one of the world's greatest operating system kernels. At the same time in the list of available Unix kernels (Solaris, FreeBSD, OpenBSD, AIX, HP-UX, UnixWare, True Unix, etc) Linux kernel is far from being the best (IMHO that place belongs to Solaris with AIX 5.3 as a close contender). Paradoxically, Linux revolution can be viewed more like a  conservative revolution or even as a counterrevolution.

Overall in this chapter I tried to show that the evolution of Linux kernel, especially after Linus moved to the USA has been guided more by demands by big business, rivalry with Microsoft and FreeBSD, one-upsmanship, "IPO craze" and the glee born of technical cleverness that is characteristic of the "hacker culture" than by purely technical considerations. Nevertheless due to infusion of huge amount of capital from IBM and likes this chaotic process has eventually produced more or less industrial strength "BIOS".  Still it should be noted that Linux kernel was never able to surpass  even FreeBSD kernel which was developed with just a tiny fraction of resources and no crazy IPO money. At this point, 10 years since the first Linux kernel release, FreeBSD retains better virtual-memory performance and a faster SCSI subsystem.  On the other traditional points of technical comparison, for example TCP/IP stack performance, the two are now close enough.

We also need also to understand that Linux is not the final step in the OS technical evolution, although it is can serve as a symbol of stagnation of the field. In twenty of fifty year from now there will be a need to something better. VM environments (like lightweight VM as implemented by Solaris 10 zones, or "full scale VMs" as in AIX 5.3 software partitions) look like a very promising new development trend and it probably will influence further evolution of the Linux kernel. Like before in this area Linux is a follower, never a trend breaker.

From the pure open source standpoint it's also pretty contradictory: more like one step forward, two steps back. Steps back that I would like to mention is betrayal of the KISS  principle and inability (and lack of desire) of Linus (because of Linux gold rush) to preserve the simplicity of the kernel. Which essentially closes the system by sheer weight of complexity. He really wanted to successes at any cost and that presuppose emulating Microsoft. That's how Linux kernel became a complex CMP-enabled kernel that essentially betrayed the ideal of simple open source kernel with adherence to KISS principle.  In a sense true advocates of open source should all migrate to OpenBSD or other simpler kernel ASAP ;-).

The view of Linux kernel as a new SuperBIOS also helps to explain why most Linux distributions are so ordinary and uninspiring in a technical sense of this word, despite all this "Linux revolution" blah-blah-blah.  Trying to be as conservative is the only realistic strategy for BIOS developers and that partially explains why Linux failed to jump into VM bandwagon and was dragged into it by events beyond its control.  Linux distributions also ignored most of the other important technological trends of late 80th (integration of scripting into OS (REXX in Amiga and OS/2),  virtual filesystems like fpfs (Plan 9, Hurd), distributed execution (Plan9).  For me personally, it's really sad that Linux as an operating system was never able to capitalize on the scripting languages revolution (feeling backward in this sense even to discontinued by IBM OS/2), but its role as a new BIOS explains the current situation. In a sense even Microsoft did better as they manage to adopt a single macro language in all major applications (VBScript) and later even manage to add other languages to the mix using common intermediate code (first JavaScript was added to the mix, then .NET extended this options to any .NET compatible language.). Later they added even Korn-shell style shell to the mix (PowerShell).

I would like to repeat my emphasize on the importance the usage of scripting languages in an OS, the area were Linux is weak. IMHO this is a major, not minor weakness, although it has nothing to do with the kernel.  While both Perl and Python are now installed in most standard distributions neither of them are used as a macro or scripting languages for applications. In this area Linux is still remain in prehistoric, dinosaur  level. Most utilities can and probably should be rewritten and integrated with the scripting language.

Developing Unix tradition scripting language regular expression engine should also be more tightly integrated into the operating system permitting its usage in all utilities and as a part of common macro language for applications.

This idea of shell serving simultaneously as a macro-language for applications was pioneered by Amiga and OS/2.  Later this idea was brilliantly transplanted into Unix world by TCL. In Unix world there was a small windows of opportunity when Sun was flirting with TCL, but Sun became distracted by Java and the idea died. Now it needs to be resurrected. It is really sad that Microsoft products that most Linux advocates (incorrectly) treat as inferior, in reality are vastly superior to open source applications because of their pretty uniform usage of  VBScript and availability of VBScript as a shell language (JavaScript can be used instead). 

At the same time the emerging status of Linux kernel as a new SuperBIOS can really repeat PC BIOS success on a new level;  if this is true then Linux will play a huge role both in the server market and the appliances market.  Thus,  the key role of Linux Torvalds in converting his POSIX-compatible kernel into de-facto "UNIX BIOS" for a large variety of systems  actually may qualify him as an important contributor to the computer science.  Only history will tell...

Outsourcing and Linux

There is no doubt that Linux distributions were the early examples of massively outsourced labor. Sold mainly by American companies Linux distributions contained code from all over the globe (with Europe as a dominant "work pool"). In a sense, enterprise move to outsource programming operations to developing nations was hugely simplified due to Linux. You do not need to move expensive equipment and software: all you need are PCs. Linux development exposes exactly the talent pool outsourcing firms are looking for: motivated, highly educated, technical talent that costs a fraction of what it commands in the USA. For me as a university professor the sad thing is that the career my students studied for at the University and spent a lot of money on probably won't sustain them for their working life. This probably means that their future success will come from moving up the software development tasks chain, focusing more on business, design and analyst skills and less on the pure programming skills that are becoming commoditized. But the number of such people needed is very low.

High speed Internet connected previously inaccessible pools of work force on different continents making possible to do Linux-based development almost everywhere. What's more, the new outsourcing is occurring at a breathtaking pace. Given the technology, there's very little that's sacred and thus can't be offshored.  Only a decade ago, programming and applications (especially databases) as well as systems  maintenance (Unix system administrators) were considered complex and secure ways for aspiring USA students to make a living. Now, it's considered "rote work," and many companies move it elsewhere to places like India, Ireland, Belarus, Ukraine etc.

Programmers jobs outsourcing became a sensitive political issue in connection with open source around year 2000, when there was a need to update a trivial bug in the huge amount of legacy code and it was too expensive to do it in the USA. It was partially resolved by increasing H1 quote and tapping retirees, but partially by moving the work offshore. According to the UC Berkeley report, “Outsourcing that began as a response to very tight labor markets in the US in 1999-2000 has continued, becoming a factor in the ‘jobless’ or ‘job-loss’ recovery of 2003. As in the last downturn in the early nineties, recession-based cost-cutting by firms may end up as the permanent loss of jobs that remain abroad even during the subsequent recovery.” Here is one interesting post borrowed from the paper Freedom Can Be Slavery:

Although I agree that open source software is better, and I enjoy using and working on it, are we all just enabling large corporations to make loads of dough off our work while we starve in relative obscurity? Are we acting in our own self interest when we basically work for free and allow anyone to use the fruits of our labor?

I wonder if this is the end of programming as a career that you can live off of. Garbage men don't go pick up garbage for fun in their spare time, the problem is programmers enjoy what they do and don't think of the economic consequences of doing so.

Someone please explain how programmers will make a wage they can live off of in the future. I've heard a lot of pie in the sky types of explanations (as I did about the Internet). Sure I believe that companies can make money off of open source, by selling supported and packaged "solutions" but that doesn't mean they need to pay the people who created the software they sell.

I think its time for us to start working in each other's interest. It seems that programmers are the new exploited class, and perhaps it is time to organize for better labor conditions and stop screwing ourselves over.

An "Anonymous Coward" posting in a Slashdot discussion

Corporations employ outsourcing largely as a means of cutting costs by replacing highly paid workers in one country with lower-paid workers who perform equivalent jobs in other countries. The availability of low-wage, educated, skilled and highly skilled programmers in countries such as India, China and Russia along with high speed Internet connections provides a key motivation for US corporations to outsource jobs. And the availability of Linux as a cheap software development platform also played its role, although minor...  For example since 2002, database company Oracle, the world’s second largest software company, has moved several high-pay research and development (R&D) projects to India and has more than doubled the number of employees in India to 4,200 workers. Oracle also moved development to Linux from Solaris.

According to Forrester's survey, momentum is huge in Linux and Linux-connected outsourcing  will grow:

But to say the truth, the Linux vendors has been doing outsourcing since the beginning: ability to profit from volunteer labor by private enterprises that was the essence of Linus "deviation" from Stallmanism (in Stallmanism volunteers were by-and-large expected to work for RMS's charity, although Cygnus demonstrated the possibility of doing this independently). If you think about it, it is clear, that by their business model Red Hat and other Linux companies were essentially outsourcers from the very beginning. Their main "business" was coordinating volunteers (zero pay workers) and, if necessary, hiring key talent around the globe (either locally or by moving it to the USA) while selling the resulting product mainly at the domestic market. As we saw above, Red Hat is extremely restrictive licensing  make perfect business sense as the defense of its USA franchise. Without this subscription model the only way Red Hat can survive is by becoming mutual fund and living of proceeds from investing IPO money in other companies. In a sense, after Red Hat IPO, volunteer period for many developers become like post-university internship: short period before the best and brightest were hired by the corporations.

In the US, the rush to outsource programming jobs internationally is increasingly being seen as the part of globalization. One corporate behemoth after another: first IBM, then Oracle, then HP, then Google move a  significant portions of their programmers offshore. Of course the problem is not limited to programming, programming was simply highly visible "guinea pig" for outsourcing. According to a Gallup Poll, in 2004 58% of Americans say that outsourcing will be "very important" when they decide their votes for president. And 61% say that they are concerned that they, a friend or a relative might lose  a job because the employer is moving work to a foreign country.

More then a million of programming jobs are likely to be lost to outsourcing by 2010, and that the rest are vulnerable to foreign competition. That means that USA-based software development suddenly converted from growing to shrinking industry. And it have turned India into the new Japan for many American programmers: an ominous economic threat to their economic prosperity.  For US programmers the nagging question "How can you compete with a colleague who makes a 10th of my salary?" remains open.  Sharp drop of salaries is already on the way. Gone are times when student fresh out of college, could get $40K-50K a year.

It's somewhat ironic that Brian Behlendorf  of Apache fame is a founder of CollabNet, the outsourcer tools producer. As Salon noted:

Behlendorf, as befits his open-source roots, is an idealist. Taking a global perspective, he believes that spreading the wealth internationally is good for the world in the long run. He and his fellow executives want CollabNet to be a truly global company, with no distinction made between employees in one country or another. But even more to the point, CollabNet's main product, SourceCast, is a set of software tools that facilitate development among teams of programmers working in different locations.

In other words, CollabNet's developers, both in the U.S. and India, are hard at work writing code that makes it easier for workers on opposite sides of the globe to work together effectively. CollabNet even "eats its own dogfood," as the saying goes, using its main product as the development environment for writing the SourceCast code.

Similarly VA software  (with Eric Raymond on board) declares that SourceForge.net is perfect for outsourcing operations and even can minimize outsourcing risks:

Sending applications and product development projects to offshore outsourcers creates numerous risks. These risks can jeopardize and delay expected benefits while threatening project success...or worse. While more due diligence to front-end planning processes helps alleviate risk, it is when the work is actually being performed and managed that real benefits are either won or lost. To minimize risk and maximize the gains of going offshore, you must strengthen governance of globally-sourced development via best practices and solutions that help you manage and execute more efficiently and effectively.

The following table summarizes the Top Ten Risks of Offshore Outsourcing, according to META Group, a leading industry research firm. It also highlights how VA Software's Global Development Platform™, SourceForge, mitigates risk while providing more visibility and control, improved savings, and better results from your offshore efforts.

Top 10 Risks of Offshore Outsourcing SourceForge Solution
1. Cost Reduction Expectations

»	Companies mistakenly assume savings will quickly approximate the simple difference in labor costs
»	Hidden costs stemming from knowledge transfer, lost productivity, and additional management expenses decrease offshore savings. Companies must overcome hidden costs by modifying operations to align with a globally-distributed model
»	Hidden costs from lost productivity are largely attributable to breakdowns in communication, collaboration, and coordination between the U.S. company's internal staff and offshore teams

»	SourceForge reduces hidden costs by providing a secure, web-based workspace that improves management visibility and control as well as distributed team productivity
»	SourceForge helps you keep projects on track and on budget with real-time dashboards and other management, monitoring, and reporting tools
»	SourceForge improves operational efficiency by enabling you to more quickly align internal operations with offshore teams and to coordinate and streamline workflow and collaboration

2. IP Security and Protection

»	The risk of security breaks or IP theft is inherently raised when working in international business
»	Security requirements must be documented and the methods and integration with vendors defined. Ideally, security methods should be auditable

»	SourceForge protects your IP by providing a secure, centralized repository for your IP behind your corporate firewall in your own data center, meeting strict internal corporate standards
»	SourceForge allows you to control access to site, projects, tools, and IP (documents, code, communications, etc) on a per-user basis
»	SourceForge increases visibility and control over company IP by allowing managers to know who is accessing and changing what IP and when, and to enable/disable access at their discretion
»	SourceForge facilitates audits by automatically capturing and logging all changes to artifacts

3. Process Discipline (CMM)

»	Offshore vendors are typically at SW-CMM levels 4 or 5 and require a standardized and repeatable model
»	Potential offshore cost savings will be undermined by process maturity gaps between U.S. organizations and offshore vendors. These gaps slow projects and require additional on-site resources, reducing cost savings

»	SourceForge provides a common, integrated workspace that fosters more mature processes, helping internal organizations close the process maturity gap with offshore vendors and reduce hidden costs
»	SourceForge comes with a flexible, best practices guide for implementing standardized, definable, and repeatable processes, and including process improvement guidelines to help your own organization attain SW-CMM levels 2 and 3

4. Loss of Business Knowledge

»	Many IT and R&D organizations have proprietary business and technical knowledge within their developers
»	Companies must carefully assess if moving critical business knowledge outside their company will compromise company practices or competitive advantage
»	High attrition rates among leading offshore service providers increase the risk that this knowledge may disappear suddenly, threatening projects and potentially weakening competitive advantage

»	SourceForge helps preserve business and technical knowledge by providing a secure, centralized, searchable repository for your IP, including documented technical, project, and industry knowledge, code, and project communications
»	SourceForge improves knowledge management by preserving the contextual history of projects and changes, as well as the source or original author for any stored IP, helping connect people with the expertise of others, whether they are still in the enterprise or not

5. Vendor Failure to Deliver

»	Even with superb quality methodologies and good intentions, outsourced project failures sometimes occur
»	Many organizations fail to have a contingency plan. Organizations should consider the implications of project failure, perform risk analysis, potentially shift outsourcing strategy (e.g. from single to multiple vendors), and have a documented contingency plan
»	Projects may need to be rapidly transitioned between vendors and teams to minimize impact of problems

»	SourceForge helps ensure project success by giving managers real-time visibility and control of projects-regardless of location-plus automated escalation and notification features to give them the earliest possible warning of potential issues. SourceForge makes it easier to spot and manage issues before they become problems, decreasing the chances of project failure
»	SourceForge helps contingency plans succeed by making it much easier to transition work to from one vendor or team to another with minimal time-to-productivity

6. Scope Creep / Project Scope Changes

»	The scope of most projects changes by 10-15% during the development cycle
»	Outsourcing contracts typically require the client to pay the difference in cost if actual work varies from baseline assumptions and estimates

»	While some changes may be necessary, SourceForge helps control scope creep and unexpected costs by monitoring and automatically notifying accountable team members of changes (or attempted changes) to project documents or unauthorized change requests
»	Managers can keep projects on track by monitoring changes and workflow status of key artifacts, documents, tasks, and milestones

7. Gov't Oversight / Regulation

»	Financial services, healthcare, utilities and other industries face stringent regulatory compliance requirements (e.g. Sarbanes-Oxley, HIPAA, etc.) and must ensure that offshore service providers comply with regulations and have sufficient "transparency" and traceability to comply with audits

»	SourceForge helps you meet regulatory requirements by providing full traceability for regulatory compliance audits, such as those required by Sarbanes-Oxley or SAS70
»	SourceForge automatically tracks and logs work performed by both in-house staff and offshore service providers, creating an auditable trail of project activities, document versions, change requests and histories, approvals, and more
»	Because SourceForge is hosted at your corporate location, you retain full control over site and data access, document retention actions, back-up and data recovery policies, and degrees of "transparency"

8. Cultural Differences

»	Even in offshore countries where English is widely spoken (e.g. India) strong accents, pronunciation differences, and cultural norms of interpretation compromise the effectiveness of verbal communication. Time zone differences further exacerbate communication difficulties
»	Issues around verbal communication can persist even when offshore vendors have cultural training programs. These issues reduce productivity and can lead to misunderstandings that contribute to poor service delivery, rework, and extra costs

»

SourceForge helps multi-cultural teams overcome communication barriers by encouraging communication and collaboration in written form. Communications can be reread, studied, associated with related information for added clarity, and automatically stored for future reference

»

SourceForge helps geographically-distributed teams be more productive via robust support of asynchronous communication methods such as email and forums. Team members can collaborate via email, participate in or catch up on news and discussion forums, get the latest information pushed to them through mailing lists, and more. These features help overcome cultural and language barriers, just as it has done in the open-source community, by giving people time to understand issues and frame responses, ask clarifying questions, and collaborate on design challenges. SourceForge focuses teams on results through better communication and clarity

9. Turnover of Key Personnel

»	Rapid growth in offshore outsourcing has created a dynamic labor market in India, with high turnover of key personnel
»	Common turnover rates of 15-20% create liability and risk to your projects
»	Turnover also increases time spent on ongoing knowledge transfer for incoming project team members

»

SourceForge mitigates the impact of turnover by capturing the work of project team members-both internal and offshore-including historical context (what's been done or changed, by whom, when, for what reason), complete with dependencies. New team members can view logs of all work done by the previous member (tasks, issues, changes, notes, comments, and more), minimizing the time-to-productivity

10. Knowledge Transfer

»	Companies rarely account for cost and time required for initial knowledge transfer to outsource service providers
»	Transfer of technical and business knowledge to outsourcing firms reduces the productivity of most IT organizations by 20% during the first year of an outsourcing agreement

»

SourceForge facilitates knowledge transfer by providing a secure, centralized repository for all documented technical and business knowledge. This helps during the initial knowledge transfer phase as well as with ongoing knowledge transfer as projects proceed. This can reduce the duration and costs of on-site service provider resources while helping to maintain productivity in IT organizations during the knowledge transfer process

But for American programmers and IT staff this is not an abstract humanitarian theme that newly-minted millionaires like Brian Benkerdorf are free to pursue. Here are some quotes from the letters to Fortune after pro-outsourcing paper was published: