DOCSLIB.ORG

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

Download full-text PDF Read full-text
The Lives and Deaths of Open Source Code Forges Megan Squire Elon University Elon, North Carolina, USA Msquire@Elon.Edu 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 both to practitioners building downloads, and is now by far the largest centralized collaborative FLOSS ecosystems, such as code forges, and software forge with over 21 million user accounts and 57 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 Paste the appropriate copyright/license statement here. ACM now supports Everett Rogers [2], who proposed a life cycle consisting of three different publication options: early adoption, adoption by the majority, then late adoption • ACM copyright: ACM holds the copyright on the work. This is the ("laggards"), and ultimately either discontinuance of the historical approach. product or a saturated market. He applied this model to a • License: The author(s) retain copyright, but ACM receives an exclusive publication license. variety of technologies in a variety of industries, refining • Open Access: The author(s) wish to pay for the work to be open the model to show that diffusion could be affected by many access. The additional fee must be paid to ACM. factors including social interactions and organizational This text field is large enough to hold the appropriate release statement dynamics. With time plotted on the x-axis and adoption of assuming it is single-spaced in Times New Roman 8-point font. Please do not change or modify the size of this text box. an innovation shown on the y-axis, Rogers proposed that Each submission will be assigned a DOI string to be included here. the typical diffusion of an innovation over time will likely 1 resemble a normal distribution (or an S-curve if plotted repository, at http://flossdata.syr.edu/data/forgeStudies/ with a cumulative x-axis). Figure 1 shows the two "typical" 2017deathOfForges. DoI technology adoption curves. 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. Project-level metadata collected from the 10 years of RubyForge's existence was gathered and described in our prior work [6]. Examples of project-level metadata we collected for RubyForge includes: project name, project owners/developers, project description, project license, Figure 1. "Typical" Diffusion of Innovations (DoI) curves with periods of maximum growth shown (after Rogers, 1964). project registration date, and so on. In assessing the adoption or lifecycle of a technology, the Figure 2 shows a visualization of the RubyForge monthly steepness or shallowness of the S-curve is interesting, as is new project registrations found in the [6] data set, the point at which the innovation declines following a beginning with its launch in 2003 through its shutdown in period of maximum adoption. By studying the adoption 2014. The dates of two important events in RubyForge's curves, we may find that some code forges may reach their history are overlaid on the graph: the launch of Github's peak (maximum adoption) earlier or later than expected. gem builder in 2008, and the 2009 launch of Gemcutter Some forges may be kept alive well past their expected (eventually renamed RubyGems). Github was a significant lifespan. For code forges that are not dead yet, a partial competitor to RubyForge, and Gemcutter/RubyGems was adoption curve may exhibit clues for what is to come. specifically designed by the RubyForge team to be a replacement for RubyForge. As the graph shows, the years Thus, this paper begins a data-driven, historical analysis of of most intense growth at RubyForge were between 2006- the diffusion/adoption curves of code forges. We study six 2009. in detail: RubyForge, Google Code, SourceForge, CodePlex, ObjectWeb, and Github. Our questions are: • RQ1: What do the adoption curves for each code 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? Figure 2. Monthly new project registrations on RubyForge, To answer RQ1, for each of six code forges, we gather 2003-2013, with key dates shown metrics to describe its adoption rate and we plot the adoption rate graphically. For RQ2, we outline the various details (e.g. spam) that may explain the shapes of the curves. To answer RQ3, we compare the 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. SourceForge Research Data Archive (SRDA) [4] data is Figure 3. Cumulative monthly new project registrations on used to describe the lifecycle of SourceForge. GHTorrent RubyForge, 2003-2013, with month of maximum growth data [5] is used to describe the lifecycle of Github. For each shown (January 2008) forge, the data, queries, and calculations used in this paper Figure 3 shows the same data, but with monthly are available for download in the FLOSSmole data contributions comprising a cumulative total. This graph shows that RubyForge began its decline at 52% saturation 2 of the "market". Following the launch of a competitive site announced [9] that the code forge would shut down (Github) and its own planned replacement completely. He explained, (Gemcutter/RubyGems), RubyForge began a slow decline. "As developers migrated away from Google Code [to RubyForge was eventually closed to new projects at the end Github], a growing share of the remaining projects were of 2013, and shuttered for good in May of 2014, having [sic] spam or abuse. Lately, the administrative load has hosted a total of 9,898 projects over its lifetime. consisted almost exclusively of abuse management." Google Code Google Code (http://code.google.com) was launched in DiBona directly blames the demise of Google Code on both 2006 as a free-of-charge hosting site for any software the spam/abuse problem and the existence of competitive project using an OSI-approved FLOSS license.
Load more

Recommended publications
  • Letter, If Not the Spirit, of One Or the Other Definition
    Producing Open Source Software How to Run a Successful Free Software Project Karl Fogel Producing Open Source Software: How to Run a Successful Free Software Project by Karl Fogel Copyright © 2005-2021 Karl Fogel, under the CreativeCommons Attribution-ShareAlike (4.0) license. Version: 2.3214 Home site: https://producingoss.com/ Dedication This book is dedicated to two dear friends without whom it would not have been possible: Karen Under- hill and Jim Blandy. i Table of Contents Preface ............................................................................................................................. vi Why Write This Book? ............................................................................................... vi Who Should Read This Book? ..................................................................................... vi Sources ................................................................................................................... vii Acknowledgements ................................................................................................... viii For the first edition (2005) ................................................................................ viii For the second edition (2021) .............................................................................. ix Disclaimer .............................................................................................................. xiii 1. Introduction ...................................................................................................................
    [Show full text]
  • Free Software Needs Free Tools
    Free Software Needs Free Tools Benjamin Mako Hill [email protected] June 6, 2010 Over the last decade, free software developers have been repeatedly tempted by devel- opment tools that offer the ability to build free software more efficiently or powerfully. The only cost, we are told, is that the tools themselves are nonfree or run as network services with code we cannot see, copy, or run ourselves. In their decisions to use these tools and services – services such as BitKeeper, SourceForge, Google Code and GitHub – free software developers have made “ends-justify-the-means” decisions that trade away the freedom of both their developer communities and their users. These decisions to embrace nonfree and private development tools undermine our credibility in advocating for soft- ware freedom and compromise our freedom, and that of our users, in ways that we should reject. In 2002, Linus Torvalds announced that the kernel Linux would move to the “Bit- Keeper” distributed version control system (DVCS). While the decision generated much alarm and debate, BitKeeper allowed kernel developers to work in a distributed fashion in a way that, at the time, was unsupported by free software tools – some Linux developers decided that benefits were worth the trade-off in developers’ freedom. Three years later the skeptics were vindicated when BitKeeper’s owner, Larry McVoy, revoked several core kernel developers’ gratis licenses to BitKeeper after Andrew Tridgell attempted to write a free replacement for BitKeeper. Kernel developers were forced to write their own free software replacement: the project now known as Git. Of course, free software’s relationships to nonfree development tools is much larger than BitKeeper.
    [Show full text]
  • Awesome Selfhosted - Software Development - Project Management
    Awesome Selfhosted - Software Development - Project Management Software Development - Project Management See also: awesome-sysadmin/Code Review Bonobo Git Server - Set up your own self hosted git server on IIS for Windows. Manage users and have full control over your repositories with a nice user friendly graphical interface. ( Source Code) MIT C# Fossil - Distributed version control system featuring wiki and bug tracker. BSD-2-Clause- FreeBSD C Goodwork - Self hosted project management and collaboration tool powered by Laravel & VueJS. (Demo, Source Code) MIT PHP Gitblit - Pure Java stack for managing, viewing, and serving Git repositories. (Source Code) Apache-2.0 Java gitbucket - Easily installable GitHub clone powered by Scala. (Source Code) Apache-2.0 Scala/Java Gitea - Community managed fork of Gogs, lightweight code hosting solution. (Demo, Source Code) MIT Go GitLab - Self Hosted Git repository management, code reviews, issue tracking, activity feeds and wikis. (Demo, Source Code) MIT Ruby Gitlist - Web-based git repository browser - GitList allows you to browse repositories using your favorite browser, viewing files under different revisions, commit history and diffs. ( Source Code) BSD-3-Clause PHP Gitolite - Gitolite allows you to setup git hosting on a central server, with fine-grained access control and many more powerful features. (Source Code) GPL-2.0 Perl GitPrep - Portable Github clone. (Demo, Source Code) Artistic-2.0 Perl Git WebUI - Standalone web based user interface for git repositories. Apache-2.0 Python Gogs - Painless self-hosted Git Service written in Go. (Demo, Source Code) MIT Go Kallithea - Source code management system that supports two leading version control systems, Mercurial and Git, with a web interface.
    [Show full text]
  • Master Thesis Innovation Dynamics in Open Source Software
    Master thesis Innovation dynamics in open source software Author: Name: Remco Bloemen Student number: 0109150 Email: [email protected] Telephone: +316 11 88 66 71 Supervisors and advisors: Name: prof. dr. Stefan Kuhlmann Email: [email protected] Telephone: +31 53 489 3353 Office: Ravelijn RA 4410 (STEPS) Name: dr. Chintan Amrit Email: [email protected] Telephone: +31 53 489 4064 Office: Ravelijn RA 3410 (IEBIS) Name: dr. Gonzalo Ord´o~nez{Matamoros Email: [email protected] Telephone: +31 53 489 3348 Office: Ravelijn RA 4333 (STEPS) 1 Abstract Open source software development is a major driver of software innovation, yet it has thus far received little attention from innovation research. One of the reasons is that conventional methods such as survey based studies or patent co-citation analysis do not work in the open source communities. In this thesis it will be shown that open source development is very accessible to study, due to its open nature, but it requires special tools. In particular, this thesis introduces the method of dependency graph analysis to study open source software devel- opment on the grandest scale. A proof of concept application of this method is done and has delivered many significant and interesting results. Contents 1 Open source software 6 1.1 The open source licenses . 8 1.2 Commercial involvement in open source . 9 1.3 Opens source development . 10 1.4 The intellectual property debates . 12 1.4.1 The software patent debate . 13 1.4.2 The open source blind spot . 15 1.5 Litterature search on network analysis in software development .
    [Show full text]
  • Snapshots of Open Source Project Management Software
    International Journal of Economics, Commerce and Management United Kingdom ISSN 2348 0386 Vol. VIII, Issue 10, Oct 2020 http://ijecm.co.uk/ SNAPSHOTS OF OPEN SOURCE PROJECT MANAGEMENT SOFTWARE Balaji Janamanchi Associate Professor of Management Division of International Business and Technology Studies A.R. Sanchez Jr. School of Business, Texas A & M International University Laredo, Texas, United States of America [email protected] Abstract This study attempts to present snapshots of the features and usefulness of Open Source Software (OSS) for Project Management (PM). The objectives include understanding the PM- specific features such as budgeting project planning, project tracking, time tracking, collaboration, task management, resource management or portfolio management, file sharing and reporting, as well as OSS features viz., license type, programming language, OS version available, review and rating in impacting the number of downloads, and other such usage metrics. This study seeks to understand the availability and accessibility of Open Source Project Management software on the well-known large repository of open source software resources, viz., SourceForge. Limiting the search to “Project Management” as the key words, data for the top fifty OS applications ranked by the downloads is obtained and analyzed. Useful classification is developed to assist all stakeholders to understand the state of open source project management (OSPM) software on the SourceForge forum. Some updates in the ranking and popularity of software since
    [Show full text]
  • Verso Project Application Report 0.6 Public Document Info
    Verso Project Application Report Tero Hänninen Juho Nieminen Marko Peltola Heikki Salo Version 0.6 Public 4.8.2010 University of Jyväskylä Department of Mathematical Information Technology Jyväskylä Acceptor Date Signature Clarification Project manager __.__.2010 Customer __.__.2010 Instructor __.__.2010 Verso Project Application Report 0.6 Public Document Info Authors: • Tero Hänninen (TH) [email protected] 0400-240468 • Juho Nieminen (JN) [email protected] 050-3831825 • Marko Peltola (MP) [email protected] 041-4498622 • Heikki Salo (HS) [email protected] 050-3397894 Document name: Verso Project, Application Report Page count: 46 Abstract: Verso project developed a web application for source code manage- ment and publishing. The document goes through the background of the software, presents the user interface and the application structure and describes the program- ming and testing practices used in the project. The realization of functional require- ments and ideas for further development are also presented. In addition, there is a guide for future developers at the end. Keywords: Application report, application structure, Git, Gitorious, programming practise, Ruby on Rails, software project, software development, source code man- agement, testing, WWW interface, web application. i Verso Project Application Report 0.6 Public Project Contact Information Project group: Tero Hänninen [email protected] 0400-240468 Juho Nieminen [email protected] 050-3831825 Marko Peltola [email protected] 041-4498622 Heikki Salo [email protected] 050-3397894 Customers: Ville Tirronen [email protected] 014-2604987 Tero Tuovinen [email protected] 050-4413685 Paavo Nieminen [email protected] 040-5768507 Tapani Tarvainen [email protected] 014-2602752 Instructors: Jukka-Pekka Santanen [email protected] 014-2602756 Antti-Juhani Kaijanaho [email protected] 014-2602766 Contact information: Email lists [email protected] and [email protected].
    [Show full text]
  • Collaborative Software Development Using R-Forge
    INVITED SECTION:THE FUTURE OF R 9 Collaborative Software Development Using R-Forge Special invited paper on “The Future of R” Forge, host a project-specific website, and how pack- age maintainers submit a package to the Compre- by Stefan Theußl and Achim Zeileis hensive R Archive Network (CRAN, http://CRAN. R-project.org/). Finally, we summarize recent de- velopments and give a brief outlook to future work. Introduction Open source software (OSS) is typically created in a R-Forge decentralized self-organizing process by a commu- nity of developers having the same or similar inter- R-Forge offers a central platform for the develop- ests (see the famous essay by Raymond, 1999). A ment of R packages, R-related software and other key factor for the success of OSS over the last two projects. decades is the Internet: Developers who rarely meet R-Forge is based on GForge (Copeland et al., face-to-face can employ new means of communica- 2006) which is an open source fork of the 2.61 Source- tion, both for rapidly writing and deploying software Forge code maintained by Tim Perdue, one of the (in the spirit of Linus Torvald’s “release early, release original SourceForge authors. GForge has been mod- often paradigm”). Therefore, many tools emerged ified to provide additional features for the R commu- that assist a collaborative software development pro- nity, namely a CRAN-style repository for hosting de- cess, including in particular tools for source code velopment releases of R packages as well as a quality management (SCM) and version control.
    [Show full text]
  • The Networked Forge: New Environments for Libre Software Development*
    The networked forge: new environments for libre software development* Jesús M. Gonzalez-Barahona, Andrés Martínez, Alvaro Polo, Juan José Hierro, Marcos Reyes and Javier Soriano and Rafael Fernández Abstract Libre (free, open source) software forges (sites hosting the development infrastructure for a collection of projects) have been stable in architecture, services and concept since they become popular during the late 1990s. During this time sev- eral problems that cannot be solved without dramatic design changes have become evident. To overeóme them, we propose a new concept, the "networked forge", fo- cused on addressing the core characteristics of libre software development and the needs of developers. The key of this proposal is to re-engineer forges as a net of dis- tributed components which can be composed and configured according to the needs of users, using a combination of web 2.0, semantic web and mashup technologies. This approach is flexible enough to accommodate different development processes, while at the same time interoperates with current facilities. 1 Introduction The libre (free, open source) software2 development community, considered as a whole, is one of the largest cases of informal, globally distributed, virtual organi- zation oriented to the production of goods. Hundreds of thousands of developers Jesús M. Gonzalez-Barahona GSyC/LibreSoft, Universidad Rey Juan Carlos, e-mail: jgb~at~gsyc . escet. urj c . es Andrés Martínez, Alvaro Polo, Juan José Hierro and Marcos Reyes Telefónica Investigación y Desarrollo Javier Soriano and Rafael Fernández Universidad Politécnica de Madrid * This work has been funded in part by the European Commission, through projects FLOSSMet- rics, FP6-IST-5-033982, and Qualipso, FP6-IST-034763, and by the Spanish Ministry of Industry, through projects Morfeo, FIT-350400-2006-20, and Vulcano, FIT-340503-2006-3 2 In this paper the term "libre software" is used to refer both to "free software" (as defined by the Free Software Foundation) and "open source software" (as defined by the Open Source Initiative).
    [Show full text]
  • The Lcg Savannah Software Development Portal
    THE LCG SAVANNAH SOFTWARE DEVELOPMENT PORTAL Y. Perrin, D. Feichtinger#1, F. Orellana#2, CERN, Geneva, Switzerland, M. Roy, FSF France Abstract A web portal has been developed, in the context of ORGANIZATION AND the LCG/SPI project, in order to coordinate workflow FUNCTIONALITY and manage information in large software projects. It is LCG Savannah is organized in projects which are a development of the GNU Savannah package and grouped according to their type as entered at offers a range of services to every hosted project: Bug / registration time. All projects of the same type inherit a support / patch trackers, a simple task planning system, number of common characteristics and default values news threads, and a download area for software with, of course, the possibility to define new types and releases. Features and functionality can be fine-tuned to override the defaults for any given project. on a per project basis and the system displays content LCG Savannah should be seen as a development and grants permissions according to the user's status front-end for every project it hosts. It provides, in a (project member, other Savannah user, or visitor). A fully configurable and integrated way, the main highly configurable notification system is able to functions required by any significant software channel tracker submissions to developers in charge of development project. These include bug and support specific project modules. request tracking, task management, automatic The portal is based on the GNU Savannah package notification of people concerned, access to CVS which is now developed as 'Savane' with the support of repository, download area, news and mailing lists.
    [Show full text]
  • Crowdsourcing the Discovery of Software Repositories in an Educational Environment
    Crowdsourcing the Discovery of Software Repositories in an Educational Environment Yuxing Ma Tapajit Dey University of Tennessee University of Tennessee Knoxville, Tennessee Knoxville, Tennessee [email protected] [email protected] Jared M. Smith Nathan Wilder Audris Mockus University of Tennessee University of Tennessee University of Tennessee Knoxville, Tennessee Knoxville, Tennessee Knoxville, Tennessee [email protected] [email protected] [email protected] ABSTRACT vice and a large number of repositories are being hosted on In software repository mining, it's important to have a broad online forges. For example, the number and size of reposi- representation of projects. In particular, it may be of inter- tories hosted on GitHub roughly doubled over the last year. est to know what proportion of projects are public. Dis- A census of public software projects is highly desirable for covering public projects can be easily parallelized but not reasons similar to those of a population census [6]. Discov- so easy to automate due to a variety of data sources. We ering the projects even on a known forge, may be a nontriv- evaluate the research and educational potential of crowd- ial task, however. To accomplish it, we ran an experiment sourcing such research activity in an educational setting. to distribute the data gathering over a group of students Students were instructed on three ways of discovering the in order to provide a practical example of data discovery. projects and assigned a task to discover the list of public Such approach is promising because it has the potential for projects from top 45 forges with each student assigned to faster speed, lower cost, more flexibility, and better diversity, one forge.
    [Show full text]
  • Bill Laboon Friendly Introduction Version Control: a Brief History
    Git and GitHub: A Bill Laboon Friendly Introduction Version Control: A Brief History ❖ In the old days, you could make a copy of your code at a certain point, and release it ❖ You could then continue working on your code, adding features, fixing bugs, etc. ❖ But this had several problems! VERSION 1 VERSION 2 Version Control: A Brief History ❖ Working with others was difficult - if you both modified the same file, it could be very difficult to fix! ❖ Reviewing changes from “Release n” to “Release n + 1” could be very time-consuming, if not impossible ❖ Modifying code locally meant that a crash could take out much of your work Version Control: A Brief History ❖ So now we have version control - a way to manage our source code in a regular way. ❖ We can tag releases without making a copy ❖ We can have numerous “save points” in case our modifications need to be unwound ❖ We can easily distribute our code across multiple machines ❖ We can easily merge work from different people to the same codebase Version Control ❖ There are many kinds of version control out there: ❖ BitKeeper, Perforce, Subversion, Visual SourceSafe, Mercurial, IBM ClearCase, AccuRev, AutoDesk Vault, Team Concert, Vesta, CVSNT, OpenCVS, Aegis, ArX, Darcs, Fossil, GNU Arch, BitKeeper, Code Co-Op, Plastic, StarTeam, MKS Integrity, Team Foundation Server, PVCS, DCVS, StarTeam, Veracity, Razor, Sun TeamWare, Code Co-Op, SVK, Fossil, Codeville, Bazaar…. ❖ But we will discuss git and its most popular repository hosting service, GitHub What is git? ❖ Developed by Linus Torvalds ❖ Strong support for distributed development ❖ Very fast ❖ Very efficient ❖ Very resistant against data corruption ❖ Makes branching and merging easy ❖ Can run over various protocols Git and GitHub ❖ git != GitHub ❖ git is the software itself - GitHub is just a place to store it, and some web-based tools to help with development.
    [Show full text]
  • Producing Open Source Software How to Run a Successful Free Software Project
    Producing Open Source Software How to Run a Successful Free Software Project Karl Fogel Producing Open Source Software: How to Run a Successful Free Software Project by Karl Fogel Copyright © 2005-2013 Karl Fogel, under a CreativeCommons Attribution-ShareAlike (3.0) license [http:// creativecommons.org/licenses/by/3.0/]. Dedication This book is dedicated to two dear friends without whom it would not have been possible: Karen Underhill and Jim Blandy. i Table of Contents Preface ............................................................................................................................ vi Why Write This Book? .............................................................................................. vi Who Should Read This Book? ..................................................................................... vi Sources ................................................................................................................... vii Acknowledgments .................................................................................................... viii Disclaimer ................................................................................................................ ix 1. Introduction ................................................................................................................... 1 History ..................................................................................................................... 3 The Rise of Proprietary Software and Free Software ................................................
    [Show full text]