Digital Walkabout

The Policy of Innovation

As a Technology Strategist, my charter is to drive bold technologies to transform my organisation, deliver world-class technical innovation, know the external research community, know my organisation, and provide technical leadership. I thus spend a significant amount of my time looking for how to achieve that transformation through "innovation". With a smaller portion of my time, I present at a number of conferences on these strategies, their associated technologies, and how they can be applied to solve real-world problems.

One recent presentation was given at CloudCamp Hamburg. One of the reasons I chose to do so was to reach a new audience. The sessions at the event were quite good, focussing on developments in the business models, usage models and technologies of the Cloud. Yet, I read posts such as this one, and wonder that, based on my experience in Europe and the Americas, if there a) is a problem with the state of innovation in Europe, or rather, b) the taxonomy of innovation exemplified in the post is a problem in and of itself.

Anyone who has spent any time with me will know that I am not one for fussing about with taxonomies. I feel that, essentially, these are a tertiary consideration, and to be addressed after what I consider to be the 'real work of taking a concept from idea to reality. My personal opinion is that taxonomies are pedantry, used to constrain, limit and control the process of innovation, and are too often used as a device to be heard, rather than to solve any problems of significance. Yet, when I hear or read the use of the word 'innovation' or phrase 'big picture' to focus only on business models, and ignore usage and technology, think there's something amiss. If we limit 'innovation' to *exclude* usage and technology advances, we are truly advancing style over substance.

Most of the widely recognized innovations in history which have advanced the standard of living for many in modern civilisation arose from usage or technology innovation addressing very specific, detailed problems. The innovation may have encompassed a grand vision, but that vision arose from connecting the dots which started with solving a specific problem. To make the blanket claim that innovation is hindered by being too "busy nitpicking on time consuming details" makes as much sense as reality television. An artist worth the enduring attention of the public will need to have mastered the fundamentals of their craft; a reality 'star' will exit the spotlight in relatively short order (although not fast enough for some of us) since their recognition was purely situational, and they had not addressed any of the 'time consuming details' necessary to sustain any career in entertainment.

Based on my assumptions, the iPhone is 10% innovation and 90% evolution. The device has truly been innovative in its enablement of Augmented Reality - Apple improved a number of existing technologies such as touch screen, application integration and metadata management, to provide a usage model which was a step beyond the expectations of a mobile device. The innovation lay in how the individual technologies were deployed to provide a better (and now widely adopted/mimicked) usage model; the whole is greater than the sum of the parts. Yet even the improvements in the parts, not to say new usage model, required a foundation rooted in time consuming details. Ask any Apple engineer working on any of the technologies that were developed or revised, and they can attest to how much effort - deep in the bowels of hardware, software and/or user experience engineering - was required of each and every one of them to deliver them.

The innovation of Rich Internet Applications (RIA), and subsequently the Rich Services Cloud - something with which I have been intimately involved - arose from similar efforts. The underlying engines supporting this, such as Flash, had already been widely deployed for nearly a decade, but it was the understanding of the limitations of Web 1.0, at the level of nitpicking on time consuming details, married with the vision for a rich yet agile development and user experience, that drove the development of platforms such as Flex and Apollo/AIR, Silverlight, and now HTML5/Chrome. Each of these implementations of RIA innovation recognised that the real world, devil-in-the-detail problems of Web 1.0's fully remoted architecture were non-performant, did not scale, and limited the web experience to very simple, highly constrained models

Innovation is not in the vision itself, or in the nano-level details, but in how recognising the vision that can be realised from creating or enhancing bits at the level of time consuming detail, and successfully mapping them. Business across Europe may not have adopted North American-style Public Cloud, with its Lowest Common Denominator (LCD) user experience and generally coarse Service Level Agreements (SLAs), but that does not reflect their difficulty with innovation. Rather, it reflects that organisations across Europe have chosen to focus their energies solving some very important problems, after already bravely diving into related areas such as the Open Business Initiative wholly, and learning important lessons from such moves. Europe has proven itself truly innovative in business models, usage models, and technology, as exemplified in it's world-leading or -challenging development in areas of mobile, automation, and web, to name a few. European organisations have not been shy to embark on bold endeavours to transform their business and usage models by developing, adapting or adopting innovative technologies.

Likewise, I've encountered plenty of innovation in North America arising from the unabashed confrontation of time-consuming-detail problems presented by the challenges of Cloud Computing. There have been plenty of clever applications of Cloud, but no matter how cool they may be, the real innovation, in my definition, is in the usage models and technologies that have enabled them together with a number of not-so-cool apps. Throwing something on the Cloud with a slick interface and a minimal SLA isn't innovation. Developing the foundations for HTML5 and Native Client Libraries, developing MapReduce and Hadoop, developing image recognition algorithms that scale by shifting cycles across compute resources based on capabilities and utilisation  - these mapped to new business and usage models is innovation.

Entering the tablet fray

CNet columnist Brooke Crothers, wrote this week that “Intel is wasting precious time waiting for its ‘partners’ to build the equivalent of an iPad and iPhone," and that Intel should build its own tablet.

Crothers seems impatient for someone, anyone, to bring some competition to  Apple’s tablet. He said Intel had the wherewithal to produce compelling products and should “short circuit” the process of watching OEM partners “prattle about Intel-based tablets, then do nothing.”

In most computing markets, he said, Intel of course can’t produce its own branded products because we would compete with products from our OEM customers, not to mention attract charges of dominating those market segments. But, he said, tablets and smartphones are different.

“In these markets, Intel does not carry the clout (potential for big revenue streams) as it does in PCs...In tablets and smartphones, Intel is just another chipmaker—and not seen as competitive to boot,” he wrote.

He noted that there’s a lot of design expertise at Intel, and that some of the first eye-catching ultra-thin laptop designs came from Intel. And the hiring of former Palm executive Mike Bell increases that expertise even more.

He agrees with Intel execs who say tablets aren’t eating into PC sales. But he asked, “Will Intel keep saying this while slowly consigning itself to insignificance in some of the most interesting newfangled device markets?”

Times are rough all over

http://www.nytimes.com/2008/10/27/technology/companies/27dotbomb.html?_r=1

Reading this article gave me some pause. It is interesting at a certain level to see examples of how well-connected startups are surviving the worst recession in 70 years; but, really, companies large and small (and with a smaller media network) are taking creative measures to do the same. Looking at how "Web 2.0" companies essentially apply the same practices their DotCom predecessors attempted 7-8 years ago seems indulgent. 

In rough times, simply cutting in the manner of a 19th century "surgeon" has been shown to place businesses in a difficult situation when recovery arrives, and encourage a form of "brain drain" which helps no one in the market. The DotCom excesses of the late 90s were in large part a reaction to the depressed market for technical skills, brought on by blinkered "slash and burn" tactics of the 80s and 90s recessions. Indiscrimination only sent talent looking elsewhere for a living, and during the following boom, the level of desperation to staff led to the truly anomalous and costly hiring practices. 

The one notable aspect of this present recession is the attention of many large and small companies to think on their collective feet and not "slash and burn", instead looking for ways to survive in a difficult environment without mass layoffs. I find this far more remarkable than mass staff cuts and relying on technology to keep the launch afloat. The recent mainstreaming of technological advances help, but without prudent resource management, they cannot help very much. The stories of organisations that have managed to remain in economic health without "slash and burn" altogether are far more interesting to me. 

Cheer up love, it might never happen

Facebook and privacy once again made headlines this week, with the social computing provider’s revamped privacy settings. Yet, per experts in digital civil liberties, these latest changes will only push more user data onto the Internet and, in some cases, make privacy protection harder for Facebook users. For privacy, this represents two steps forward, one (possibly two) step back. The question remains, “Does anyone care?”

The web crowd has made an industry out of ignoring the privacy, instead leaving the matter to the service providers for whom they have built out today’s social computing platforms. Yet, ignoring it has failed to make it go away. With Google tracking one’s online behaviour to target online advertisments, controlling a large amount of what is seen online through its search results, amassing the largest library in recent history, owning huge share of the online video market; recording one’s voice, voicemail and SMS messages; and offering a wide range of services that bring more and more daily online habits into its online sphere, the company alone has access to the daily habits of their users. 

Amongst continued attention to the misuse of social computing, one can more easily encounter people who still blithely trust providers with their privacy. Although with a little insight, one can easily understand why some providers dismiss privacy concerns entirely, it is far more curious that users en masse have agreed with such dismissals.  

In a CNBC interview, Google CEO Eric Schmidt explained his stance on online privacy "If you have something that you don't want anyone to know, maybe you shouldn't be doing it in the first place. If you really need that kind of privacy, the reality is that search engines --including Google --do retain this information for some time and it's important, for example, that we are all subject in the United States to the Patriot Act and it is possible that all that information could be made available to the authorities."

The problem with that point of view is that it assumes one can only be concerned about privacy when they are doing something illegal or unethical. For those with limited historical or cultural literacy, the first thing they may want to learn is that laws can change, and not necessarily in an ethical, moral or logical manner. Some of the 20th century’s greatest atrocities were deemed “legal” by the regimes that committed them. Believing “it can never happen here” (wherever that may be) doesn’t ensure such atrocities cannot be repeated. On a more mundane level, prohibiting discrimination based on gender, race, orientation or religious beliefs (or lack thereof) does not prevent it from occurring; and rights that have been extended to groups outside what “the majority” may consider “traditional” or “mainstream” can be easily repealed and rolled back (take California’s Prop 8, for instance). To anyone with any depth of historical or cultural understanding, laws are a frightening fluid and mutable construct. Blind faith in any legal system has only led to tears.

It also completely ignores that information involved with legal and ethical behaviour can be abused in many ways. Knowing a person’s near-real-time location combined with their home address, occupation, family, and all these imply, leaves that person and/or their loved ones vulnerable to various crimes. People too often open themselves to such vulnerability by providing basic information. 

Thirdly, this doesn't take into consideration the myriad ways that data can be inadvertently leaked or compromised by search engines like Google, or social networks like Facebook. Just because people want information to be private, it doesn't mean that they are trying to hide anything like shady activity. It simply means that some information is sensitive or confidential, and for a reason.

For businesses that rely on the public cloud, there is a level of trust there that provider will respect the privacy of that data and protect it from unauthorized access. Comments like those made by Schmidt provide another reason to think twice about using public cloud for any sensitive or confidential communications.

More providers are privy to a great deal of information which could be used to reach conclusions. Whilst it is important for them to take privacy seriously, it is far more important for users to understand what they are getting into with such services. 

Service Level Agreements - the fine print of the cloud, web and social computing - are only beginning to receive the attention they deserve. “Just trust me”, “Don’t be evil”, and “50 million people use this service” mean little when one’s privacy is invaded, and that information abused to engage in nefarious behaviour ranging from unethical to criminal activity. The fine print in important, and one can choose services that meet required levels or privacy, or simply choose not to use a category where none are to be found. 

Whether one believes they have information of which they should have privacy concerns, they do regardless. Not every service endeavours to protect users’ privacy, who are better served by a realistic attitude to concerns than by blithely trusting providers to do what’s right. The approach that unless one wears a tinfoil hat or has terrorist connections, they have no right to be concerned about privacy - "cheer up love, it might never happen" - has no place in an increasingly networked world. 

Too much fluff

Given the "novelty" of cloud - principally as a concept rather than with any technology - I have found a strong need to level set whenever doing anything of consequence with it. Whilst this often is received gratefully, there are many times when level set is written off as "too much fluff" and unnecessary. Where concepts, models, architectures and technologies are well understood, level set is not as important or necessary. Yet with the nebulousness of the cloud - made apparent when it takes a year for the industry to agree to the otherwise self-evident definitions of SaaS, PaaS and IaaS - level set is critical to starting any endeavour, investigation, reporting of results, or other activity. A high degree of FUD still permeates cloud, and not clearing it away through a level set only leads to poor decisions. 

It is a common phenomenon in engineering to focus on detail to the exception of all else. This is a factor of decomposition, yet when details command most or all of the attention for solving a problem, the overall direction is lost. Sun Tzu's statement, "Strategy without tactics is the slowest route to victory; tactics without strategy is the noise before defeat" is just as applicable to engineering as to war. Without an understanding of the problem to be solved and the strategy to solve it, the details are only noise. One must understand both well to be an effective technical leader; one must understand what is the strategy and overall directon to be an effective engineer. 

Still have doubts? Let me tell you a story: A vendor of desktop software solutions not too long ago began to explore cloud as a high-level strategy to lower TCO for both themselves and their customers, largely as a reaction to pressure from Google. The vendor understood the benefits of developing cloud services for their product, but lacked a coherent understanding and strategy for making the transition. There was no level set, and as a result, all thinking delved directly into details - what technologies to use/build, what features were needed, how and where to deploy. The result was an exclusive focus on technology and loss of sight of the problem to be solved. The technology decision was made first, and all subsequent decisions had to fit that technology set. Time and resources were badly wasted trying make something that few users wanted to needed work with the chosen technology; the vendor ended up reinventing in poor form an number of technologies outside their core competencies; the pilot projects failed and were scrapped; and the vendor was set back by several years in their efforts to compete. At very least, the detritus was salvaged toward another, far more limited project which, with the expensive lessons of excessive detail and technology focus, has been able to enjoy a measure (albeit muted) degree of success. All this from "setting the cart before the horse."

The first lesson of the story is the danger of taking technology decisions outside any framework of the problem to be solved and a strategy to address it. When the vendor committed themselves to a particular technology choice outside of any problem/solution context, they limited every decision and direction they could subsequently take, and turned their focus to square pegging everything to that technology. If a particular feature set was not available for that technology, they built it themselves, rather than stray outside the technology base. This was justified with the argument that it would simply be "prohibitive" for their engineers to learn anything new and to not maximise existing experience, which is not unheard of in IT. Failure was guaranteed from the beginning. 

The second lesson is the danger of not level setting so as to ease the understanding of the problem to be solved and how to approach it. Nearly no one in the vendor's technical staff could agree on direction, measures of success, or even what was cloud. Technology focus was offered as comfort food, empty calories to provide a sense of direction where there was none. Since no one could agree on anything other than the technology being used and the issues inherent with that technology, it demanded all attention, and the elephant in the room was never acknowledged. 

It is far more dangerous to not level set than it is to face the slings and arrows of "too much fluff" from those who only want to hear about the details. My advice: Don't get caught up in the "too much fluff" argument. Level set first; permeate understanding of the problem to be solved, the strategy and direction which provide the framework within which to delve into the details. Without this, one is just showing off how well they understand technical details, and not seeking to solve any real, practical or even academic problems. If someone is saying there's "too much fluff" in your strategy, model or architecture proposal (that covers a new or nebulous concept like CC), more often than not, it is really a compliment - it means you're doing enough level setting. IMHO, for topics such as CC where there are few standards and little to no shared consensus, you really cannot do too much level setting. You need to "set the cart behind the horse, not before."

Additionally, with CC, the level of confusion and misinformation is to an extent where level setting is critical. One may think they "get it", but until CC is well defined and at least started on the path to standardisation, it is important to go over the basics so that everyone understands the context. Saying "I get it, let's just dive into the details" misses the chance to prevent major misunderstandings and context switches later on. When people claiming to be architects making statements as, "Cloud? SaaS? That's easy - all I need is J2EE - I can just make my EJBs into services" (which, to the uninitiated, makes as much sense as, "I can see Russia from my house"), it is obvious there is much to cut through to really know what one is talking about with CC. 

So, when talking CC, "too much fluff" feedback likely means you are providing just enough level setting. That's not to say that the same feedback for a well-defined, well-standardised topic should not be taken literally. ;)

Standards and diversity

Mike Masnick's TechDirt article explored and important issue: Which is more important for innovation: A standard platform or competition? He evaluated with respect to gaming systems, but the arguments can be easily applied to many ecosystems - e.g., standardisation vs. diversity for OSs, Telcos, RIAs, etc.

IMHO the heart of the issue is:

… where the biggest economic contribution comes from: the platform or the applications on top of the platform. If it’s the platform, then competition makes sense. If it’s really the applications on top of the platform then it’s going to make sense for there to be a standard to let the competition occur on top of the standardized platform.

That said, I view innovation through the lens of what problem it aims to solve? As in other posts, I make it clear that innovation in isolation ends up in the vault, for engineers to prop their egos, but a very low ROI. :-) The question of standards and diversity is a cyclical one. Standards and platform hit the mark when they enable the business models which consumers seek (and for which they are willing to pay. The tendency is for the standards owners to dictate terms once standard becomes dominant, which is a cross-purposes to enabling business models. There is little-to-no profit motive in enabling new business models, and yet focussing elsewhere (e.g. operational efficiency) leaves the door open to competition in this arena. This drives the development of competing standards, which then triggers a new cycle of diversity, which eventually will result in another cycle of standardisation, and so forth.

bush re-elected

from the AP - kerry concedes the election, making bush the winner. a statement is expected by 18.00 UTC.

too close to call

as of 19.00 UTC, the 2004 elections have added to the g.o.p.'s control over the u.s. congress. the presidential election is still very close. although two american national networks have predicted a bush victory in the critical state of ohio, kerry is not conceding victory therein, as there remain 250k votes which will not be counted for another day (bush leads only by 107k votes). if bush wins nevada, iowa (in both of which kerry still leads) and new mexico, and kerry gets wisconsin and michigan, bush still will not have enough electoral votes to win without ohio. as such, it will be the determining state, although bush is approximately 3 percent ahead in the nationwide popular vote. at this point the electoral vote is 249 bush, 220 kerry.

more on outsourcing

as i continue to ramble on about outsourcing, i wanted to present some additional organised thoughts on why it isn't the panacea for the U.S. economy:

1. the U.S. labor force is not better trained, harder working, or more innovative than its foreign competitors. the argument that the U.S. will create new jobs in highly paying fields simply is not true. the U.S. has no comparative advantage or superiority in innovation. to assume that Americans are inherently more creative than foreign competitors is both arrogant and naive. now, the U.S. is currently empowering our competition with the resources to innovate equally as well as we. consider the number of new non-native Ph.D.s that leave our universities each year; consider the low rank in the U.S. in the education of mathematics and the sciences; and consider the large number of international students enrolled in the most difficult technical degree programs at the most prestigious universities in the U.S.

2. most of the best and high-paying jobs in the U.S. can be exported.
* doctors (even surgeons)
* mathematicians
* accountants
* financial analysts
* engineers
* computer programmers
* architects
* physicists
* chemists
* biologists
* researchers of all types

3. cost reductions and other benefits provide a strong incentive to outsource jobs. a company that decides to move its production overseas cuts its costs in many ways, including the following:
* extremely low wage rates
* the circumvention or avoidance of organized labor
* no Social Security or Medicare benefit payments
* no federal or state unemployment tax
* no health benefits for workers
* no child labor laws
* no OSHA or EPA costs or restrictions
* no worker retirement benefits or pension costs

besides cutting costs, there are other benefits to exporting jobs, including the following:
* tax incentives provided by the U.S. government
* incentives from foreign governments
* the creation of new international markets for the company's products (which ultimately empowers the company to turn a deaf ear to this country's problems and influence)
* the continued benefits of our legal system and the freedoms that the U.S. provides

the net effect of all of this is lower costs, higher revenue, higher profits, higher stock prices, bonuses for management, and the creation of wealth for a subclass that benefits from low taxes at the expense of everyone else.
at present there are considerable tax incentives for U.S. companies to outsource, most significantly earnings deferral.

as a society and as a country, the U.S. experiences many costs from outsourcing, including the loss of jobs, social costs, higher costs of raw materials and loss of national sovereignty. loss of jobs reduces the tax base, creates high unemployment benefit costs, and raises the cost of government retraining programs. displaced, unemployed workers have higher rates of child and spousal abuse, alcoholism, bankruptcy, divorce, etc. as China and India and other large populations grow, they demand huge quantities of oil, gas, steel and other basic raw materials. these costs are born by all Americans -- e.g. every time you fill your gas tank. and as a nation, the U.S. will lose its ability to make independent decisions that are in its best interest when it is dependent on foreign debt and foreign manufacturing.

outsourcing

i've recently read Stephen Cohen and Brad DeLong's Thinking About Outsourcing, an excellent perspective on the issue. with my first-person perspective on hi-tech outsourcing, i have generally seen it fail badly. the lack of a legal framework for ip and information safeguards in many nations, the time zone and cultural differences, the communication barriers, and the lack of control from HQ all conspire to make the outsourcing strategy fail. this is especially acture where the work involved requires a high level of expertise and in-depth, hands-on experience.

i have worked at two organisations which had outsourced software development efforts for enterprise products, and both efforts were dismal failures.

one was with a team in bangalore, india; this team was erudite and possessed the necessary acumen for the work, but the other factors listed above doomed the effort. there was never enough presence from the architects and designers of the products at the remote site to keep the project on track, and despite daily conference calls and emails aimed at ensuring maximum communication between both sides, it always took at least a day to turn over even the minimum tasks or research. the work they produced didn't appropriately meet requirements, even though the coding was sound, and they always had to be pushed to ask the appropriate questions. their impl had to be sent back to be redone more than once, and in the end still required rework from the engineers in the home sites.

another was with a team in singapore. where bangalore is a tech centre, singapore is most definitely not (you can find a pool of talented investment bankers there, but your choice of hi-tech professionals is quite limited). the company could not find the appropriate personnel for the projects to be completed in singapore, and they managed to botch every project sent their way; every one required considerable engineering intervention from the engineers in the home sites. the company eventually decided to shut down the outsourcing effort and bring back all development to the U.S. (but quietly, unfortunately, so the illusory allure of outsourcing was never impacted).

in both cases, there were no actual cost savings for the companies involved. more money was spent in the outsourcing effort than would have been spent keeping the same work at the home sites. however, both claimed cost savings from a line item basis (the usual U.S. corporate technique used to hide failure).

although this isn't a statstically relevant sample, it does highlight how assuming outsourcing success using present metrics is poorly based. salary rate arbitrage and employment tax evasion - the main benefits of outsourcing - do not guarantee operative success, and ip based endeavours always involve barriers in expertise, practises, process, and communication. outsourcing is not the panacea as claimed by U.S. executives; it is simply a way to continue hiding the cost of doing business in an ambiguous expense category, and persist tried and true pennywise/poundfoolish management practises.

however, i have worked closely with two organisations which have successfully made use of offshore resources. these did not pursue outsourcing, but a globalisation strategy, where they invested and developed technology centres across the globe - over a number of years - to tap local research, development and marketing expertise. in both cases, the companies had these centres focus on specific technology areas, and did not unduly over-divide responsibilities. for example, one company made its bangalore centre entirely responsible for the implementation of a particular EAI stack, following specifications which were developed in north america, japan and europe, taking advantage of the communication and cultural infrastructure it had spent years developing.

what was the difference between these two globalising companies and the other two outsourcers? the former focussed on a long term strategy which would best leverage talent pools and resources at each centre, while the latter focussed on a short term strategy to cut salaries and other business costs.

this latter trend is most troubling, because organisations following it are in essence looking to exploit a foreign workforce through salary arbitrage. the focus is on slashing costs for the quarter and fiscal year and not on global presence. as soon as the workforce currently used becomes too 'expensive' for the organisation's taste, it picks up and moves elsewhere. there is no overall strategy other than to preserve executive compensation (one of the two outsource failures i mentioned above cut 15% of its workforce - in essence taking it out of the market in several product offerings - in the space of 6 months, while giving its CEO a 10% pay raise, where that money could have paid for those employees for more than a year and kept the company in lucrative markets).

another disturbing effect of this trend is the negative impact the development of U.S. hi-tech talent. the less jobs there are in the U.S. for hi-tech professionals, the less incentives university students will have to enter hi-tech fields. and the so-called 'higher-level' tech jobs (architecture & design) are not available to university graduates without considerable work experience. where are these grads going to get such experience? China? India? not bloody likely, where U.S. citizens have fewer chances of getting a work permit than Chinese or Indian citizens have in the U.S. flooding these markets with foreign workers would kill their hi-tech industries.

the last recession ('90-'93) illustrated that the U.S. educational system had a steep drop off in hi-tech grads and did not recover until 1998, when the boom had already been running for at least two years (the boom didn't really start until 1996). of the '90-'93 hi-tech undergrads, it has been estimated that 50% were lost to other fields/industries because no jobs were available to them until late 1994; until late '94 5-8 years experience were required for even the most basic jobs. approximately 25% of hi-tech masters/doctorate grads were lost to other fields/industries during this period for the same reasons.

what is worse in the '01-'04 recession is that the jobs from which required experience is developed won't be around in large part in the U.S.. U.S. citizens are largely barred from jobs in the hot foreign hi-tech markets unless they are hired by U.S. companies. yet U.S. companies have shown a disturbing trend of not hiring citizens for such jobs because they can still demand higher salaries than foreign workers. it is a vicious cycle, and the portents are not good for U.S. hi-tech and r&d primacy.

however, it may take the loss of this primacy to motivate the rank and file in the U.S. to act. presentlly, it seems there is not enough motivation among the electorate to enact any substantive change. the votes - whether actual or not - keep going to politicians who only serve to increase the incentives for outsourcing. the election of Schwarzenegger as governor of California was particularly distressing: California in particular has undergone an especially grim experience in the '01-'04 recession, yet the electorate blissfully continues to place political candidates who only serve to exacerbate it's economic woes. this political naïveté goes beyond 'panem et circenses', since the electorate continues to directly place (or at least believe that they are) into power those who are openly acting against their interests.

at one point or another, it will become apparent that U.S. corporate executives neither have a G-d given right to a job, nor a G-d given right to disproportional compensation, especially at the risk of shareholders, employees and the industry. hopefully this will happen before the U.S. experiences further economic damage, but i doubt it.