您在這裡

Michael Feldstein - November 11th, 2007 at 12:25 pm

15 一月, 2016 - 09:28
Available under Creative Commons-ShareAlike 4.0 International License. Download for free at http://cnx.org/contents/f6522dce-7e2b-47ac-8c82-8e2b72973784@7.2

Ken, on the first question, I don't think that Benkler's analysis is detailed enough to provide clear and concrete decision-making guidelines to practitioners; nor do I think that Benkler would claim otherwise. However, it does provide some general direction and guidance for investigation.

    Which brings me to your second question. There are two elements to the frame that Benkler provides. The first is measure of “success.” Benkler doesn't provide us with an explicit measure, in part because his point is that when transaction costs are low enough people with more diverse motivations will enter the game. But implicitly, the measure here is the same measure that is applied to markets and firms in economic analysis, i.e., how much value in terms of new and better product can be unlocked at the lowest cost for the producers? So if we're thinking about educational software, for example, one important test on this model would be the proliferation of high-quality educational software on the market, regardless of whether it is open or proprietary. Benkler thinks that network-based production will bring along all kinds of other civic values and will ultimately win out over more traditional means in many cases, but I don't think you can dismiss the big economic picture from his framework for the purpose of the question that you asked.

    The second element of Benkler's frame is cost. What is the cost of each license style to potential producers of open source code? This turns out to be a very community-specific question. Consider the following examples:

    A proprietary vendor wants to contribute code to an open source project. However, in order to do so under a FOSS license, the vendor has to firewall FOSS developers in order to prevent inadvertent contamination of the company's proprietary code with ideas that the developers gained from working with the FOSS code. This is a cost that may prevent the proprietary company from contributing code.

    A small development shop (or individual) is contributing for idealistic reasons and as a means of earning a living via consulting. Under an OSS license, a proprietary competitor could take their contributions and resell it, which may be costly both in terms of ideological commitments and real economic benefits to the contributor.

    If your goal is to achieve success for a (F)OSS project by lowering transaction costs, you can't do that without answering the question, “Costs for whom?” From this perspective, the right license is the one that, on balance, leads to lowering of the specific transaction costs for the particular participants that have the largest positive impact on the project's progress. It's what the utilitarians would call “felicific calculus”.