All About Outsourcing

Slashdot recently ran a story entitled The Unstoppable Shift of IT Jobs Overseas which had lots of comments that surprised me. I am used to the hypocrisy of the Slashdot crowd. The people who keep posting about how musicians need to "adapt or die" with regards to dealing with the rise in copyright infringement brought on by the popoularity of MP3s or liken the replacement of proprietary software with Open Source equivalents as "the automobile replacing the horse & buggy" are often quick to complain about H1-B programs or outsourcing failing to realize the parallels with other aspects of the technological landscape.

However I was quite surprised to see lots of people taking the same attitude with regards to outsourcing. Many posters opined that software developers and IT people need to "adapt or die" instead of complaining about the effects of globalization and blaming "fatcat executives". The best post of the bunch was Advocates of freedom don't advocate this.

You don't have a right to an IT job. If you have one, great. Make sure you have skills that are so valuable that you won't be outsourced. If you can't do that, then find another line of work, you lazy bastard. Should the government have done something to protect operators of horse drawn buggies that were put out of business when cars came to the market?

I was thinking about going into IT. The recent fad of outsourcing makes me rethink my priorities. I don't want to benefit by causing prices to rise beyond free market levels and screwing my fellow citizens who have little to do with this.

When Microsoft pleaded that the GPL would destroy their ability to make money, someone responded, "Tough. Adapt or die."

So, to those IT workers who feel they're being cheated by having something taken from them, when in fact they did not have an inherent right to what they have:

Tough. Adapt or die. Offer something in America in IT that foreigners cannot offer or find some other line of business. I refuse to support people who want to screw me.

I agree 100%. Good stuff. However I do think that the current rash of IT outsourcing is bordering on excessive and will likely cause problems for the US in the future [which no one cares about since the major decision makers both government and business are driven by short term results]. I like the post entitled You've discovered the time bomb which points out

The jobs get outsourced to Indian Consulants, but the end result in products or whatever is still sold here for the same amount, only with a much higher profit. BUT, here's the rub, we have Americans making less so they can't afford to buy a bunch of overpriced american goods any more. A bunch of Indian programers and accountants making $6000 a year aren't going to be lining up to $1500 Amana Fridges, $30000+ ford SUVs or $20 brittany spears cds. Except the CEO's still want to make thier 20 million a year salaries. There will be massive defaltion, something has to give. The CEO's want to make all the money, only problem if they have all the money and they aren't paying US and they aren't paying the Indians a whole lot, no one has the money to buy thier stuff.

I keep wondering whether the current IT outsourcing trend will become part of the national discourse and end up as an election issue next year. As for being somewhat cautious on the rash of outsourcing it seems I'm not the only one, both Gartner and Forrester have issued words of caution in recent weeks.

#

The Goal of Open Source and Free Software

Tom Lord wrote

There has been a sort of tension in the commercial free operating system world:

(a) Are we building a free alternative to proprietary software?

or

(b) Are we building a commodity, $0-price OS component to lower the cost of proprietary applications?

If the goal is (a), the we need an architect. We need to come up with an inexpensive-to-develop architecture that, nevertheless, contains viable solutions for the needs of our markets.

If the goal is (b), then we need an anti-architect. We need to come up with impossibly-expensive-to-fully-develop clone projects of proprietary software to draw off the energy of volunteer contributors who might otherwise undermine the value of the proprietary applications we expect to drive revenues for our distro.

For example, under (a), we would probably have to admit that trying to clone all the Java libraries _and_ build a competitive Java implementation is too expensive a course of action. While we might be perfectly happy to ship a low-end, incomplete implementation to help the low-end of the market, in the long run, we'd want to look for a more clever solution: something that can compete with Java and Java libraries on functionality, but that is cheaper to build in the first place (and cheaper and more effective to apply, of course).

If you are a proprietary vendor, and your goal is to introduce a new proprietary technology to the market, it makes sense to make that technology as expensive to develop as you can -- so that others can't casually come in and compete with your implementation on price. You can make things expensive to develop with legal barriers (like trademarking the Java name), and you can also make things expensive to develop by structuring them as an object oriented framework that you then spend zillions on filling out with subclasses, or by making really hard components (like finely tuned JIT compilers and garbage collectors) critical to implementations.

If you are like me you probably thought about the Mono project and realize that the above description applies to them as quite well. I haven't tracked the Mono project as much as I'd like but I tend to agree with Tom Lord's analysis of the situation. Trying to clone a large software platform that is continually evolving is a losing proposition.

I'm no longer sure what the goals of the Mono project are nor am I sure what they were to begin with. At one time it seemed like an implementation of the standardized bits of the .NET Framework namely C# and the CLI but they seem to have broadened their goals a lot since then. Specifically from the compatibility section of the Mono FAQ

Question 55: Will missing API entry points be implemented?

Yes, the goal of Mono is to implement precisely the .NET Framework API (as well as compile-time selectable subsets, for those interested in a lighter version of Mono).

The entire .NET Framework? Sounds ambitious. Given that the current Microsoft Developer Tools Roadmap implies there'll be two releases of the Visual Studio and the .NET Framework in the next two years ("Whidbey" and "Orcas") I wonder how the Mono folks plan to deal with this given that they're implementations of v1.0 of the .NET Framework are still lacking based on the comments in the FAQ.

I wish them luck and suggest that they send someone to PDC so they at least get some idea of what is coming. Tom Lord's suggestion that OSS folks should build simpler solutions to user problems instead of cloning more complex solutions has merit. The problem is that OSS developers typically cannot do this effectively because it means they actually have to know and understand a wide range of customers (aka users) and their scenarios which is often not the case for Open Source projects that are mainly "itch scratching" excercises.

It's easy to say Java & the JVM or C# and the CLR suck but it is a lot harder to design and implement an alternative that takes into consideration all the various customer feature requests that made the technologies end up the way they are.

This is where I probably disagree with Tom Lord, in many cases the platforms are not complex because the vendors don't want competitors cloning their product and competing on price (although there is definitely some of that) but because the problems they are trying to solve are actually complex and cover several differing scenarios.

#


--
Get yourself a News Aggregator and subscribe to my RSSfeed

Disclaimer: The above comments do not represent the thoughts, intentions, plans or strategies of my employer. They are solely my opinion.