4 ms·

You can definitely sell extra warranties, support, or both for open software. I've helped a few clients do all those things, and published free form contracts o

You can definitely sell extra warranties, support, or both for open software. I've helped a few clients do all those things, and published free form contracts online. However, contracting for warranties or support does not have the same incentive-alignment effect as offering them within a broader license deal. A few thoughts come to mind: - The one selling the warranties or the support needn't be the developer. Even if the developer does offer those things, others can step in and compete. The outsiders' costs may in fact be lower. They're not also spending on gratis software development, for one. - Speaking of money, customers will usually pay a lot less for warranties or support than for use of software, or use of software along with warranties and support. That means fewer resources flowing back to the develop to invest in quality, security, IP hygiene, and the other drivers of risk driving demand for warranties and support. - Offering support in isolation can produce a perverse incentive: invest too much in usability, bug hunting, architecture, and so on, and suddenly customers don't need paid support. Fundamentally, warranties and support are for when things go wrong. Training and consulting have a similar potential conflict with open documentation.

monocasa 4y ago
> The one selling the warranties or the support needn't be the developer. Even if the developer does offer those things, others can step in and compete. The outsiders' costs may in fact be lower. They're not also spending on gratis software development, for one. A healthy market for support is good for the user. > Speaking of money, customers will usually pay a lot less for warranties or support than for use of software, or use of software along with warranties and support. That means fewer resources flowing back to the develop to invest in quality, security, IP hygiene, and the other drivers of risk driving demand for warranties and support. Definitely not true from my experience in supported B2B software. Most of the time nearly all of the real money is in the support contract. The license purchase normally only covers cogs and R&D. > Offering support in isolation can produce a perverse incentive: invest too much in usability, bug hunting, architecture, and so on, and suddenly customers don't need paid support. Fundamentally, warranties and support are for when things go wrong. Training and consulting have a similar potential conflict with open documentation. Equally true of proprietary software given the above calculus of how support is where the real money is. That's why you see little cottage industries of people who know crappy software, proprietary or FOSS. See the scene around maintaining Oracle DBs where uptime and throufhput seems to be measured in credit score.
- kemitchell 4y ago
  > A healthy market for support is good for the user. I'd be careful defining user welfare so narrowly, aspect-by-aspect, in isolation. Alas, it sometimes comes to pass that A develops and releases a valuable project but B steps in, beating A out to offer support. That diverts resources from A to B. A's work lags and bugs languish, which perversely drives demand for more support. I have seen B starve A out, then step in to fix bugs and add features...to a proprietary fork, available only to customers of B. All the while, B may in fact be far less familiar with or competent on the project than A, the initial developer. > Most of the time nearly all of the real money is in the support contract. I've seen deals structured this way. And I've seen the opposite. Frankly, there's often no rigorous allocation of dollars across software, support, and other buckets, just a deal between the parties about who gets how much when. The rest is just "structuring". In some cases, driven as much by accounting as anything else.
  - monocasa 4y ago
    > I'd be careful defining user welfare so narrowly, aspect-by-aspect, in isolation. > Alas, it sometimes comes to pass that A develops and releases a valuable project but B steps in, beating A out to offer support. That diverts resources from A to B. A's work lags and bugs languish, which perversely drives demand for more support. I have seen B starve A out, then step in to fix bugs and add features...to a proprietary fork, available only to customers of B. All the while, B may in fact be far less familiar with or competent on the project than A, the initial developer. As I said in the part of my response that you failed to quote that's equally true of proprietary software. And the fact that someone can make a private proprietary fork with some FOSS licenses being a point in favor of a software product being completely proprietary seems absurd on its face. > I've seen deals structured this way. And I've seen the opposite. Frankly, there's often no rigorous allocation of dollars across software, support, and other buckets, just a deal between the parties about who gets how much when. The rest is just "structuring". In some cases, driven as much by accounting as anything else. What's pretty universal once you distill down the accounting trickery is that deals require support contracts to make money. I have never seen someone making hand over fist for as-is software with no obligations, proprietary or FOSS.

monocasa 4y ago

> The one selling the warranties or the support needn't be the developer. Even if the developer does offer those things, others can step in and compete. The outsiders' costs may in fact be lower. They're not also spending on gratis software development, for one. A healthy market for support is good for the user. > Speaking of money, customers will usually pay a lot less for warranties or support than for use of software, or use of software along with warranties and support. That means fewer resources flowing back to the develop to invest in quality, security, IP hygiene, and the other drivers of risk driving demand for warranties and support. Definitely not true from my experience in supported B2B software. Most of the time nearly all of the real money is in the support contract. The license purchase normally only covers cogs and R&D. > Offering support in isolation can produce a perverse incentive: invest too much in usability, bug hunting, architecture, and so on, and suddenly customers don't need paid support. Fundamentally, warranties and support are for when things go wrong. Training and consulting have a similar potential conflict with open documentation. Equally true of proprietary software given the above calculus of how support is where the real money is. That's why you see little cottage industries of people who know crappy software, proprietary or FOSS. See the scene around maintaining Oracle DBs where uptime and throufhput seems to be measured in credit score.

kemitchell 4y ago
> A healthy market for support is good for the user. I'd be careful defining user welfare so narrowly, aspect-by-aspect, in isolation. Alas, it sometimes comes to pass that A develops and releases a valuable project but B steps in, beating A out to offer support. That diverts resources from A to B. A's work lags and bugs languish, which perversely drives demand for more support. I have seen B starve A out, then step in to fix bugs and add features...to a proprietary fork, available only to customers of B. All the while, B may in fact be far less familiar with or competent on the project than A, the initial developer. > Most of the time nearly all of the real money is in the support contract. I've seen deals structured this way. And I've seen the opposite. Frankly, there's often no rigorous allocation of dollars across software, support, and other buckets, just a deal between the parties about who gets how much when. The rest is just "structuring". In some cases, driven as much by accounting as anything else.
- monocasa 4y ago
  > I'd be careful defining user welfare so narrowly, aspect-by-aspect, in isolation. > Alas, it sometimes comes to pass that A develops and releases a valuable project but B steps in, beating A out to offer support. That diverts resources from A to B. A's work lags and bugs languish, which perversely drives demand for more support. I have seen B starve A out, then step in to fix bugs and add features...to a proprietary fork, available only to customers of B. All the while, B may in fact be far less familiar with or competent on the project than A, the initial developer. As I said in the part of my response that you failed to quote that's equally true of proprietary software. And the fact that someone can make a private proprietary fork with some FOSS licenses being a point in favor of a software product being completely proprietary seems absurd on its face. > I've seen deals structured this way. And I've seen the opposite. Frankly, there's often no rigorous allocation of dollars across software, support, and other buckets, just a deal between the parties about who gets how much when. The rest is just "structuring". In some cases, driven as much by accounting as anything else. What's pretty universal once you distill down the accounting trickery is that deals require support contracts to make money. I have never seen someone making hand over fist for as-is software with no obligations, proprietary or FOSS.