The Lives and Deaths of Open Source Code Forges Megan Squire Elon University Elon, North Carolina, USA [email protected]
Total Page:16
File Type:pdf, Size:1020Kb
The Lives and Deaths of Open Source Code Forges Megan Squire Elon University Elon, North Carolina, USA [email protected] ABSTRACT file downloads, version control systems, mailing list Code forges are third party software repositories that also software, wikis, bug tracking software, and so on. In the provide various tools and facilities for distributed software early years of the FLOSS phenomenon, these code forges development teams to use, including source code control served an important role for developers by providing a low systems, mailing lists and communication forums, bug barrier to entry to coordinate team work, and they served tracking systems, web hosting space, and so on. The main end-users by providing a centralized place to find and contributions of this paper are to present some new data sets communicate about a variety of different FLOSS projects. relating to the technology adoption lifecycles of a group of six free, libre, and open source software (FLOSS) code By the mid-2000s, larger software companies began to forges, and to compare the lifecycles of the forges to each create their own software forges, such as Google Code and other and to the model presented by classical Diffusion of Microsoft CodePlex. Non-commercial special-purpose Innovation (DoI) theory. We find that the observed forges were also created during this time frame, for adoption patterns of code forges rarely follow the DoI example RubyForge was designed for projects written in a model, especially as larger code forges are beset by spam particular programming language (Ruby) and the and abuse. The only forge exhibiting a DoI-like lifecycle ObjectWeb forge was designed for FLOSS middleware was a smaller, community-managed, special-purpose forge projects. GitHub was launched in 2008 to offer version whose demise was planned in advance. The results of this control and some basic features such as wikis and file study will be useful in explaining adoption trajectories, both downloads, and is now by far the largest centralized to practitioners building collaborative FLOSS ecosystems software forge with over 21 million user accounts and 57 and to researchers who study the evolution and adoption of million repositories as of this writing. [1] socio-technical systems. Though their intended audiences may differ, and the Author Keywords services provided by each code forge may be slightly Open source; free software; FLOSS; code forge; diffusion different, the purpose of all FLOSS code forges is to host of innovations; technology adoption; RubyForge; Google projects. Each time a project owner "chooses" to host their Code; SourceForge; ObjectWeb; CodePlex; GitHub; particular project on a code forge, this action is an software evolution indication that the code forge is still relevant in some way. Some of the oldest forges are still accepting new projects, ACM Classification Keywords while others have closed, merged, or otherwise transformed D.2.9. SOFTWARE ENGINEERING: Management; H.3.5 themselves as the FLOSS phenomenon has changed and INFORMATION STORAGE AND RETRIEVAL: Online matured. What do the project hosting rates look like in the Information Services; Data sharing. years between a code forge's birth and its death? Do the INTRODUCTION code forges follow the same adoption or "diffusion" Because teams of developers of free, libre, and open source patterns found in other technologies, as project owners software (FLOSS) projects are often geographically choose to adopt the technology or move to something else? distributed around the world, many teams choose to For this paper, we compare longitudinal data from six code structure their work in an asynchronous, location-neutral forges to a "typical" technology adoption curve as presented way. Early web-based FLOSS hosting services, such as in classical Diffusion of Innovation (DoI) theory. Basic SourceForge and GNU Savannah, offered features such as models for technology diffusion were first described by Permission to make digital or hard copies of all or part of this work for Everett Rogers [2], who proposed a life cycle consisting of personal or classroom use is granted without fee provided that copies are early adoption, adoption by the majority, then late adoption not made or distributed for profit or commercial advantage and that copies ("laggards"), and ultimately either discontinuance of the bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the author(s) must be product or a saturated market. He applied this model to a honored. Abstracting with credit is permitted. To copy otherwise, or variety of technologies in a variety of industries, refining republish, to post on servers or to redistribute to lists, requires prior the model to show that diffusion could be affected by many specific permission and/or a fee. Request permissions from Permissions factors including social interactions and organizational @acm.org. OpenSym '17, August 23–25, 2017, Galway, Ireland dynamics. With time plotted on the x-axis and adoption of © 2017 Copyright is held by the owner/author(s). Publication rights an innovation shown on the y-axis, Rogers proposed that licensed to ACM. the typical diffusion of an innovation over time will likely ACM ISBN 978-1-4503-5187-4/17/08…$15.00 https://doi.org/10.1145/3125433.3125468 resemble a normal distribution (or an S-curve if plotted GHTorrent data [5] is used to describe the lifecycle of with a cumulative x-axis). Figure 1 shows the two "typical" GitHub. GHTorrent was created in 2013 as a source of data DoI technology adoption curves. about projects hosted on Github. For each of the five forges in this study, our data, queries, and calculations are available for download in the FLOSSmole data repository, at http://flossdata.syr.edu/data/forgeStudies/2017deathOf Forges. RubyForge RubyForge was launched on July 16, 2003 as a Ruby language-specific hosting site for FLOSS projects. It included collaboration tools such as file downloads, source code control software, bug tracking, and mailing lists. Figure 1. "Typical" Diffusion of Innovations (DoI) curves with periods of maximum growth shown (after Rogers, 1964). Project-level metadata collected from the 10 years of RubyForge's existence was gathered and described in our In assessing the adoption or lifecycle of a technology, the prior work [6]. Examples of project-level metadata we steepness or shallowness of the S-curve is interesting, as is collected for RubyForge includes: project name, project the point at which the innovation declines following a owners/developers, project description, project license, period of maximum adoption. By studying the adoption project registration date, and so on. curves, we may find that some code forges may reach their peak (maximum adoption) earlier or later than expected. Figure 2 shows a visualization of the RubyForge monthly Some forges may be kept alive well past their expected new project registrations found in the [6] data set, lifespan. For code forges that are not dead yet, a partial beginning with its launch in 2003 through its shutdown in adoption curve may exhibit clues for what is to come. 2014. The dates of two important events in RubyForge's history are overlaid on the graph: the launch of GitHub's Thus, this paper begins a data-driven, historical analysis of gem builder in 2008, and the 2009 launch of Gemcutter the diffusion/adoption curves of code forges. We study six (eventually renamed RubyGems). GitHub was a significant in detail: RubyForge, Google Code, SourceForge, competitor to RubyForge, and Gemcutter/RubyGems was CodePlex, ObjectWeb, and GitHub. Our questions are: specifically designed by the RubyForge team to be a replacement for RubyForge. As the graph shows, the most • RQ1: What do the adoption curves for each code intense growth at RubyForge occurred between 2006-2009. forge look like? • RQ2: What factors, if any, alter the curves or affect the adoption patterns between the forges? • RQ3: Do all code forges exhibit the same patterns of birth, growth, and death as would be expected from traditional DoI theory? To answer RQ1, for each of six code forges, we gather metrics to describe its adoption rate and we plot the adoption rate graphically. For RQ2, we outline the various details (e.g. abuse of the system) that may explain the Figure 2. Monthly new project registrations on RubyForge, shapes of the curves. To answer RQ3, we compare the 2003-2013, with key dates shown shape of these curves to what DoI theory would predict and discuss the possible reasons for any differences. Finally, we explore the limitations of this work and present ideas for how to advance this work in the future. TECHNOLOGY ADOPTION DATA FLOSSmole [3] data is used in this paper to describe the adoption rates - via new project registrations - of RubyForge, Google Code, CodePlex, and ObjectWeb. FLOSSmole was created in 2004 as a source for research- quality data about how free, libre, and open source software is constructed. SourceForge Research Data Archive (SRDA) [4] data is used to describe the lifecycle of SourceForge. SRDA was created in 2003 as a repository of Figure 3. Cumulative monthly new project registrations on data about projects hosted on the SourceForge system. RubyForge, 2003-2013, with month of maximum growth shown (January 2008) Figure 3 shows the same data, but with monthly but new project creations never again reached their pre- contributions comprising a cumulative total. This graph deluge levels. Nonetheless, on March 12, 2015 Chris shows that RubyForge began its decline at 52% saturation DiBona announced [9] that the code forge would shut down of the "market". Following the launch of a competitive site completely. He explained, (GitHub) and its own planned replacement "As developers migrated away from Google Code [to (Gemcutter/RubyGems), RubyForge began a slow decline. GitHub], a growing share of the remaining projects were RubyForge was eventually closed to new projects at the end [sic] spam or abuse.