David Elliott dfe@tgwbd.org wrote:
but I have yet to see a successful mode that has no propriatary component.
At the moment, this is true. Most of the open source companies have at least some proprietary software built on top of an open source foundation.
[snip]
I think that in fact it will become much more viable. The key is that in order to make this model work you need to be selling to a market that is unable or unwilling to provide their own support. As mentioned before, Red Hat may not be doing great, but if you take into account that they have a very small viable market (that is, the people actually willing to pay for support) then they are doing pretty damn well.
don't know about that. Considering their cost of goods conceptually is zero... As for support, I don't see it ever being a panacea for the industry. Various models for support have already been tried by commerical companies with varying levels of success. However, there's a really bad side to this model, as it puts the economic incentive on generating support calls - which means that there is LESS incentive for fixing bugs (even in site support, you're less apt to buy it if the program is trouble free).
It is these sorts of people and companies that we want to target. And financially Patrik's money for his license or even the money form all the wine developers would be nearly insignificant compared to a 100+ seat site license.
uh, how can you sell a N-seat site license with something that is covered by *GPL (since this would be a violation of the license)? If your model is to sell by seat, I would like you see the reasoning between the difference of a 10 seat license and a 100 seat license with the *GPL.
If you are selling support then you can most definitely sell per-seat.
If that what they are doing (Selling a support contract for N seats). Hard to tell by the wording.
You cannot expect to sell a free product without some sort of value added. That value can be a proprietary component or can be support for free components or can be other stuff that no-one as yet thought of. If your business model is to sell only what your customers can get for free then you are really, really, really, stupid.
no argument here.
As I said before, if a copyleft is all that is needed, choose a copyleft that makes SENSE. LGPL may be convienient, but I have seen no rational argument in having the *GPL's brand of copyleft (other than it's widely used). I think the mozilla project would be a good place to look...
This is a very valid argument. Although realize that they are now MPL/LGPL/GPL triple licensed. And the only reason I could see for having the MPL in there was so Netscape can take the code and release closed-source versions.
maybe so, but I think that LGPL/GPL was ADDED because mozilla touched too many things under those licenses. MPL has a 1 year grace period, plus its copyleft is not nearly as viral. I'm not saying it's perfect, but is a good place to start.
This doesn't really work well for Wine as the codebase is not owned\ by a single entity.
well, that benefit wouldn't be realized, but there is more to the license.
If you have a copyleft license that you feel would make more sense for Wine than the LGPL, please discuss it with us.
There's a gazillion licenses. Haven't seen any concensus on what the license should have (just what it SHOULDN'T have). Would think anything FSF considers a weak copyleft would be something to look at IF you want a copyleft. Wonder if Gav has any opinions on a copyleft license...
-r
-r
On 2002.02.16 18:58 Roger Fujii wrote: [SNIP]
don't know about that. Considering their cost of goods conceptually is zero... As for support, I don't see it ever being a panacea for the industry. Various models for support have already been tried by commerical companies with varying levels of success. However, there's a really bad side to this model, as it puts the economic incentive on generating support calls - which means that there is LESS incentive for fixing bugs (even in site support, you're less apt to buy it if the program is trouble free).
Actually, there would be an economic incentive to NOT have support calls. Support calls cost money. If people don't call you with support calls that are clearly your fault (i.e. a bug) then you make more money. Of course you're right, there still is incentive to want people to at least pay for support which you can hope they'd be more willing to do if you give them some reason to do so. Introducing bugs for this purpose would surely backfire as you'd get more calls than you could afford to pay for.
-Dave
David Elliott wrote:
On 2002.02.16 18:58 Roger Fujii wrote: [SNIP]
don't know about that. Considering their cost of goods conceptually is zero... As for support, I don't see it ever being a panacea for the industry. Various models for support have already been tried by commerical companies with varying levels of success. However, there's a really bad side to this model, as it puts the economic incentive on generating support calls - which means that there is LESS incentive for fixing bugs (even in site support, you're less apt to buy it if the program is trouble free).
Actually, there would be an economic incentive to NOT have support calls. Support calls cost money. If people don't call you with support calls that are clearly your fault (i.e. a bug) then you make more money.
This only hold true for a productized model, where you pay for something in advance. If you pay for product, then support for it usually subtracts from the profit and it is a cost of doing business. This does have the economic incentive in the "right" place because you want to minimize the number of support calls (though it hasn't stopped companies like M$ who has monopoly powers). However, in a PURE support model (ie, not one based on making money up front by a sale and must have a revenue stream all its own), you basically have 2 choices: 1) Charge by the incident 2) Offer site support
With #1, support calls MAKE money. If you have a problem-free product, it subracts from #2 (and #1 for the matter). In either case, the incentive is in the "wrong" place because your revenue stream is going to depend on people having problems...
Of course you're right, there still is incentive to want people to at least pay for support which you can hope they'd be more willing to do if you give them some reason to do so. Introducing bugs for this purpose would surely backfire as you'd get more calls than you could afford to pay for.
I wasn't implying that people would sabotage products. I was only trying to point out that the much hearlded support model for open source projects is not nearly as good as people make it out to be.
-r
-
David Elliott -
Roger Fujii