4 ms·

> 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 come

> 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

> 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.