5 ms·

> People have asked me what I think of the fact that other people can then also redistribute the source code, or compile a binary and provide that for free. I'm

> People have asked me what I think of the fact that other people can then also redistribute the source code, or compile a binary and provide that for free. I'm fine with that, as said, I'm a firm believer in open source / free software. What??? They’ve admitted to a flaw in their method to get income, which is that they’re making it trivial for competitors to offer the same product. Their response is that they’re a believer. I would have appreciated a response like dual licensing, or going into consulting for their app, or using trademark to enforce ownership over their version.

geoah 5y ago
Textual is a good example of this working IRL for me. Their app is one of the best IMO IRC clients on MacOS, is open source [1] and is also sold on the App store and their site. 1. https://github.com/Codeux-Software/Textual#original-limechat-license https://github.com/Codeux-Software/Textual#original-limechat... 2. https://www.codeux.com/textual https://www.codeux.com/textual
- vegetablepotpie 5y ago
  So in the case of Textual, it’s a convenience for the user to download from the App Store than to clone and compile and get through code signing. If I’m broke, have a MacBook, and know how to build and modify a project, I can get textual for free, which is a nice option to have. On platforms with app stores I can see this being viable for developers. I am aware of VLC being removed from the iOS App Store years ago because the license agreement for the App Store said that developers had to have sole control over the source code. I’m wondering if this requirement was removed, which would allow Textual to exist on the platform with its licensing. I can see licensing an open source project, for profit, as BSD being riskier than GPL because I could take their project, add my own additions, publish the product on the App Store (under a different name and branding) and never release the source code. At least with GPL, I would be required to share my modified versions of the source code with users of the product, which could be reintegrated into Textual.
- crazysim 5y ago
  Pixen was the opposite. It was open source and sold on the App Store but then people just took the code and put their own low effort Pixen-likes on the App Store. No more OSS Pixen.
R0b0t1 5y ago
The idea behind licensing as GPL is that you offer support, subscription, or relicensing. The problem I see is his target niche is crowded already, not that he's using GPL. Using AGPL would be better because you work around hosted services.
jlokier 5y ago
> What??? It makes sense if you see it as a hierarchy of priorities: First priority: Believe in making open source / free software where other people can exercise the associated freedoms. Second priority: Want to make income, it's difficult or impossible, but whatever methods are searched for to overcome those difficulties, the income goal is still secondary to the first priority. Dual licensing and trademark might both be rejected on that basis. Consulting would be fine.
- vegetablepotpie 5y ago
  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" ;)

geoah 5y ago

Textual is a good example of this working IRL for me. Their app is one of the best IMO IRC clients on MacOS, is open source [1] and is also sold on the App store and their site. 1. https://github.com/Codeux-Software/Textual#original-limechat-license https://github.com/Codeux-Software/Textual#original-limechat... 2. https://www.codeux.com/textual https://www.codeux.com/textual

vegetablepotpie 5y ago
So in the case of Textual, it’s a convenience for the user to download from the App Store than to clone and compile and get through code signing. If I’m broke, have a MacBook, and know how to build and modify a project, I can get textual for free, which is a nice option to have. On platforms with app stores I can see this being viable for developers. I am aware of VLC being removed from the iOS App Store years ago because the license agreement for the App Store said that developers had to have sole control over the source code. I’m wondering if this requirement was removed, which would allow Textual to exist on the platform with its licensing. I can see licensing an open source project, for profit, as BSD being riskier than GPL because I could take their project, add my own additions, publish the product on the App Store (under a different name and branding) and never release the source code. At least with GPL, I would be required to share my modified versions of the source code with users of the product, which could be reintegrated into Textual.
crazysim 5y ago
Pixen was the opposite. It was open source and sold on the App Store but then people just took the code and put their own low effort Pixen-likes on the App Store. No more OSS Pixen.

R0b0t1 5y ago

The idea behind licensing as GPL is that you offer support, subscription, or relicensing. The problem I see is his target niche is crowded already, not that he's using GPL. Using AGPL would be better because you work around hosted services.

jlokier 5y ago

> What??? It makes sense if you see it as a hierarchy of priorities: First priority: Believe in making open source / free software where other people can exercise the associated freedoms. Second priority: Want to make income, it's difficult or impossible, but whatever methods are searched for to overcome those difficulties, the income goal is still secondary to the first priority. Dual licensing and trademark might both be rejected on that basis. Consulting would be fine.

vegetablepotpie 5y ago
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" ;)