4 ms·

I know, it's the question. But I recall pg claiming something to the effect of "if it's something people want, don't worry, we'll find a way to make money from

by cool-RR 18y ago

I know, it's the question. But I recall pg claiming something to the effect of "if it's something people want, don't worry, we'll find a way to make money from it." (I'm probably not 100% accurate with this quote, I don't remember exactly how he said it.)

blender 18y ago
He said: "Because making something people want is so much harder than making money from it, you should leave business models for later, just as you'd leave some trivial but messy feature for version 2. In version 1, solve the core problem. And the core problem in a startup is how to create wealth (= how much people want something x the number who want it), not how to convert that wealth into money." Cheers
braindead_in 18y ago
Few obvious things which come to mind. 1) Dual licensing 2) Charge for commercial support 3) Sell hosted versions (might not apply to you) 4) Advertising?
- huhtenberg 18y ago
  #1 and #2 require substantial legal expense and a lot of subsequent sales and support management effort. And unless a founder has a prior experience building this kind of organizational infrastructure, it will be a very painful experience to go through. All in all, it's a project that is simply too risky for the investors to put their money into.
gojomo 18y ago
I think the subtext of that advice is that you're still making something that is eventually excludable/controllable, so you have options. For an open-source library, the right-to-fork and to use without paying licensing fees means many of the options used by other startups which defer revenue questions in favor of building an enthusiastic userbase are already off the table for you. You can't easily withhold your product unless fees are paid; you can't add advertising; you may not be in a position to sell excludable complementary offerings. You could try a dual-licensing structure like Sleepycat BerkeleyDB -- free for other open-source projects, pay if you want to use in a closed-source application. However, that presupposes a large closed-source commercial market for the software your library-users make, requires some capability for closing big corporate sales, and it may take years of proven library quality before becoming the solid/safe choice for companies to embed in their own products.
- inimino 18y ago
  "I think the subtext of that advice is that you're still making something that is eventually excludable/controllable" And the unstated assumption of that interpretation is that it is impossible to make money without coercion.
  - gojomo 18y ago
    That's not a fair reading; I don't assume that coercion is necessary to make money (nor do I believe PG assumes that). Excludability ≠ coercion. An advertising-supported site can exclude non-payers from using their advertising inventory. Money is made without coercion (and free/open-source software might be provided as an audience generator). A consulting/services/support business can refuse to provide their service to non-clients. Money is made without coercion (and free/open-source software might be central to the delivery of services or expression of expertise). A paid-subscription website can exclude non-subscribers. Money is made without coercion (and free/open-source software might be provided as a complement to the paise service). The OP's proposal of angel-funding an open-source library presents a challenging case, unless some excludable complementary product can be offered. Only the dual-licensing strategy could vaguely be said to include coercion, if you believe enforcement of copyleft or copyright is coercive. And as I noted, that approach requires overcoming other market/sales/staying-power difficulties. If you have other ideas for turning a open-source library into a money-making non-coercive business, please share -- especially if they somehow work without excludability. I'm very interested in this topic.
    - inimino 18y ago
      I may have misread your post a bit, I was responding mainly to the dual-licensing suggestion (which read to me like a suggestion for getting around the right to fork; i.e. the "open source in name only" business model). Your points about service businesses are well-taken, though I think this is a hard and uncertain road to turning a profit. As for turning free software into a money-maker, I think not-for-profit is the stable state of a perfectly efficient software industry. That doesn't mean programmers couldn't be well paid, but it's likely nothing that would be terribly attractive to VC.

by cool-RR 18y ago

blender 18y ago

He said: "Because making something people want is so much harder than making money from it, you should leave business models for later, just as you'd leave some trivial but messy feature for version 2. In version 1, solve the core problem. And the core problem in a startup is how to create wealth (= how much people want something x the number who want it), not how to convert that wealth into money." Cheers

braindead_in 18y ago

Few obvious things which come to mind. 1) Dual licensing 2) Charge for commercial support 3) Sell hosted versions (might not apply to you) 4) Advertising?

huhtenberg 18y ago
#1 and #2 require substantial legal expense and a lot of subsequent sales and support management effort. And unless a founder has a prior experience building this kind of organizational infrastructure, it will be a very painful experience to go through. All in all, it's a project that is simply too risky for the investors to put their money into.

gojomo 18y ago

I think the subtext of that advice is that you're still making something that is eventually excludable/controllable, so you have options. For an open-source library, the right-to-fork and to use without paying licensing fees means many of the options used by other startups which defer revenue questions in favor of building an enthusiastic userbase are already off the table for you. You can't easily withhold your product unless fees are paid; you can't add advertising; you may not be in a position to sell excludable complementary offerings. You could try a dual-licensing structure like Sleepycat BerkeleyDB -- free for other open-source projects, pay if you want to use in a closed-source application. However, that presupposes a large closed-source commercial market for the software your library-users make, requires some capability for closing big corporate sales, and it may take years of proven library quality before becoming the solid/safe choice for companies to embed in their own products.

inimino 18y ago
"I think the subtext of that advice is that you're still making something that is eventually excludable/controllable" And the unstated assumption of that interpretation is that it is impossible to make money without coercion.
- gojomo 18y ago
  That's not a fair reading; I don't assume that coercion is necessary to make money (nor do I believe PG assumes that). Excludability ≠ coercion. An advertising-supported site can exclude non-payers from using their advertising inventory. Money is made without coercion (and free/open-source software might be provided as an audience generator). A consulting/services/support business can refuse to provide their service to non-clients. Money is made without coercion (and free/open-source software might be central to the delivery of services or expression of expertise). A paid-subscription website can exclude non-subscribers. Money is made without coercion (and free/open-source software might be provided as a complement to the paise service). The OP's proposal of angel-funding an open-source library presents a challenging case, unless some excludable complementary product can be offered. Only the dual-licensing strategy could vaguely be said to include coercion, if you believe enforcement of copyleft or copyright is coercive. And as I noted, that approach requires overcoming other market/sales/staying-power difficulties. If you have other ideas for turning a open-source library into a money-making non-coercive business, please share -- especially if they somehow work without excludability. I'm very interested in this topic.
  - inimino 18y ago
    I may have misread your post a bit, I was responding mainly to the dual-licensing suggestion (which read to me like a suggestion for getting around the right to fork; i.e. the "open source in name only" business model). Your points about service businesses are well-taken, though I think this is a hard and uncertain road to turning a profit. As for turning free software into a money-maker, I think not-for-profit is the stable state of a perfectly efficient software industry. That doesn't mean programmers couldn't be well paid, but it's likely nothing that would be terribly attractive to VC.