Published Research Papers

THE SOCIAL STRUCTURE OF FREE AND OPEN SOURCE SOFTWARE DEVELOPMENT
Kevin Crowston and James Howison
School of Information Studies, Syracuse University
{crowston,jhowison}@syr.edu

Summary

What do we really know about the communication patterns of FLOSS projects? How generalizable are the projects that have been studied? Is there consistency across FLOSS projects?

These are the questions this paper responds to. Questioning the assumption of distinctiveness is important because practitioner-advocates from within the FLOSS community rely on features of social structure to describe and account for some of the advantages of FLOSS production.

To address these questions, this study examined 120 project teams from SourceForge, representing a wide range of FLOSS project types, for their communications centralization as revealed in the interactions in the bug tracking system. It was found that FLOSS development teams vary widely in their communications centralization, from projects completely centered on one developer to projects that are highly decentralized and exhibit a distributed pattern of conversation between developers and active users.

And therefore, it was suggested that it is wrong to assume that FLOSS projects are distinguished by a particular social structure merely because they are FLOSS. Our findings suggest that FLOSS projects might have to work hard to achieve the expected development advantages which have been assumed to flow from “going open.” In addition, the variation in communications structure across projects means that communications centralization is useful for comparisons between FLOSS teams. The social structure of Free and Open Source software development 2 found that larger FLOSS teams tend to have more decentralized communication patterns, a finding that suggests interesting avenues for further research examining, for example, the relationship between communications structure and code modularity.

Evaluation

The topic being raised is really interesting (since I can relate to it better than the other researches I found). At its conclusion it really did prove the points raised but the downside for me in this study is its methodology. Though indeed the results are gathered with evidence or supporting data this paper mostly is done by researching topics directly and indirectly related to it. The methodology only consists of gathering data and queueing them up and no other strategies were done (as I see it). As Kate quoted it, "The paper was more of a historical type of research rather than a technical research because they did not perform any experimentation and relied majorly on their literature."

With regards to the format, there were only two major parts: related literature and conclusion. The other parts of a “standard” paper were indeed missing and thus it can e understood that the conclusion and recommendation was drawn from the literature review.

However, I think this research still is effective since it provided sufficient data/ literature to support the study.


----------------------------------------------------

OPEN SOURCE SOFTWARE: THE USE OF OPEN SOURCE GIS STANDARD AND ITS IMPACT ON ORGANIZATION
by: Mahmoud Refaat Nasr

Summary

This thesis explores the reasons behind the poor level of adoption of open source web GIS software, and whether it is due to poor awareness about open source concepts or due to technical deficiencies in the open source tools. The research was done in 2 major phases; the first phase involved conducting surveys to measure the awareness and attitudes towards open source. The surveys examined three categories of people involved in the IT industry, namely: decision makers, software developers, and end users. The measurement of awareness was done by developing an Awareness Indicator and a Sentiment Indicator for each category. These indicators were developed by the author during the course of the study in order to provide a measurable and descriptive indication of the results. The second phase involved performing a comparative analysis between MapServer a leading open source web GIS tool, and three of the leading proprietary web GIS software, namely: ESRI’s ArcIMS, Intergraph’s GeoMedia WebMap, and MapInfo’s MapXtreme. The results of the research provide an insight on how different categories of people view open source, and demonstrate that lack of awareness about open source concepts and its competencies may be a major reason behind the poor adoption of open source solutions. The results of the comparative analysis also demonstrate that MapServer is technically equivalent to its commercial counter parts.


Evaluation

All I can say is that this is a very good research paper. Maybe its because I'm still inexperienced in judging the research work but I can't find I fault or major ones anyway in this paper. Upon reading this paper, you can see how detailed the framework is, how in depth the research has gone and the structure of the paper is complete and done nicely. Researching histories and related topics were complete with regards to the points the researcher raised in his objectives and also survey done in terms of testing the hypothesis of the study was also shown and detailed in the paper.

Though the survey done was fine as a suggestion, it would be better if he added observation and interview of organizations who were already using open source GIS standards as to support his survey findings. Format wise its done throughly and
But overall, its a pretty much detailed and good research paper.


-------------------------------------------

COORDINATION OF FREE/LIBRE OPEN SOURCE SOFTWARE DEVELOPMENT
Kevin Crowston, Kangning Wei, Qing Li,
U. Yeliz Eseryel, and James Howison

Summary

The apparent success of free/libre open source software (FLOSS) development projects such as Linux, Apache, and many others has raised the question, what lessons from FLOSS development can be transferred to mainstream software development? In this paper, they used the coordination theory to analyze coordination mechanisms in FLOSS development and compare our analysis with existing literature on coordination in proprietary software development. The researchers examined developer interaction data from three active and successful FLOSS projects and used content analysis to identify the coordination mechanisms used by the participants. The researchers found that there were similarities between the FLOSS groups and the reported practices of the proprietary project in the coordination mechanisms used to manage task-task dependencies. However, it found clear differences in the coordination mechanisms used to manage task-actor dependencies. While published descriptions of proprietary software development involved an elaborate system to locate the developer who owned the relevant piece of code, The researchers found that “self-assignment” was the most common mechanism across three FLOSS projects.

This coordination mechanism is consistent with expectations for distributed and largely volunteer teams. We conclude by discussing whether these emergent practices can be usefully transferred to mainstream practice and indicating directions for future research.

Evaluation

Honestly, reading these research papers was easy but understanding them is a hard so most of the time I just skim through a whole section and judge it by its format and methodology. As I have observed, the drawbacks of the paper is just like the first paper I commented on. Though indeed the results are gathered with evidence or supporting data this paper mostly is done by researching topics directly and indirectly related to it. The methodology only consists of gathering data and queueing them up and no other strategies were done (as I see it). As Kate quoted it, "The paper was more of a historical type of research rather than a technical research because they did not perform any experimentation and relied majorly on their literature."

With regards to the format, there were only two major parts: related literature and conclusion. The other parts of a “standard” paper were indeed missing and thus it can e understood that the conclusion and recommendation was drawn from the literature review.

As a suggestion, using other data collection techniques to combine with the data or literature collected would be better.