Subject: Re: Introduction
From: Tom Lord <>
Date: Thu, 21 Mar 2002 22:59:30 -0800 (PST)

	Would this be an appropriate forum for this form of

Let's find out.

To be able to read your thesis summary, I had to google around for
some background material on RBV.  I was excited by what I saw.  I
sometimes write on this list and to various people about thinking in
terms of:

	1) software basis sets
	2) effective team structures (for strategic, tactical, and
	   custodial programming tasks)
	3) the relationship of those to repeatable growth

RBV seems to present a management-theoretic abstraction for
understanding why my position makes sense without having to delve too
far into "the nature of software".

       I'm a doing a PhD in the broad area of strategic management. In
       particular I am interested in the resource-based view

I'm trying to absorb your thesis summary quickly, so if I've horribly
misunderstood, please let me know.

It seems that you're looking at RBV analysis on the one hand, and the
organization and success factors of open source on the other, and then
asking "Does this open source activity fit the RBV model?  If so,

You say (in your summary):

	This thesis maintains that the resource-based view is indeed
	robust despite the requirement that it be re-examined before
	application to the Open Source context. It is being argued
	that the resource-based view presents a means by which firms
	may achieve success while the Open Source standard presents a
	new method.

and otherwise talk about applying RBV to open source practices.

       I am heavily focused on the survey at the moment so I am
       concerned with measurement, but I have questions about, for
       example, the nature of competition and issues of strategy.

Your data confuses me, though.  It looks to me like you're starting
with certain presumptions about what are likely "resources", and
perhaps as though you're going to think of open source projects as
occupying the position of "the firm" in RBV analysis (or perhaps as an
FSB firm as being a collection of such projects).  I think that's a
popular was to look at it but not the best way.

I wonder if you won't get more interesting results by drawing the
boundaries a little bit differently.

Does it make sense to apply RBV not only to a single corporate firm,
or to individual open source projects, but to collections of
sometimes-competing firms and projects that collectively form an
industry segment that competes with other industry segments?

For example, let's stipulate that the FSBs are collectively in the
underdog position.  Competitive differentiation from one another is,
at the moment, less important for each individual FSB corporation's
long term success than collective differentiation from monopolists
such as Microsoft and proprietary unix.  This need for collective
differntiation is further strengthened by recurring technical issues
inherent to software, such as the ability of the monopolist to define
de facto standards that introduce interoperability barriers to market
entry.  Another complicating factor is that the monopolists can count
among _their_ collective resources the license-oriented purchasing
practices of the customers.

Given that need for collective differentiation, is it rational
management behavior for FSB directors to think not simply in terms of
the resources they uniquely possess, but in terms of the resources
possessed by the entire FSB segment?  In other words, the public good
challenge to the RBV model might in part be explained if we assume
that the goods in question are collectively owned by the entire FSB
segment, and not generally available to the monopolists' segments.
(And if that's the case, does the RBV model have any contribution to
make to the Free Software (e.g. GPL) vs. Open Source licensing

There's an RBV implication of the customer purchasing practices
"owned" by the proprietary segment: FSBs have to bring competing
purchase practices to market.  Interestingly, individual FSBs
currently use that need as a point on which to achieve
corporation-specific resource advantages: Red Hat, for example, spends
a decent chunk of it's R&D budget not implenting open source software
that benefits the entire FSB segment, but rather on in-house software
that they alone possess and that implements new forms of revenue
stream for that company alone.  To the extent that strategy is
successful, it deprives their segment peers of revenue opportunities:
so from a narrow point of view, it seems like a good RBV play.  But if
the segment as a whole is in an underdog position, and if it makes
sense for members to contribute to software projects because it helps
to improve a walled-garden resource shared by the entire segment, then
isn't the company-specific revenue mechanism a kind of schizophrenic
strategy -- ultimately taking value away from the core resource (open
source software)?

Some years ago I was involved in some length discussions about
implementing revenue stream mechanisms for Free Software.  As I
recall, we talked about mechanisms that would have given customers
vendor-neutral channels.  To be more concrete, instead of subscribing
to a to a particular vendor's delivery mechanism, customers and
vendors would have standard, open end-points of an industry-wide FSB
delivery mechanism.  FSB's would then be competing for "bandwidth"
over that software/money channel.  That approach would seem to give
the entire FSB segment a purchasing practice resource that, especially
if linked to Free Software licensing practices, would be a "monopoly"
resource of the entire segment -- a far more symmetric competitor for
proprietary-license purchasing practices than current approaches.

Just in general, one hand there's "the firm" in RBV, on the other
hand, there's legal and accounting practices such as business units
and corporations.  When applying management theory, we may have to
make decisions using tools like RBV at multiple scales, including
scales which are larger than the boundaries of single corporations.
At that scale, the tension between RBV and the public goods problem of
open source might be resolved.

Or not :-)