A discussion of hybrid open source and proprietary licensing models.

[Marshall Van Alstyne <marshall AT MIT.EDU>]

Hi Onno, a few clarifying thoughts follow:

At 08:59 PM 9/17/2004, Onno Kluyt wrote:
> Couple of follow-ons inserted in the text below.
>
> Onno.
>
> > One subtlety, however, is that we feel the platform author should get an 
> > immediate option to offer a new innovation as part of their own work such 
> > that (i) the price is no higher than that charged by the 3rd party 
> > developer and (ii) the proceeds on that piece go to the 3rd party 
> > developer.  This encourages users to come to the platform author as the 
> > main supplier of all new pieces and it doesn't harm the innovation 
> > incentives because the developer gets the money anyway.
> I wonder whether this works in practice. For large scale projects, say 
> J2SE or J2EE, doesn't this become quite complex rather quickly?
> If you'd have one or two contributions from other developers then it may 
> work but does it scale?
> This is generally addressed in the JCP in different ways but seldom 
> (actually I don't know of a case) via proceeds sharing. The innovation is 
> offered to the original author either for free or for an upfront one-off 
> fee. The developer is then often further rewarded by public recognition 
> for the contribution by the original author.

Ah, you raise 2 points, one on integrating complexity and the other on 
proceeds sharing.

Actually, I agree that the add-ons become complex rather quickly.  This, 
however, is a key source of value provided by the integrator.  Who else is 
in a better position to achieve the integration?  It's also much more 
efficient to have the integrator (or someone) do this once than have lots 
of individual users repeat this step for themselves -- and this promotes 
adoption.

As to the proceeds sharing, this addresses the exact same problem that is 
always faced with a new innovation i.e. a market test of value.  There's a 
reason that governments don't just buy new patents then place the idea in 
the public domain.  No one really knows the value in advance of testing it 
in the market.  So, how do you set the price?  Answer: you let the market 
decide.  If the individual innovator sets too high a price, he doesn't make 
any money.

...

> > I'd argue that the issue is probably not to contractually *forbid* 
> > forking of any kind since this also has the potential to retard true 
> > innovation.  Rather it should be economically unattractive.  A truly 
> > innovative radical innovation may still offer enough value to make 
> > forking worthwhile, but then this is precisely when forks should occur.
> So, how do you make it economically unattractive?
> This seems hard to do when there is substantial disparity in financial 
> abilities between the original author and the party that is considering 
> the fork, and the disparity being to the disadvantage of the original 
> author. The GPL does seem to offer a defense strategy in this case because 
> of its viral affect on other products bundled or dependent upon it.
>
> Perhaps one needs to consider other strategies in addition to (or in 
> support of) whatever license one puts on the original work: ie fortify the 
> community against such actions via social and moral tools. The unwanted 
> forking activity may then be rejected by the market on other grounds, or 
> at least it could significantly increase the forker's costs in marketing 
> and other activities for it overcome the resistance to its actions.

You do raise a legit argument in the financial resources of a determined 
Forker i.e. someone who wants to do this for private reasons, not because 
it's good either for the technology or the community.  But for companies 
such as MS, this is always a potential problem.

Still the economics to prevent it can be quite strong.

We can make forking economically unattractive by using properties of 
bundling (which, BTW, is another reason to take the integration step 
suggested in the previous answer).

There are two good papers on this (one by Bakos & Brynjolfsson, the other 
by Nalebuff) but here's the key insight.  By bundling goods together, you 
can make it harder for a competitor to market into your installed 
base.  The reason is that your base probably already has your version of 
the component that your competitor is trying to get them to adopt, i.e. 
your version already came with the bundle, so they don't need another.

Nalebuff points out that when MS office first came on the market as a 
bundle, it wasn't best of breed in spreadsheet (Lotus was), word processing 
(honor went to WordPerfect), or presentation (honors to Persuasion)!  But 
you got the whole bundle cheaply.  Then if you bought it for the word 
processor, you didn't need to buy Lotus 'cause you already had Excel.  So 
even though Lotus had a lot of resources, it couldn't promote adoption 
against any user who got a word processor (and office bundle) or a 
presentation package (and office bundle).

MVA