Don Marti

Fri 12 Sep 2008 04:33:46 PM PDT

Funding software: Scarcity and risks

David N. Welton points out some ways to pay for free software.

Fund it as a public sector project, with tax money. (Hey, it worked for ARPANET and the DARPA-funded BSD.)

Do consulting work, but it's hard to get clients to pay for fundamental new ideas and for infrastructure code that benefits multiple clients.

But there could be another way.

The problem, though, is that too often we think about the presence of technology as a good, rather than thinking about the inability to get some technology as a risk. A lot of people write about ways to sell software—especially figuring out a way to measure what the customers use like scanning soup cans at the supermarket—when an important part of what customers want isn't necessarily a seat of this or a license to that, but the ability to get it if needed.

If you make plans based on constant technology, then progress is a surprise and a gift. But nobody makes IT plans without assuming that things are going to get better, faster, cheaper. When they don't, that's a problem.

If you think about planning for the available technology of the future as analogous to planning for the weather of the future, you might want something like WeatherBill to hedge.

Real simple example: you have a 1000-watt generator, and your web server does 1000 pageviews per second at one J/pageview. Unless somebody invents a more efficient web server that runs at less than that, you're at risk of having to buy a bigger generator.

You don't know at what point in the stack the innovation will come, or if it will. It's a completely unknown risk. So why not hedge it? Buy a futures contract that will pay you, to compensate for your cost to upgrade your generator, if no sufficently efficient web server exists. Then you don't really care who buys the other side of the contract. A hardware manufacturer, OS hacker, or web server developer could make it work and claim the reward, in which case you lose your investment in the futures contract but you don't have to buy a generator. Or if it doesn't work, you make money on the contract but you do have to buy a generator.

Tom W. Bell came up with the idea, which he calls a "SPEX" in Prediction Markets for Promoting the Progress of Sciences and the Useful Arts."

More contractual tools:

Alex Tabarrok: The Private Provision of Public Goods Via Dominant Assurance Contracts

Dr. Paul Harrison: The Rational Street Performer Protocol.

Chris Rasch: Wall Street Performer Protocol

The other problem with markets for software, of course, is mismatch between the interests of stockholders and users. Your software supplier might be worth more to a competitor as a buy-and-kill than as a going concern. Sean Park points out that the right capital structure for a mature software company is different from the right capital structure for a startup.

A SPEX might get you to proof of concept. Next step: what about splitting a software company into two: the operating company, which employs all the people, organized as a consumers' cooperative owned by the customers; and a separate holding company, owned by the founders and original equity investors, which starts out owning the software's copyrights, trademarks, and patents? The holding company then sells its assets to the operating company along the lines of an Islamic mortgage—transferring a percentage of the ownership each year and collecting rent on the rest. At the end, you have a completely user-owned, takeover-proof company.

This might not have worked back in the day when you needed eight figures to launch a company, but with today's as smaller teams and all-angel funding, it might work better.