If you want to write software to make money you have to provide something people want.
Figuring out what people want requires doing market research in the US.
Assuming that a software company in india can do that kind of research 100% remotely (without people here in the US); they'd have to raise funds to start their own company. India's Venture Community is not quite as well developed as the US. And the banking/financing system is not as well developed, so obtaining loans from "1st Bank of Bangalore" might be an issue.
Now, assuming that they have an idea, they have the money to start the company, and they've got the product... they STILL need to come to the US and market and sell that product to the firms in the US.
So the strange thing is it still requires workers in the US, and some level of US production. Consider, while the Japanese back in the 80s produced autos and imported them--- after a while, they needed to move sales, marketing, and manufacturing to the US to ensure that what they were making addressed US needs.
The fact that so much software is written in corporations is the one reason why the outsourcing bubble will eventually pop.
Oursourcing the maintenance of your OS/390, and Oracle RDMBS is one thing. Application development is entirely different.
Can you imagine a wall street type trying to explain to developer, with no prior knowledge of financial services, how to write an application to manage securities trades? Now think about that and add a cultural, language, and time/distance barrier.
Even if a solid specification could be written, think about who's going to be writing that specification. And think about -how- they'll be writing that spec.
The "analysts/designers" here in the US would probably not assume knowledge of complex things like US Securities Practices; but they'll probably assume things like accounting and trading concepts.
But therein lies the problem, if the developers lack even the most fundamental knowledge, how will they comprehend the higher-level specs. Now, that won't stop them from writing the software, things that they don't know they'll assume. Which means more testing stateside to ensure that the code is acting correctly.
I went through this process at a product company. We wrote beautiful specifications, but even then, not only did I have to spend 25-30 extra hours a week handholding over the telephone. A bunch of us spent a great deal more time here running through test cases. Our total savings were probably closer to a 20% vs 50%-60% everyone seems to believe they're going to get.
It would have saved us time, and we would have gotten a better product, if the PHBs had let us hire another programmer with domain experience.
Think, the guys that work inside the insurance company or pharmacuticals firm have loads of inside, and specific knowledge about how the industry and that specific firm works. Often it's not possible to obtain that info without having had worked in that kind of environment.
More to point: What's to stop someone from creating an internet based CD library.
Operations would work similar to NetFlicks, except rather than having a centeralized depot where CDs and DVDs are mailed to and fro; the mailings are done individual to individual.
So Music Library basically keeps: Info about album ownership, where the album is physically located, and how many albums people have out, and escrowed $$$ (more on this later).
So assume I own a copy of "XYZ Album."
1) I notify the "Music Library" that I have a copy to lend. 2) Five people want to listen to it, so they notify music library and queue up. 3) I mail the album to person1, notify "Music Library" 4) person1 receives the album, notify "Music Library" 5) When person1 is done listening to the album, s/he mails it to person2... and so on.
So where are the risks?
a) Individuals might not send/return albums as required.
Basically: Don't lend what you don't want to lose. Secondly: If you really want something ASAP you can always go out to your local record-mart and buy it.
Secondly: Individual that wants to borrow the CD put money into an escrow account that "Music Library" holds in the user's name.
So, I have XYZ Album, person1 wants to borrow it. Person1 puts money into escrow/deposit (basically replacement cost for XYZ). Person1 listens to and enjoys the music; and when they're finished they ship it off to Person2. When person2 reports Recepit of the album -- Person1's funds are "unlocked" out of escrow.
There's an interesting side effect to this as well. If a borrow decides they really want to purchase this CD they can do by notifiying Music Library. They money then flows out to the individual that owns the album.
This might even serve as a pathway for simplifying the structure further. Rather than "borrow" the album, individuals in the chain are temporarily owning the album and "reselling it" to the next person in the queue.
b) Poor content
The major issue would be that the vast majority of people probably wouldn't want to lend their stuff; or the stuff that would be rented would be stuff no-one wants to listen to (ie. Bruce Willis' Return of Bruno).
One way around this would be to require an initial setup fee from individuals which the Library would use to acquire new works that the subscribers want on --- much like how a museum or private library works.
Another would be to work with -real- libraries and borrow their works.
Slashdot Mirror
If you want to write software to make money you have to provide something people want.
Figuring out what people want requires doing market research in the US.
Assuming that a software company in india can do that kind of research 100% remotely (without people here in the US); they'd have to raise funds to start their own company. India's Venture Community is not quite as well developed as the US. And the banking/financing system is not as well developed, so obtaining loans from "1st Bank of Bangalore" might be an issue.
Now, assuming that they have an idea, they have the money to start the company, and they've got the product... they STILL need to come to the US and market and sell that product to the firms in the US.
So the strange thing is it still requires workers in the US, and some level of US production. Consider, while the Japanese back in the 80s produced autos and imported them--- after a while, they needed to move sales, marketing, and manufacturing to the US to ensure that what they were making addressed US needs.
The fact that so much software is written in corporations is the one reason why the outsourcing bubble will eventually pop. Oursourcing the maintenance of your OS/390, and Oracle RDMBS is one thing. Application development is entirely different. Can you imagine a wall street type trying to explain to developer, with no prior knowledge of financial services, how to write an application to manage securities trades? Now think about that and add a cultural, language, and time/distance barrier. Even if a solid specification could be written, think about who's going to be writing that specification. And think about -how- they'll be writing that spec. The "analysts/designers" here in the US would probably not assume knowledge of complex things like US Securities Practices; but they'll probably assume things like accounting and trading concepts. But therein lies the problem, if the developers lack even the most fundamental knowledge, how will they comprehend the higher-level specs. Now, that won't stop them from writing the software, things that they don't know they'll assume. Which means more testing stateside to ensure that the code is acting correctly. I went through this process at a product company. We wrote beautiful specifications, but even then, not only did I have to spend 25-30 extra hours a week handholding over the telephone. A bunch of us spent a great deal more time here running through test cases. Our total savings were probably closer to a 20% vs 50%-60% everyone seems to believe they're going to get. It would have saved us time, and we would have gotten a better product, if the PHBs had let us hire another programmer with domain experience. Think, the guys that work inside the insurance company or pharmacuticals firm have loads of inside, and specific knowledge about how the industry and that specific firm works. Often it's not possible to obtain that info without having had worked in that kind of environment.
More to point:
... and so on.
What's to stop someone from creating an internet based CD library.
Operations would work similar to NetFlicks, except rather than having a centeralized depot where CDs and DVDs are mailed to and fro; the mailings are done individual to individual.
So Music Library basically keeps: Info about album ownership, where the album is physically located, and how many albums people have out, and escrowed $$$ (more on this later).
So assume I own a copy of "XYZ Album."
1) I notify the "Music Library" that I have a copy to lend.
2) Five people want to listen to it, so they notify music library and queue up.
3) I mail the album to person1, notify "Music Library"
4) person1 receives the album, notify "Music Library"
5) When person1 is done listening to the album, s/he mails it to person2
So where are the risks?
a) Individuals might not send/return albums as required.
Basically: Don't lend what you don't want to lose.
Secondly: If you really want something ASAP you can always go out to your local record-mart and buy it.
Secondly: Individual that wants to borrow the CD put money into an escrow account that "Music Library" holds in the user's name.
So, I have XYZ Album, person1 wants to borrow it. Person1 puts money into escrow/deposit (basically replacement cost for XYZ). Person1 listens to and enjoys the music; and when they're finished they ship it off to Person2. When person2 reports Recepit of the album -- Person1's funds are "unlocked" out of escrow.
There's an interesting side effect to this as well. If a borrow decides they really want to purchase this CD they can do by notifiying Music Library. They money then flows out to the individual that owns the album.
This might even serve as a pathway for simplifying the structure further. Rather than "borrow" the album, individuals in the chain are temporarily owning the album and "reselling it" to the next person in the queue.
b) Poor content
The major issue would be that the vast majority of people probably wouldn't want to lend their stuff; or the stuff that would be rented would be stuff no-one wants to listen to (ie. Bruce Willis' Return of Bruno).
One way around this would be to require an initial setup fee from individuals which the Library would use to acquire new works that the subscribers want on --- much like how a museum or private library works.
Another would be to work with -real- libraries and borrow their works.
Thoughts?