Subject: Re: Introduction
From: Rene Kienzle <rkienzle@bigpond.net.au>
Date: Sat, 23 Mar 2002 10:58:20 +1000


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

RBV is an abstraction. In some senses it is higher order theory that is 
based on many views and perspectives on the nature of the firm. In essence 
it is an excuse to look at the resources inside firms as a possible 
reason/cause/driver for firm success. Other approaches that attempt to 
explain firm success focus on market power, such as the positioning of 
products, as an explanation for firm success.

RBV really came about as an explanation for why firm differences 
(heterogeneity) exists and why some firms that appeared unsuccessful (based 
on more traditional accounting measures) remained in business.

The "nature of software" will necessarily have some bearing on the types of 
resources and competencies required by the firm/project to be successful. 
This is an important point to make when talking across industries. However 
if we are examining software development I would be more inclined to be 
concerned with issues of life-cycle - i.e. the stage of development of the 
software. I'm expecting to see differences in focus across the various 
major stages of software development. For example, projects heavily into 
development will be more likely to focus on growth to build programming 
resources, while others with a stable/mature software product might be more 
concerned with marketing issues. Again, it's a balancing act - exactly 
where the balance is, is difficult to guess.

>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,
>how?"

As I mentioned before the theory provides a framework for the analysis. The 
RBV provides a good reason for looking at what it is that people do in 
projects and believing that their actions in no small part contribute to 
the success or failure of the project. Because the RBV is focussed on 
success (more rightly sustainable competitive advantage), as all strategy 
theories are, the question needs to be asked - what resources are 
important? Which ones are "core" or "strategic" resources and why are they 
important? In the broader context (taking into account the projects 
environment) this is a question of fit - what is an appropriate mix of 
resources in a given situation - or alternately "How can we do this 
efficiently?"


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

Previous research provides some guidance about the possible range of 
competencies and resources that are associated with success. Some 
researchers talk about commonality factors that are associated with success 
- these are more general constructs like communication that are necessary 
components of almost all project activities. At a lower level of analysis 
particular aspects of communication might be important, such as openness of 
communication.

So previous theoretical propositions are important and necessary to theory 
building and theory testing and cannot be ignored. I have to make an 
assumption (hypothesis) in order to test it :) The academic literature is 
one side of the research fence. I have gone out and asked others what they 
believe to contribute to success - without me assuming anything for them. 
This more grounded approach highlights important factors that just happen 
to be mentioned in the research literature.

Yes I am going to look at projects as "a firm". Based on theories of the 
firm there is no reason to believe that they cannot fit within the 
assumptions of a resource-based view (which is based on more fundamental 
economic theories). Traditionally, research has focused on your 
stereotypical range of businesses but this doesn't mean that projects 
should be excluded from research using the RBV. I think it is necessary to 
extend the RBV to the arena of open source development in order to test 
whether it applies where alternate economies are apparently active.

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

Not sure about which boundaries you mean...

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

I think it is easier to apply the RBV to analysis of industry segments or 
in the more traditional setting where firms are competing with each other 
in similar products domains.

I am going to be looking at many open source projects that compete to vary 
degrees with other "closed source" and open source products. Rarely will 
their be any free software projects that directly compete (given the fear 
of forking). How competition can be measured is one of the current issues I 
have. Regardless projects will also be competing, to varying degrees, not 
only on the output side but also on the supply side - to gain programmers 
to work on their projects.

My thesis is really the first step into examining projects using the RBV. 
I'm hoping to make a small step in reducing noise at this stage and be more 
concerned with a finer grained understanding of competition at a later 
date. For now I will be happy with a higher order and noiser measure of how 
projects compete :)  At the very least at the end I should be able to make 
a clearer distinction between success and failure and outline a range of 
resource based reasons for why projects succeed or fail.

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

The biggest stumbling block I have found in discussion with other academics 
(in particular those that reluctantly let me take on my thesis topic) is 
the idea of competition. How can I be analysing projects that don't compete 
with each other - they are coopearting !? Competition is not all about 
competing. Competition requires cooperation and trust. The term coopetition 
(shudder) as been more prevalent in recent strategy literature. The action 
of markets requires a level of trust to ensure that transactions occur - 
without trust between firms the action of markets would be impossible. I 
think it's all a matter of how you cut up the market cake in your analyses 
of how firms are competing or cooperating etc.

Anyway, I digress. You bring in a couple of point - 1) FSB directors should 
be concerned with resources possessed by the entire group of collective 
differentiators, 2) The public good nature of free software is a challenge 
to the RBV.

With regard to point 1. Free software development has many network 
externalities. So yes, FSB directors should be concerned. more than perhaps 
in other markets/contexts with how they interact with other FSBs. However, 
an FSB director cannot simply expect to be able to copy these "shared 
resources" (whatever they are) and hope they work in their particular 
project. Resources are not simple. They are complex and difficult to 
measure, even though the measures of them are often simple because they are 
often proxy measures of their existence. Resources are generally seen as 
firm-specific assets that are valuable, rare, difficult for other firms to 
imitate and hard to substitute. So while FSBs might benefit from a range of 
positive network externalities and can "buy" these in as resources to use 
in the firm they still need to be able to create their own resources or 
strategic assets in order to successfully develop software. If the software 
they are developing is also unique or technically difficult then they also 
need to perhaps need to focus more on building their own unique resources 
that are rare, inimitable etc.

With regard to point 2 - yes it is a challenge but an interesting one 
because the public good nature really highlights how important, if at all, 
firm specific resources are to developing free software. If we remove, to a 
large extent, barriers to the action of markets (such as with the existence 
of intellectual property rights) then we will get a clearer focus on how 
resources with projects contribute to firm success. If we all share, to a 
greater or lesser extent, the same information and technology (approach the 
notion of perfect competition) then it really comes down to how well we 
manage projects. How well we convert resources in capabilities that allow 
us to develop software.

>(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
>debate?)

I think it does, but it might not be so easy to pick out. It could be more 
about the orientation of the project leaders and how they translate their 
bias towards one or the other in the culture and practices of the 
project/firm. You would need to establish that one or other distinguishing 
characteristic of either approach is a significant factor that explains 
firm success/failure.

>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)?

If you view it as a system I don't think it is schizophrenic. IF they 
require a firm specific technology to be successful (that is it's a 
strategic asset) then without it they would be unable to contribute back 
into the free software community through other community minded activities. 
However they need both - their own unique processes and also the community 
- which they appear to understand. A balancing act.

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


I don't really know where to comment here. I think I've commented enough 
already. Might leave that one for another time


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

I think this is really just a question of how you conceptualise "the firm". 
There are no real clear guidelines but a reasoned argument for why a 
particular set of activities (business functions) should be considered as 
one unit of analysis.

Rene