Essays on Exploitation and Exploration in Software Development
1 online resource (321 pages) : PDF
University of North Carolina at Charlotte
Software development includes two types of activities: software improvement activities by correcting faults and software enhancement activities by adding new features. Based on organizational theory, we propose that these activities can be classified as implementation-oriented (exploitation) and innovation-oriented (exploration). In the context of open source software (OSS) development, developing a patch would be an example of an exploitation activity. Requesting a new software feature would be an example of an exploration activity. This dissertation consists of three essays which examine exploitation and exploration in software development.The first essay analyzes software patch development (exploitation) in the context of software vulnerabilities which could be exploited by hackers. There is a need for software vendors to make software patches available in a timely manner for vulnerabilities in their products. We develop a survival analysis model of the patch release behavior of software vendors based on a cost-based framework of software vendors. We test this model using a data set compiled from the National Vulnerability Database (NVD), United States Computer Emergency Readiness Team (US-CERT), and vendor web sites. Our results indicate that vulnerabilities with high confidentiality impact or high integrity impact are patched faster than vulnerabilities with high availability impact. Interesting differences in the patch release behavior of software vendors based on software type (new release vs. update) and type of vendor (open source vs. proprietary) are found.The second essay studies exploitation and exploration in the content of OSS development. We empirically examine the differences between exploitation (patch development) and exploration (feature request) networks of developers in OSS projects in terms of their social network structure, using a data set collected from the SourceForge database. We identify a new category of developers (ambidextrous developers) in OSS projects who contribute to patch development as well as feature request activities. Our results indicate that a patch development network has greater internal cohesion and network centrality than a feature request network. In contrast, a feature request network has greater external connectivity than a patch development network.The third essay explores ambidexterity and ambidextrous developers in the context of OSS project performance. Recent research on OSS development has studied the social network structure of software developers as a determinant of project success. However, this stream of research has focused on the project level, and has not recognized the fact that software projects could consist of different types of activities, each of which could require different types of expertise and network structures. We develop a theoretical construct for ambidexterity based on the concept of ambidextrous developers. We empirically illustrate the effects of ambidexterity and network characteristics on OSS project performance. Our results indicate that a moderate level of ambidexterity, external cohesion, and technological diversity are desirable for project success. Project success is also positively related to internal cohesion and network centrality. We illustrate the roles of ambidextrous developers on project performance and their differences compared to other developers.
AMBIDEXTERITYEXPLOITATIONEXPLORATIONSECURITYSOCIAL NETWORK ANALYSISSOFTWARE DEVELOPMENT
Subramaniam, ChandrasekarPark, SungjuneSaydam, CemBishwal, Jaya
Thesis (Ph.D.)--University of North Carolina at Charlotte, 2012.
This Item is protected by copyright and/or related rights. You are free to use this Item in any way that is permitted by the copyright and related rights legislation that applies to your use. For other uses you need to obtain permission from the rights-holder(s). For additional information, see http://rightsstatements.org/page/InC/1.0/.
Copyright is held by the author unless otherwise indicated.