Here is an insightful recent article on outsourcing by George Monbiot (one of the world's leading overachievers):
The Flight to India
The jobs Britain stole from the Asian subcontinent 300 years ago are now returning. Is this a good thing or a bad one?
If you live in a rich nation in the English-speaking world, and most of your work involves a computer or a telephone, don't expect to have a job in five years' time. Almost every large company which relies upon remote transactions is starting to dump its workers and hire a cheaper labour force overseas. All those concerned about economic justice and the distribution of wealth at home should despair. All those concerned about global justice and the distribution of wealth around the world should rejoice. As we are, by and large, the same people, we have a problem.
Britain's industrialisation was secured by destroying the manufacturing capacity of India. In 1699, the British government banned the import of woollen cloth from Ireland, and in 1700 the import of cotton cloth (or calico) from India.1 Both products were forbidden because they were superior to our own. As the industrial revolution was built on the textiles industry, we could not have achieved our global economic dominance if we had let them in. Throughout the 18th and 19th centuries, India was forced to supply raw materials to Britain's manufacturers, but forbidden to produce competing finished products.2 We are rich because the Indians are poor.
Now the jobs we stole 300 years ago are returning to India. Last week the Guardian revealed that the National Rail Enquiries service is likely to move to Bangalore, in south-west India. Two days later, the HSBC bank announced that it is cutting 4000 customer service jobs in Britain, and shifting them to Asia. BT, British Airways, Lloyds TSB, Prudential, Standard Chartered, Norwich Union, BUPA, Reuters, Abbey National and Powergen have already begun to move their call centres to India. The British workers at the end of the line are approaching the end of the line.
There is a profound historical irony here. Indian workers can outcompete British workers today because Britain smashed their ability to compete in the past. Having destroyed India's own industries, the East India Company and the colonial authorities obliged its people to speak our language, adopt our working practices and surrender their labour to multinational corporations. Workers in call centres in Germany and Holland are less vulnerable than ours, as Germany and Holland were less successful colonists, with the result that fewer people in the poor world now speak their languages.
The impact on British workers will be devastating. Service jobs of the kind now being exported were supposed to make up for the loss of employment in the manufacturing industries which disappeared overseas in the 1980s and 1990s. The government handed out grants for cybersweatshops in places whose industrial workforce had been crushed by the closure of mines, shipyards and steelworks. But the companies running the call centres appear to have been testing their systems at government expense before exporting them somewhere cheaper.
It is not hard to see why almost all of them have chosen India. The wages of workers in the service and technology industries there are roughly one tenth of those of workers in the same sectors over here. Standards of education are high, and almost all educated Indians speak English. While British workers will take call centre jobs only when they have no choice, Indian workers see them as glamorous.3 One technical support company in Bangalore recently advertised 800 jobs. It received 87,000 applications.4 British call centres moving to India can choose the most charming, patient, biddable, intelligent workers the labour market has to offer.
There is nothing new about multinational corporations forcing workers in distant parts of the world to undercut each o
Sounds like the way to go. Binding should occur at application build time. This is the reason C applications are robust, while Perl, Python, and Java are only toy languages.
The alleged memo on why Sun doesn't use Java internally was largely about applications breaking when the Java environment was upgraded. Once again, problems resulting from using dynamic binding instead of static binding at application build time.
Yes, PacBell seems pretty Linux friendly. They provide static IP addresses, and their use policies permit the use of ADSL for servers. And while it isn't a guarantee of corporate policy, the fact that the PacBell Internet CEO is also author of the Linux ADSL How-To, this seems like an excellent indicator of their corporate attitudes.
"NSF does not possess or control the domain name database..."
An administrative appeal of this decision was made (NSF FOIA No. 96-090 Appeal). This appeal was rejected. The words "possess" and "control" are being used here in the context of the Freedom of Information Act to determine if the database is an "agency record", and not in respect of claims to ownership of intellectual property. These are the same terms used in the FLITE case (Baizer v. Department of the Air Force, 887 F. Supp. 225 (N.D. Cal. 1995). The FLITE decision has been criticized for its "broad assertion of an exemption from FOIA for 'library' materials, and its questionable use of legal precedent" ( Supreme Court Decisions in FLITE database, Information Policy Notes, Taxpayers Assets Project). The Flite decision draws upon the Supreme Court decision in Department of Justice v. Tax Analysts, 492 US 136 (1989).
So, the NSF has the right to obtain a copy of the database from Network Solutions, but because the NSF has not chosen to obtain the database, it is not possible to obtain the database from the NSF under the FOIA. And even if the NSF did have a copy of the database, it is not clear, in the light of the FLITE decision, whether the NSF would be required to make the database available under the FOIA.
Under the terms of the original contract between the NSF and Network Solutions (Awardee's Proposal Q.1):
"the information we collect and dispense will be freely available to all."
That said, the complete legal situation is faily complicated. My understanding of it is as follows. The registration database is probably capable of being copyrighted, however such a copyright would be a thin copyright that would not prevent others constructing a new database from facts contained in the original database. If this is the case, Network Solutions probably owns this copyright, but has failed in its contractual duty to inform the NSF of its claim of copyright in it's annual report (I discovered this by filing a FOIA request). To keep ownership of the database copyright upon termination of the contract, Network Solutions would have to pay 1-3% of the databases fair market value to the government. For the duration of the contract, Network Solutions is required to make the database freely available. The NSF can also obtain a copy of the database including on termination of the contract, but has not made such a request.
A year or so ago I followed the procedures Network Solutions requires for requesting access to the zone files. In my email request I stated that I agreed not use any of the information derivered from the zone files for sending spam, and that my sole reason for requesting access to the zone files was I was becoming increasingly concerned about the risk of monopoly control of DNS, and that I wanted access to these files to prevent this threat. This should have qualified as a legitimate reason for access to the zone files. However, Network Solutions never even dignified my request with a reply.
I find the present DNS situation highly disturbing. I have written a very comprehensive document explaining why this is such a big threat.
Network Solutions monopolistic ambitions are clear. The difficult question is how to stop them. Right now there appears little that can be done other than trusting that the government and ICANN don't screw up.
Slashdot Mirror
The Flight to India
The jobs Britain stole from the Asian subcontinent 300 years ago are now returning. Is this a good thing or a bad one?
If you live in a rich nation in the English-speaking world, and most of your work involves a computer or a telephone, don't expect to have a job in five years' time. Almost every large company which relies upon remote transactions is starting to dump its workers and hire a cheaper labour force overseas. All those concerned about economic justice and the distribution of wealth at home should despair. All those concerned about global justice and the distribution of wealth around the world should rejoice. As we are, by and large, the same people, we have a problem.
Britain's industrialisation was secured by destroying the manufacturing capacity of India. In 1699, the British government banned the import of woollen cloth from Ireland, and in 1700 the import of cotton cloth (or calico) from India.1 Both products were forbidden because they were superior to our own. As the industrial revolution was built on the textiles industry, we could not have achieved our global economic dominance if we had let them in. Throughout the 18th and 19th centuries, India was forced to supply raw materials to Britain's manufacturers, but forbidden to produce competing finished products.2 We are rich because the Indians are poor.
Now the jobs we stole 300 years ago are returning to India. Last week the Guardian revealed that the National Rail Enquiries service is likely to move to Bangalore, in south-west India. Two days later, the HSBC bank announced that it is cutting 4000 customer service jobs in Britain, and shifting them to Asia. BT, British Airways, Lloyds TSB, Prudential, Standard Chartered, Norwich Union, BUPA, Reuters, Abbey National and Powergen have already begun to move their call centres to India. The British workers at the end of the line are approaching the end of the line.
There is a profound historical irony here. Indian workers can outcompete British workers today because Britain smashed their ability to compete in the past. Having destroyed India's own industries, the East India Company and the colonial authorities obliged its people to speak our language, adopt our working practices and surrender their labour to multinational corporations. Workers in call centres in Germany and Holland are less vulnerable than ours, as Germany and Holland were less successful colonists, with the result that fewer people in the poor world now speak their languages.
The impact on British workers will be devastating. Service jobs of the kind now being exported were supposed to make up for the loss of employment in the manufacturing industries which disappeared overseas in the 1980s and 1990s. The government handed out grants for cybersweatshops in places whose industrial workforce had been crushed by the closure of mines, shipyards and steelworks. But the companies running the call centres appear to have been testing their systems at government expense before exporting them somewhere cheaper.
It is not hard to see why almost all of them have chosen India. The wages of workers in the service and technology industries there are roughly one tenth of those of workers in the same sectors over here. Standards of education are high, and almost all educated Indians speak English. While British workers will take call centre jobs only when they have no choice, Indian workers see them as glamorous.3 One technical support company in Bangalore recently advertised 800 jobs. It received 87,000 applications.4 British call centres moving to India can choose the most charming, patient, biddable, intelligent workers the labour market has to offer.
There is nothing new about multinational corporations forcing workers in distant parts of the world to undercut each o
The alleged memo on why Sun doesn't use Java internally was largely about applications breaking when the Java environment was upgraded. Once again, problems resulting from using dynamic binding instead of static binding at application build time.
See What Perl, Python, and Java need to learn from C for more details.
PEP maintains a National/International Directory of Computer Recycling Organizations.
Yes, PacBell seems pretty Linux friendly. They provide static IP addresses, and their use policies permit the use of ADSL for servers. And while it isn't a guarantee of corporate policy, the fact that the PacBell Internet CEO is also author of the Linux ADSL How-To, this seems like an excellent indicator of their corporate attitudes.
By my counting, we are now up to 1800 registered Linux domains in .com alone!
See http://www.base.com/gordoni/linux.html for the complete list (plus some other useful Linux market intelligence I have gathered).
In responding to a FOIA request submitted by Corsearch in 1996 requesting a copy of the domain name database (NSF FOIA No. 96-090 Request), the NSF claimed (NSF FOIA No. 96-090 Response):
An administrative appeal of this decision was made (NSF FOIA No. 96-090 Appeal). This appeal was rejected. The words "possess" and "control" are being used here in the context of the Freedom of Information Act to determine if the database is an "agency record", and not in respect of claims to ownership of intellectual property. These are the same terms used in the FLITE case (Baizer v. Department of the Air Force, 887 F. Supp. 225 (N.D. Cal. 1995). The FLITE decision has been criticized for its "broad assertion of an exemption from FOIA for 'library' materials, and its questionable use of legal precedent" ( Supreme Court Decisions in FLITE database, Information Policy Notes, Taxpayers Assets Project). The Flite decision draws upon the Supreme Court decision in Department of Justice v. Tax Analysts, 492 US 136 (1989).
So, the NSF has the right to obtain a copy of the database from Network Solutions, but because the NSF has not chosen to obtain the database, it is not possible to obtain the database from the NSF under the FOIA. And even if the NSF did have a copy of the database, it is not clear, in the light of the FLITE decision, whether the NSF would be required to make the database available under the FOIA.
I find the present DNS situation highly disturbing. I have written a very comprehensive document explaining why this is such a big threat.
Network Solutions monopolistic ambitions are clear. The difficult question is how to stop them. Right now there appears little that can be done other than trusting that the government and ICANN don't screw up.