3 ms·

That makes sense, but it’s not a complete answer because to accomplish priority #2 the author has to go through additional work, such as applying for a business

That makes sense, but it’s not a complete answer because to accomplish priority #2 the author has to go through additional work, such as applying for a business license, getting a domain name for their business, getting a pre-paid cell phone, and having their home address listed publicly. This risks receiving business solicitations at his home address. If you have the first priority, why go through the trouble of the second priority? What I’d like to see is a plausible theory of monetization that accounts for the possibility of competitors redistributing his code. There may be one, but I don’t see it.

dalke 5y ago
As someone who tried the same approach, I think I can help. I sold software to pharmaceutical R&D groups. As a supporter and author of free and open source software, I wanted to see if I could apply the ideas from "Selling Free Software". Pharma companies are tight-lipped. Researchers often have to submit their talks for legal review before presenting it in public. I've hear that developers at some pharmas also need to submit patches for legal review before sending them upstream. Few pharmas distribute in-house software, which 1) they consider it a proprietary advantage over their competitors, and 2) like most in-house software, has a low level of documentation and testing, with the expectation that the authors and maintainers are directly available. Pharma companies also have the money to pay for software, and internal developers who are able to do some maintenance if needed. Finally, about 15 years ago, a company in my field decided to triple the price of its software (the owner was no longer really interested in producing software). This was deeply embedded in many projects. It took one company about 2 years to migrate to a competitor. So the owner made 6 years of revenue in two ... and made pharmas a bit more cautious about their licensing. This strategy isn't possible with FOSS licenses, which I think would make an advantage in sales. (This is not specific to FOSS licenses. My current proprietary licenses also allow in-house support, no time limit, no limit on the number of CPUs, and no restrictions on where those machines are located.) So my "theory of monetization" is that 500 pharmas and biotechs were willing to pay $25K for a top-of-the-line niche product which took about $300K of engineering time, and that I would get 50 or so customers before the source would be distributed to possible competitors. 50*25000 = $1.25M > $300K. Plus, it would take time (and money) for possible competitors to get up to speed with understanding how the product works. And they also couldn't make much money from it as I could always lower my prices, once I made back the engineering costs. Things I didn't factor in were: 1) I'm lousy at marketing (never got 50 customers) 2) Commercial vendors entered this space, with independently developed products (driving down the sales price) 3) People don't want to buy a $25K product without being able to demo it, and if I insist on only FOSS distributions (or components I use require it), I can't provide evaluation-use-only licenses. 4) Academics are an important user base as they publish papers (advertising) and their students go on to work at pharmas. My theory of monetization meant I couldn't sell to them as they expect no-cost or highly-discounted licenses, while being the most likely to put a FOSS component. As a result, I gave up, and now offer various levels of proprietary licenses for the source distribution, plus pre-built binaries for general base use, and a license key to unlock additional features. Yup, I've become a "software hoarder" ;)

dalke 5y ago

As someone who tried the same approach, I think I can help. I sold software to pharmaceutical R&D groups. As a supporter and author of free and open source software, I wanted to see if I could apply the ideas from "Selling Free Software". Pharma companies are tight-lipped. Researchers often have to submit their talks for legal review before presenting it in public. I've hear that developers at some pharmas also need to submit patches for legal review before sending them upstream. Few pharmas distribute in-house software, which 1) they consider it a proprietary advantage over their competitors, and 2) like most in-house software, has a low level of documentation and testing, with the expectation that the authors and maintainers are directly available. Pharma companies also have the money to pay for software, and internal developers who are able to do some maintenance if needed. Finally, about 15 years ago, a company in my field decided to triple the price of its software (the owner was no longer really interested in producing software). This was deeply embedded in many projects. It took one company about 2 years to migrate to a competitor. So the owner made 6 years of revenue in two ... and made pharmas a bit more cautious about their licensing. This strategy isn't possible with FOSS licenses, which I think would make an advantage in sales. (This is not specific to FOSS licenses. My current proprietary licenses also allow in-house support, no time limit, no limit on the number of CPUs, and no restrictions on where those machines are located.) So my "theory of monetization" is that 500 pharmas and biotechs were willing to pay $25K for a top-of-the-line niche product which took about $300K of engineering time, and that I would get 50 or so customers before the source would be distributed to possible competitors. 50*25000 = $1.25M > $300K. Plus, it would take time (and money) for possible competitors to get up to speed with understanding how the product works. And they also couldn't make much money from it as I could always lower my prices, once I made back the engineering costs. Things I didn't factor in were: 1) I'm lousy at marketing (never got 50 customers) 2) Commercial vendors entered this space, with independently developed products (driving down the sales price) 3) People don't want to buy a $25K product without being able to demo it, and if I insist on only FOSS distributions (or components I use require it), I can't provide evaluation-use-only licenses. 4) Academics are an important user base as they publish papers (advertising) and their students go on to work at pharmas. My theory of monetization meant I couldn't sell to them as they expect no-cost or highly-discounted licenses, while being the most likely to put a FOSS component. As a result, I gave up, and now offer various levels of proprietary licenses for the source distribution, plus pre-built binaries for general base use, and a license key to unlock additional features. Yup, I've become a "software hoarder" ;)