Subject: RE: Apache chairman: Days numbered for commercial software
From: Brian Behlendorf <brian@collab.net>
Date: Mon, 27 Mar 2006 12:00:15 -0800 (PST)

On Sat, 25 Mar 2006, Larry M. Augustin wrote:
> Greg Stein wrote:
>
>> I believe the key trend is around "licensing pressure". A push towards
>> less restrictive licenses.
>
> I think it depends on which side of the code you are on.  I actually see
> more tendency towards reciprocal licenses coming from commercial vendors
> releasing their code.  They tend to prefer more restrictive licenses as it
> limits the ability of their competitors to use their own code against them
> in a closed way.

I think we are seeing a clear bifurcation in reasons why a company decides 
to significantly fund Open Source software development, above and beyond 
the usual, like contributing bugfixes to already established projects.

Class 1: a loss leader/seeding strategy to establish brand and leads 
for a commercial upsell.  Here, ownership of the IP and of the process of 
development is important for dual-licensing and roadmap purposes, and the 
same brand is used for the open source and for-profit entity.  You don't 
want a significant number of core developers not on your payroll.

Class 2: a way to commoditize a particular segment by establishing a 
particular solution as The Standard through ubiquity.  Here, scale is 
important, both in usage and development - you *want* far more core 
contributors than exist on your payroll, an independent brand, perhaps an 
independent developer-driven organization that owns the IP, and multiple 
companies building businesses that incorporate that code and thus have 
reason to ensure its future.

I believe that software product segments will be "colonized" by Open 
Source projects of class 1, but that that over time they will be "settled" 
by projects of class 2.  In class 1, it is important to the funding 
company to *not* put much more than just the code out there - certainly 
not the core discussion lists where development takes place, also likely 
not any developer documentation.  You want end-user docs, and perhaps 
enough technical information to foster an add-ons community.  The last 
thing you want, though, are so many outside core developers that the 
threat of a fork is something you have to worry about - plus, you want 
people to see *you* as the source of all technical innovation in this 
segment, not just one of a bunch of companies whose chief differentiator 
becomes price.

My own intuition tells me that in the long run it is difficult to maintain 
this segment dominance against Class 2 competitors.  Class 2 projects tend 
to be much slower to take off unless there are dedicated developers on it 
from the start, but once momentum is achieved can grow more quickly than a 
more closed-managed project can.  It also is likely to arrive at 
architectures that can last longer, due to wider peer review before and 
during development.  It might also be the case that after a while, 
multiple Class 1 projects will compete in the same segment, spending 
resources on duplicated effort, with some of those defecting to a Class 2 
project in the same space as soon as it's viable.  It might also become a 
better home for proprietary vendors who missed the boat on the Class 1 
offering.  Is Solid, the database company, more likely to abandon its 
proprietary database in favor of MySQL, or put its efforts behind Postgres 
or Derby?

The end-users will play a role in this, too.  Right now I'm trying to help 
broker peace in a scenario where a Class 1 vendor's customer is trying to 
convince the Class 1 vendor to shift to a Class 2 model - to open up their 
development processes and documents and involve more outsiders in the 
project.  The Class 1 vendor, very reasonably, wonders what's left to 
compell contract renewals if they can so easily enable their competitors. 
This shift involves an uneasy calculus about whether the entire user 
community will grow if the project becomes Class 2, and thus represent 
more services opportunities - convincing them that a smaller size of a 
much bigger pie is a better thing.

Just as I feel, contrary to Greg's assertion, that we will always have 
proprietary software (no matter how it's distributed) we will also always 
have both Class 1 and Class 2 style open source projects.  But over 
time...

> Of course the view is reversed when using code; they look for software under
> a non-reciprocal license.  So we have an interesting dynamic developing:
> when using code, prefer a non-reciprocal license; when releasing code,
> prefer a reciprocal license.

Good analysis: now which are there more of, users or releasors?  Enough 
user demand to outweigh releasor preference?  :)

 	Brian