The (still simple) economics of decompilation after open source

Let me now consider the case in which one of the late comers follows an open source model of software development. Assume, in particular, that the first late-comer is an open source community, the goal if which is to achieve horizontally interoperability with the original system.142 _{If this is the case, the open source}

community supporting the project would face the usual trade-off, but the “expected revenues” of the new project would be evaluated in a peculiar way. A complete analysis of the incentive structure of open source developers is outside the scope of this paper, but some scholars143 _{isolated several possible explanations,}

including signaling incentives. More generally, the motives of open source developers are various and include: own use benefits, complementarity with proprietary products sold in the market, signaling, education, and social psychological motives such as altruism or simple enjoyment.144

In the context of the paper at hand, the relevant consequences of this different structure of incentives are that: (1) entry could occur in cases in which commercial firms would not enter (in fact, “difficult or almost desperate projects” or projects going “against a powerful incumbent” could be seen as a bad commercial enterprise by commercial software houses, but as wonderful occasions to show their talent from the point of view of open developers); moreover, (2) an open source project will publish its entire source code.

Notice that point (1) does not necessarily imply that “open source entry” would occur in many cases in which commercial firms would not dare to enter. In fact, one should notice that, normally, the incentives to produce open source software are actually lower (not higher) than the incentives to produce a commercial equivalent, since only some indirect revenues may be collected and the software is typically given away for free. Moreover, successful open source projects are frequently backed – or even directly subsidized – by commercial firms, so that their incentives may even be more similar to the ones of traditional software houses than one could expect. Finally, nothing prevents commercial firms from collecting revenues from the same sources (customization, training, etc.) from which open source developers derive their profit. Hence, there should not be excessive entry from FLOSS entrants. In any case – even if open source entry was more likely than commercial entry – no market failures would result, because of the different incentive structure of open source projects: if this structure of motivations fosters more innovation, commercial software houses should adopt it as well, and nothing prevents them from doing so (actually, they do with increasing frequency). (That having been said, I suggest downplaying the relevance of this point: there is no empirical evidence of excessively strong entry from open source firms.) To conclude about point (1), the fact that the first entrant may be an open source project should not be directly worrying in terms of reduced incentives to innovate.

It is point (2) that may be more relevant. It means that later-potential-entrants (i.e. new entrants from the second on) would have a much reduced “cost of reverse engineering”, because they could free-ride on the publicly disclosed results achieved by the first open source entrant. In principle, if the open source project achieved a perfect result, the cost of reverse engineering would drop to zero or almost for other-potential- entrants. But, please, notice that this is just a potential polar case: usually, reverse engineering would not be perfect. And, even if it was, the open source project would disclose a new implementation (although in a human-readable format) with comments and not a specification document. Moreover, notice that a re- implementation (from scratch, in terms of actual written code) should be performed in any case.

142 _{Notice that this is a polar case: cases in which just vertical interoperability is achieved would be qualitatively similar, but would}

have much more limited effects; also cases in which the open source functional cloner is not the first of the new entrants would be less problematic than this polar case, since the incumbent would have more time to recoup its investments.

143 _{See, in particular, JOSH LERNER & JEAN TIROLE, Some Simple Economics of Open Source, 50 The Journal of Industrial Economics,}

197--234 (2002).

144 _{STEPHEN M.MAURER & SUZANNE SCOTCHMER, Open Source Software: The New Intellectual Property Paradigm, NBER Working}

To summarize, the worst possible case (from the point of view of the first entrant and of the incentives to innovate) is one in which a perfectly horizontally interoperable project releases its source code, including a full-fledged set of comments providing information that is equivalent to the one an interface specification document would offer. Indeed, after such an open-source-entry, other late comers would see their reverse engineering cost drop to virtually zero (but would still have to bear the cost of re-implementation). Would this create a market failure? Surely, this would make a market failure more likely than in the standard case, however, it would still be far from certain.

A first argument concerns the – already mentioned – fact that the publication of source code, when existing, does not seem to generate the impossibility of staying in the market. In fact, open source projects may resist – sometimes even as market leaders145 _{– despite that fact that other firms may easily appropriate their ideas and}

understand the principles behind their pieces of software. Indeed, developing well-written software is both costly and difficult and it requires time. Moreover, no market failure would occur as long as:

(Cost of research) <= (gains from lead-time)

In fact, both the described case studies and the law & technology or law & economics literature suggest that several years may be needed in order to achieve a decent level of horizontal interoperability. The study of the most effective of previously mentioned projects, Wine (which is still unable to run in a usable way about 50% of Windows’ applications146_{), suggests that a couple of years are needed even to implement ordinary}

incremental innovations, while at least 3-5 years seems to be a reasonable (educated) guess regarding the lead- time of first comers, when major technological shifts are involved.

A lead time of a couple of years, extending to 3-5 for more significant innovations, may be more than sufficient to recoup the majority of investments in the field of software. At least, that is coherent with the suggestion of the “Manifesto concerning the legal protection of computer programs”, written by two leading lawyer-economists and two technologists in 1994:147

Markets have a kind of ‘basal metabolic rate’ that determines the length of product development cycles. For software, it is currently the one or two years required to create and to test a totally new product, or the roughly twelve to eighteen month interval required to develop and to test the new release of a preexisting product.

Notice that, the sui generis protection that these authors proposed for software (consisting in a kind of anti- cloning provision, limited in time, but balanced by disclosure obbligations) had a suggested duration of about three (or less) years.148 _{After this period, the proposed legal regime would guarantee a much broader access to}

the original source code than the one offered by reverse engineering. Moreover, also the possibility of reusing the original code, after the initial “artificial lead-time” offered by the sui generis protection was much more significant than the one offered by copyright (the proposed system was more similar to the special regime governing the reproduction of masks and topographies of semiconductors).

We may compare the sui generis protection recommended by the “Manifesto” with the protection technologically offered by secret, reinforced by the legal protection against literal copying of the implementation offered by copyright. Indeed, the latter is slightly longer and, what is more important, much more pervasive. That is true even in the most worrying case for incumbents, that is when the first late-comer

145 _{Such an example is the Apache web server: see http://en.wikipedia.org/wiki/Apache_HTTP_Server.}

146 _{This rough estimate is suggested by Wine’s developer Jeremy White (see WWN Interview Series: Jeremy White; available at}

http://www.winehq.org/?issue=347; last visited August 5, 2008) and it is based upon the users’ generated database of wine applications (http://appdb.winehq.org/). “If I look back on my time with Wine (about 10 years now), this is the most exciting Wine has ever been. When I first started, the only thing you could always run was Solitaire. Other things could be made to work, but it took a lot of effort. Contrast that with today when, with few exceptions, it’s reasonable to hope that any application will work. And, in practice, a substantial fraction of applications do install and run. (I don't know what that number is; I don’t have a good way to quantify it). The WineHQ ratings page suggests it's close to 75% run at least as bronze: http://appdb.winehq.org/browse_by_rating.php (I think that page over inflates things, but I think that 50% is not a bad rough estimate for applications that install and at least start to work).” (Ibid.)

147 _{See SAMUELSON, et al., A Manifesto, p.2408 in particular.}

148 _{See Id., p.2423 in particular. “We note that a number of countries have recently adopted or proposed short terms of protection}

(generally three years or less) for unregistered designs of industrial products. A concept of this sort might usefully be adopted for protecting program compilations, at least insofar as there is some minimal creativity in the compilation (that is, it does not consist entirely of standard or commonplace elements arranged in a standard or commonplace way). Anti-cloning protection of the sort we recommend for programs could be implemented by legislation or by common law.”

achieving interoperability follows an open source model of software development (and hence facilitates the work of later entrants through the disclosure of its own source code).