Mik’s Review

Problem

This paper addresses the problems in large-scale software development by proposing that a well-modularized open source system provides a better economy than closed monolithic codebase. The authors argue that a good architecture opens up option value in the codebase in a way to provide developers with incentive that increases the supply of effort and mitigates free-riding.

The problem the paper addresses is becoming increasingly relevant as key software markets become comoditized (e.g. developer tools, browsers, messaging tools, operating systems, databases, and eventually productivity tools).

Contributions

Terrry and Lyndon provide a good list of contributions below. Some additional ones that I think are relevant:

• We usually focus on architectural issues for deciding how to modularize a system. This paper demonstrates that in order to leverage open source, focusing on the social dimension is key for deciding the granularity and composition of modules.
• An explanation of why prioprietary firms will find it more difficult to compete with open source development: “Assuming equals costs of development, the expected profit from a proprietary codebase that competes with a collectively developed codebase declines with the number of modules and the option value of the collectively developed codebase.” *There are oversimplifications made, but the key issues are addressed by their model and the things abstracted away do seem like details, so overall I find this analysis very convincing.

Weaknesses

• Open source is not necessarily about volunteers, but often about salaried individuals whose incentives line up on the project.
• Free riders on the code do provide utility to the organization as long as they have another mechanism for contributing, e.g. bug reports, mailing lists, blogs. They’re not addressed here, and the paper only considers one kind of “contributor”.
• Scaling is an issue: the more people are involve the harder the modules, and connections between the modules, become to change.

Questions

1. The people and organizations who contribute code to many modern open source projects are note volunteers (as was the case with Linux), but motivated or funded by rational capitalistic behaviour. Would looking at them this way provide additional insights to how companies should build around open source that “involuntary altruism” doesn’t?
2. Can the values of each module really be treated independently? When scaled to very large projects and teams, what happens to the combinatorial API and communication overhead? Don’t dependencies between modules and people become a critical part of the equation?

Terry’s Review

Problem

The success of an open source development depends greatly on its architecture. This paper shows that modularity in architecture motivates people in the open source community to contribute rather than free-load off other contributors.

Contributions

• Translates the complicated activities of open source development into 2 simple linked games that have easily defined rules. The first game correlates to implicit exchange of effort for each value and the option values of the codebase. It depends on the notion of software code being "non-rival" good and that developers' contribution are based on "involuntary altruism" meaning that each developer contributes positively to the other users of the software whether he/she meant to or not. The second game, also known as Prisoners’ Dilemma, correlate to the communication of contribution to the codebase. It justifies why a developer would communicate his/her contribution in spite of the cost of communication.
• Shows ways/formulae that can calculate or at least estimate ideal number of modules in a project size of a development community and cost/value per module. *Justifies the existence of open source projects, but also explains that the existence of corporation is needed.

Weaknesses

• It is unclear to me how the same logic of reasoning could apply to the real world. There seems to be many assumptions that might not hold true in the real world which are vital to the success of their theories (P. 22 - value of each module is independent of any other module's value; whole system's value equals sum of its module, P. 11 - each developer works on one and only one module at a time)
• Is the design rule "each module can be worked on separately, and they are incrementally value-additive" always achievable? It seems that there are changes to modules that make a system worse so that better changes could be done to it. In an open source project, is there incentive to take the first step?
• Who will start implementing the minimal system? What is the incentive for contributing to the minimal system?

Questions

• How difficult would the model and reasoning be if cost of each module is treated separately with the others (i.e. each module's cost is not directly proportional to the number of module that exists). What if each module is treated as a random variable?
• How does the introduction of users in an open source community that cannot contribute in terms of coding but can contribute in other ways like bug reports factor in the reasoning of this model?

Lyndon’s Review

Problem

Open source development has been around for many years and is a viable method of development. But the process is still not fully understood and there are still questions about how it functions and its interactions with commercial software development. This paper looks the effect of the codebase structure on the developer's contributions and well as the developer's effect on the codebase.

Contributions *Game theoretic analysis of codebase modularity with involuntary altruism.

• An analysis of the effect combining modularity and option values.
• The effects of modularity and options values on the competitiveness between open source and commercial development environments.

Weaknesses

• Lack of comparison of theoretical results to real world results.
• Game theory models over simplify some important assumptions.
• Robinson crusoe scenario does not seem to be a good alternative for comparison.

Questions

• How realistic are the assumptions used in the games?
• Although game theory has been used in various fields for a while, how applicable is it to analyzing design decisions and software engineering practices?

Belief

Considering the limitations of modelling software development processes, I thought the argument was convincing, in the context and framework set out in the paper. The conclusions about each game scenario come from the game payoffs are justified mathematically and they do consider various aspects of the development process and take them into account, such as the uncertain value of modules being completed, revealing code, imperfect information, etc.