[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Wrong business model?

This is how some government contractors work.  They 
get to function more autonomously, but often design
products for exclusive use by the government.
Competition among contractors breeds innovation. 

Note that the largest [private] revenue generating 
entity is a decentralized collection of autonomous
subunits, competing and cooperating simultaneously-- 


> From: David Farber <dfarber@numenor.com>
> Date: 2003/02/26 Wed AM 10:37:15 CST
> To: ll1-discuss@ai.mit.edu
> Subject: Wrong business model?
> So the business model implied in a lot of the recent discussion here appears to be:
> 1) Identify a market opportunity.
> 2) Bring together a small group of the best programmers you can find and put them to work using the best language possible to create a product that meets the market opportunity identified in Step 1.
> 2a) Use the language you have chosen to deliver the product within a time frame and with a feature set that could not be matched by using a more popular/mainstream but less powerful/expressive language.
> [In either order]
> 4) Sellout to a big company.
> 4) Rewrite the product in a more popular/mainstream language.
> 5) Take the money and run while...
> 5a) The big company that bought you out hires a small army of programmers to maintain and extend the product in the more popular/mainstream language that it was just ported to.
> 6) Repeat.
> I find the first half of this model (Steps 1 through 2a) quite appealing; I'd like to try it myself. But the second half seems, um, off. First, unless you sold your company for a /lot/ of money, you've failed to sufficiently prime the pump for the next iteration (ie. Step 6). Second, rewriting the product and hiring a small army of green programmers isn't economically efficient--your product effectively costs the buyer more than the purchase price of the company which means they could have paid you /more/ if the total lifecycle cost of the product had been less.
> So it seems to me that a better "second half strategy" would be:
> 3) License the product to a big company.
> 3a) Be sure to charge them for what the product is /worth/ to /them/. This will be more (perhaps even a LOT more) than what it costs you to maintain and extend the product.
> 3b) Say nothing about the language used to implement the product. Tell them that it is confidential information, part of your competitive advantage. Keep all discussion at the feature level and refuse to talk with them about implementation. (OK, I am exagerating for emphasis here.)
> 4) Repeat, using the excess money from the licensing income stream to fund the next product.
> Comments? Paul? Dan?
> david
> --
> David Farber
> dfarber@numenor.com