![[PukiWiki]](image/wadanyan.png "[PukiWiki]")
The main contribution of the paper is the study of the Apache HTTP Server community from the point of view of how contributions of non-core developers are accepted, and how that is related to the growth of the non-core developers number, and to the number of non-core contributions.
However, the analysis is performed only on one project, which is certainly not enough to draw general conclusions about how OSS projects in general behave.
The wording of the hypothesis "The condition of bazaar in a successful OSS community with a long history changes over time in evolving to adapt itself and its products to the rapidly changing external environment" is hard to understand. And since it is in the abstract and introduction, may lead to difficuties in the appreciation of the value of the paper. (by the way, probably "in evolving" should be "is evolving").
In fact, probably there are other ways of stating the main hypothesis of the paper. From my point of view, it is more related to how "openess" evolve ober time in a succesful project.
Page 2: "This implies thatbazaar-like software development might not be a critical success factor of OSS products and communities. If so, how could certain products and communities such as Linux and Apache achieve great success and survive in a free competitive market for more than a decade? Our study is motivated to answer this question." To me, it is not clear how the first sentence is related to the second. Probably more explanation about this should be included.
Developers have diffrent ids in CVS (CVS ids) and in mailing lists (email addresses). The authors should clarify how they relate both, which is critical for deciding (according to their definition in subsection 4.3) who are core developers.
The sentence "(3) the acceptability of contributions from core and non-core members (i.e., the rate of patches reviewed by other developers)." does not make it clear when a contribution is considered as accepted. When there is a reply to the message with the patch? (the next paragraph suggests this). When there is some positive acceptance of it? Something else? This should be clarified, since it is key to understand the results of the paper. In any case, it is not clear how replys to messages with patches show that those patches are accepted. The reply could say "I don't want this patch to be considered", for example.
The lists consideres should be detailed. From the context, probably it is "httpd-devel", but that should be detailed, to facilitate reproduction of results by other parties.
In fig. 2, the number of patches by non-core developers decreases after 2002. But the total number of patches decreases too. Therefore, maybe something happened around that date which cuased less number of patches sent to the project (maybe the release of the 2.0 version of Apache, which has a modular architecture?). This fact should be at least discussed, since could invalidate the support of the hypotesis.
The section on discussion goes too far. Many of the comments there cannot be derived from the data presented in the paper. Those comments are probably out of scope in this paper. On the contrary, I would expect that this section consdiers the possible problems of the methodology, and the validity of the results.
Apache is, as far as I know, using Jira, and not Bugzilla, since some time ago, for issue tracking.
�If the authors had of limited their conclusions to the culture of openness in the Apache project I would have fewer issues with the paper, however I must take issue with the sweeping generalizations made on the basis of examining one atypical FLOSS project. Furthermore the hypotheses posed in section 3.2 are unremarkable and do little to support the hypothesis outlined in section 1 (and the stated aim of the paper). The work is not without merit but the paper requires a significant rewrite and the research needs to be framed appropriately.
