DOCSLIB.ORG

Quality Improvement in Volunteer Free and Open Source Software Projects: Exploring the Impact of Release Management

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Quality Improvement in Volunteer Free and Open Source Software Projects: Exploring the Impact of Release Management Quality Improvement in Volunteer Free and Open Source Software Projects Exploring the Impact of Release Management A dissertation submitted to the University of Cambridge for the Degree of Doctor of Philosophy Martin Michlmayr <[email protected]> King’s College March 2007 Centre for Technology Management Institute for Manufacturing University of Cambridge Quality Improvement in Volunteer Free and Open Source Software Projects Exploring the Impact of Release Management Martin Michlmayr Free and open source software has had a major impact on the computer industry since the late 1990s and has changed the way software is perceived, developed and deployed in many areas. Free and open source software, or FOSS, is typically developed in a collaborative fashion and the majority of contributors are volunteers. Even though this collaborative form of develop- ment has produced a significant body of software, the development process is often described as unstructured and unorganized. This dissertation studies the FOSS phenomenon from a quality perspective and investigates where im- provements to the development process are possible. In particular, the focus is on release management since this is concerned with the delivery of a high quality product to end-users. This research has identified considerable interest amongst the FOSS commu- nity in a novel release management strategy, time based releases. In contrast to traditional development which is feature-driven, time based releases use time rather than features as the criterion for the creation of a new release. Releases are made after a specific interval, and new features that have been completed and sufficiently tested since the last release are included in the new version. This dissertation explores why, and under which circumstances, the time based release strategy is a viable alternative to feature-driven development and discusses factors that influence a successful implementation of this release strategy. It is argued that this release strategy acts as a coordination mecha- nism in large volunteer projects that are geographically dispersed. The time based release strategy allows a more controlled development and release pro- cess in projects which have little control of their contributors and therefore contributes to the quality of the output. Preface Except for commonly understood and accepted ideas, or where specific refer- ence is made, the work reported in this dissertation is my own and includes nothing that is the outcome of work done in collaboration. No part of the dissertation has been previously submitted to any university for any degree, diploma or other qualification. This dissertation consists of approximately 60,000 words, and therefore does not exceed the 65,000 word limit put forth by the Degree Committee of the Department of Engineering. Martin Michlmayr March 2007 iii Contents Abstract ii Preface iii 1. Introduction 1 1.1. A Definition of FOSS . 1 1.2. Problems with the FOSS Process . 5 1.3. Contribution of this Dissertation . 7 1.4. Structure of the Dissertation . 7 2. Quality Management 9 2.1. Quality Literature . 9 2.1.1. Definitions of Quality . 9 2.1.2. Process Improvement . 12 2.2. FOSS Literature . 13 2.2.1. Quality Considerations . 13 2.2.2. Development Style . 15 2.2.3. Challenges and Problems . 19 2.2.4. Summary . 21 2.3. Exploratory Study . 22 2.3.1. Methodology . 22 2.3.2. Comparison of Proprietary Software and FOSS . 23 2.3.3. Development and Quality Practices . 24 2.3.4. Quality Problems . 27 2.3.5. Discussion . 30 2.4. Refining the Scope . 31 2.5. Chapter Summary . 34 iv Contents v 3. Release Management 35 3.1. Literature . 35 3.1.1. Software Maintenance . 36 3.1.2. Release Management in FOSS . 38 3.2. Exploratory Study . 40 3.2.1. Methodology . 40 3.2.2. Types of Release Management . 41 3.2.3. Preparation of Stable Releases . 42 3.2.4. Skills . 47 3.2.5. Tools and Practices . 48 3.2.6. Problems . 50 3.2.7. Discussion . 52 3.3. Theory . 53 3.3.1. Modularity and Complexity . 54 3.3.2. Coordination in FOSS . 55 3.3.3. Coordination Theory . 56 3.4. Chapter Summary . 59 4. Research Question and Methodology 61 4.1. Research Question . 61 4.2. The Case Study Approach . 62 4.3. Selection Criteria . 64 4.4. Case Study Projects . 68 4.5. Sources of Evidence . 71 4.5.1. Interviews . 73 4.5.2. Mailing Lists . 73 4.5.3. Documents . 74 4.5.4. Observation . 75 4.6. Methodological Considerations . 75 4.6.1. Construct Validity . 75 4.6.2. Internal Validity . 76 4.6.3. External Validity . 76 4.6.4. Reliability . 77 4.6.5. Personal Involvement . 77 Contents vi 4.6.6. Ethical Issues . 78 4.7. Chapter Summary . 79 5. Time Based Releases: Learning from 7 Case Studies 80 5.1. Debian . 80 5.2. GCC . 85 5.3. GNOME . 88 5.4. Linux . 92 5.5. OpenOffice.org . 97 5.6. Plone . 100 5.7. X.org . 102 5.8. Chapter Summary . 105 6. Release Strategy 106 6.1. Problems Prompting a Change . 106 6.1.1. Lack of Planning . 107 6.1.2. Problems Caused by Lack of Planning . 109 6.1.3. Long-term Issues . 112 6.1.4. Summary . 113 6.2. Time Based Strategy as an Alternative . 113 6.2.1. Conditions That Have to be Met . 113 6.2.2. Time Based Releases as a Coordination Mechanism . 120 6.2.3. Advantages of Time Based Releases . 129 6.2.4. Open Questions . 133 6.3. Chapter Summary . 136 7. Schedules 138 7.1. Choice of the Release Interval . 138 7.1.1. Regularity and Predictability . 138 7.1.2. User Requirements . 140 7.1.3. Commercial Interests . 141 7.1.4. Cost Factors Related to Releasing . 143 7.1.5. Network Effects . 146 7.1.6. Summary . 148 7.2. Creation of a Schedule . 148 Contents vii 7.2.1. Identification of Dependencies . 149 7.2.2. Planning the Schedule . 150 7.2.3. Avoiding Certain Periods . 152 7.3. Chapter Summary . 153 8. Implementation and Coordination Mechanisms 154 8.1. Implementing Change . 154 8.1.1. Incentives for Change . 154 8.1.2. Issues of Control and Trust . 155 8.1.3. Implementation of Control Structures . 157 8.1.4. Summary . 160 8.2. Policies . 160 8.2.1. Stability of the Development Tree . 160 8.2.2. Feature Proposals . 162 8.2.3. Milestones and Deadlines . 164 8.2.4. Summary . 165 8.3. Coordination and Collaboration Mechanisms . 165 8.3.1. Bug Tracking . 166 8.3.2. Communication Channels . 169 8.3.3. Meetings in Real Life . 172 8.3.4. Summary . 173 8.4. Chapter Summary . 173 9. Discussion and Conclusions 175 9.1. Discussion . 175 9.2. Key Learning Points . 178 9.3. Limitations and Future Research . 179 9.4. Conclusions . 184 Acknowledgements 185 Glossary 186 A. Exploratory Studies 188 A.1. Quality . 188 A.1.1. Questions . 188 Contents viii A.1.2. Projects . 188 A.1.3. Consent . 189 A.2. Release Management . 189 A.2.1. Questions . 189 A.2.2. Projects . 191 A.2.3. Consent . 192 B. Case Studies 194 B.1. Interviews . 194 B.1.1. Questions . 194 B.1.2. Projects and Participants . 195 B.1.3. Consent . ..
Load more

Recommended publications
  • Redhawk Linux User's Guide
    Linux® User’s Guide 0898004-520 May 2007 Copyright 2007 by Concurrent Computer Corporation. All rights reserved. This publication or any part thereof is intended for use with Concurrent products by Concurrent personnel, customers, and end–users. It may not be reproduced in any form without the written permission of the publisher. The information contained in this document is believed to be correct at the time of publication. It is subject to change without notice. Concurrent makes no warranties, expressed or implied, concerning the information contained in this document. To report an error or comment on a specific portion of the manual, photocopy the page in question and mark the correction or comment on the copy. Mail the copy (and any additional comments) to Concurrent Computer Corporation, 2881 Gateway Drive, Pompano Beach, Florida, 33069. Mark the envelope “Attention: Publications Department.” This publication may not be reproduced for any other reason in any form without written permission of the publisher. Concurrent Computer Corporation and its logo are registered trademarks of Concurrent Computer Corporation. All other Concurrent product names are trademarks of Concurrent while all other product names are trademarks or registered trademarks of their respective owners. Linux® is used pursuant to a sublicense from the Linux Mark Institute. Printed in U. S. A. Revision History: Date Level Effective With August 2002 000 RedHawk Linux Release 1.1 September 2002 100 RedHawk Linux Release 1.1 December 2002 200 RedHawk Linux Release 1.2 April 2003 300 RedHawk Linux Release 1.3, 1.4 December 2003 400 RedHawk Linux Release 2.0 March 2004 410 RedHawk Linux Release 2.1 July 2004 420 RedHawk Linux Release 2.2 May 2005 430 RedHawk Linux Release 2.3 March 2006 500 RedHawk Linux Release 4.1 May 2006 510 RedHawk Linux Release 4.1 May 2007 520 RedHawk Linux Release 4.2 Preface Scope of Manual This manual consists of three parts.
    [Show full text]
  • Debian 1 Debian
    Debian 1 Debian Debian Part of the Unix-like family Debian 7.0 (Wheezy) with GNOME 3 Company / developer Debian Project Working state Current Source model Open-source Initial release September 15, 1993 [1] Latest release 7.5 (Wheezy) (April 26, 2014) [±] [2] Latest preview 8.0 (Jessie) (perpetual beta) [±] Available in 73 languages Update method APT (several front-ends available) Package manager dpkg Supported platforms IA-32, x86-64, PowerPC, SPARC, ARM, MIPS, S390 Kernel type Monolithic: Linux, kFreeBSD Micro: Hurd (unofficial) Userland GNU Default user interface GNOME License Free software (mainly GPL). Proprietary software in a non-default area. [3] Official website www.debian.org Debian (/ˈdɛbiən/) is an operating system composed of free software mostly carrying the GNU General Public License, and developed by an Internet collaboration of volunteers aligned with the Debian Project. It is one of the most popular Linux distributions for personal computers and network servers, and has been used as a base for other Linux distributions. Debian 2 Debian was announced in 1993 by Ian Murdock, and the first stable release was made in 1996. The development is carried out by a team of volunteers guided by a project leader and three foundational documents. New distributions are updated continually and the next candidate is released after a time-based freeze. As one of the earliest distributions in Linux's history, Debian was envisioned to be developed openly in the spirit of Linux and GNU. This vision drew the attention and support of the Free Software Foundation, who sponsored the project for the first part of its life.
    [Show full text]
  • Kshot: Live Kernel Patching with SMM and SGX
    KShot: Live Kernel Patching with SMM and SGX Lei Zhou∗y, Fengwei Zhang∗, Jinghui Liaoz, Zhengyu Ning∗, Jidong Xiaox Kevin Leach{, Westley Weimer{ and Guojun Wangk ∗Department of Computer Science and Engineering, Southern University of Science and Technology, Shenzhen, China, zhoul2019,zhangfw,ningzy2019 @sustech.edu.cn f g ySchool of Computer Science and Engineering, Central South University, Changsha, China zDepartment of Computer Science, Wayne State University, Detroit, USA, [email protected] xDepartment of Computer Science, Boise State University, Boise, USA, [email protected] Department of Computer Science and Engineering, University of Michigan, Ann Arbor, USA, kjleach,weimerw @umich.edu { f g kSchool of Computer Science and Cyber Engineering, Guangzhou University, Guangzhou, China, [email protected] Abstract—Live kernel patching is an increasingly common kernel vulnerabilities also merit patching. Organizations often trend in operating system distributions, enabling dynamic up- use rolling upgrades [3], [6], in which patches are designed dates to include new features or to fix vulnerabilities without to affect small subsystems that minimize unplanned whole- having to reboot the system. Patching the kernel at runtime lowers downtime and reduces the loss of useful state from running system downtime, to update and patch whole server systems. applications. However, existing kernel live patching techniques However, rolling upgrades do not altogether obviate the need (1) rely on specific support from the target operating system, to restart software or reboot systems; instead, dynamic hot and (2) admit patch failures resulting from kernel faults. We patching (live patching) approaches [7]–[9] aim to apply present KSHOT, a kernel live patching mechanism based on patches to running software without having to restart it.
    [Show full text]
  • SPI Annual Report 2015
    Software in the Public Interest, Inc. 2015 Annual Report July 12, 2016 To the membership, board and friends of Software in the Public Interest, Inc: As mandated by Article 8 of the SPI Bylaws, I respectfully submit this annual report on the activities of Software in the Public Interest, Inc. and extend my thanks to all of those who contributed to the mission of SPI in the past year. { Martin Michlmayr, SPI Secretary 1 Contents 1 President's Welcome3 2 Committee Reports4 2.1 Membership Committee.......................4 2.1.1 Statistics...........................4 3 Board Report5 3.1 Board Members............................5 3.2 Board Changes............................6 3.3 Elections................................6 4 Treasurer's Report7 4.1 Income Statement..........................7 4.2 Balance Sheet............................. 13 5 Member Project Reports 16 5.1 New Associated Projects....................... 16 5.2 Updates from Associated Projects................. 16 5.2.1 0 A.D.............................. 16 5.2.2 Chakra............................ 16 5.2.3 Debian............................. 17 5.2.4 Drizzle............................. 17 5.2.5 FFmpeg............................ 18 5.2.6 GNU TeXmacs........................ 18 5.2.7 Jenkins............................ 18 5.2.8 LibreOffice.......................... 18 5.2.9 OFTC............................. 19 5.2.10 PostgreSQL.......................... 19 5.2.11 Privoxy............................ 19 5.2.12 The Mana World....................... 19 A About SPI 21 2 Chapter 1 President's Welcome SPI continues to focus on our core services, quietly and competently supporting the activities of our associated projects. A huge thank-you to everyone, particularly our board and other key volun- teers, whose various contributions of time and attention over the last year made continued SPI operations possible! { Bdale Garbee, SPI President 3 Chapter 2 Committee Reports 2.1 Membership Committee 2.1.1 Statistics On January 1, 2015 we had 512 contributing and 501 non-contributing mem- bers.
    [Show full text]
  • Red Hat Enterprise Linux 7 Kernel Administration Guide
    Red Hat Enterprise Linux 7 Kernel Administration Guide Examples of Tasks for Managing the Kernel Last Updated: 2018-05-21 Red Hat Enterprise Linux 7 Kernel Administration Guide Examples of Tasks for Managing the Kernel Marie Dolezelova Red Hat Customer Content Services [email protected] Mark Flitter Red Hat Customer Content Services Douglas Silas Red Hat Customer Content Services Eliska Slobodova Red Hat Customer Content Services Jaromir Hradilek Red Hat Customer Content Services Maxim Svistunov Red Hat Customer Content Services Robert Krátký Red Hat Customer Content Services Stephen Wadeley Red Hat Customer Content Services Florian Nadge Red Hat Customer Content Services Legal Notice Copyright © 2018 Red Hat, Inc. The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/ . In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. Linux ® is the registered trademark of Linus Torvalds in the United States and other countries. Java ® is a registered trademark of Oracle and/or its affiliates.
    [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-2017 Karl Fogel, under the CreativeCommons Attribution-ShareAlike (4.0) license [http://cre- ativecommons.org/licenses/by-sa/4.0/]. Version: 2.0 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? .................................................................................... vii Sources ................................................................................................................... vii Acknowledgements ................................................................................................... viii For the first edition (2005) ................................................................................ viii For the second edition (2017) ............................................................................... x Disclaimer .............................................................................................................. xiii 1. Introduction ...................................................................................................................
    [Show full text]
  • Social Dynamics of Free and Open Source Team Communications
    Social dynamics of free and open source team communications James Howison, Keisuke Inoue, and Kevin Crowston School of Information Studies Syracuse University Syracuse, USA {jhowison,kinoue,crowston}@syr.edu Abstract 1 This paper furthers inquiry into the social structure of free and open source software (FLOSS) teams by undertaking social network analysis across time. Contrary to expectations, we confirmed earlier findings of a wide distribution of centralizations even when examining the networks over time. The paper also provides empir- ical evidence that while change at the center of FLOSS projects is relatively uncommon, participation across the project communities is highly skewed, with many participants appearing for only one pe- riod. Surprisingly, large project teams are not more likely to undergo change at their centers. Keywords: Software Development, Human Fac- tors, Dynamic social networks, FLOSS teams, bug fixing, communications, longitudinal social network analysis 1 Introduction and Literature Review Free/Libre Open Source Software (FLOSS2) is a broad term used to em- brace software developed and released under an “open source” license allowing inspection, modification and redistribution of the software’s source without charge (“free as in beer”). Much though not all of this software is also “free software,” meaning that derivative works must be made available under the same unrestrictive license terms (“free as in speech”, thus “libre”). We study 1 Acknowledgement: This research was partially supported by NSF Grants 03– 41475, 04–14468 and 05–27457. Any opinions, findings, and conclusions or rec- ommendations expressed in this material are those of the authors and do not necessarily reflect the views of the National Science Foundation 2 The free software movement and the open source movement are distinct and have different philosophies but mostly common practices.
    [Show full text]
  • Red Hat Enterprise Linux 8 Managing, Monitoring and Updating the Kernel
    Red Hat Enterprise Linux 8 Managing, monitoring and updating the kernel A guide to managing the Linux kernel on Red Hat Enterprise Linux 8 Last Updated: 2019-11-05 Red Hat Enterprise Linux 8 Managing, monitoring and updating the kernel A guide to managing the Linux kernel on Red Hat Enterprise Linux 8 Legal Notice Copyright © 2019 Red Hat, Inc. The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/ . In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. Linux ® is the registered trademark of Linus Torvalds in the United States and other countries. Java ® is a registered trademark of Oracle and/or its affiliates. XFS ® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries. MySQL ® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
    [Show full text]
  • Software Process Maturity and the Success of Free Software Projects
    Software Process Maturity and the Success of Free Software Projects Martin MICHLMAYR Department of Computer Science and Software Engineering University of Melbourne Victoria, 3010, Australia 1 e-mail: [email protected] Abstract. The success of free software and open source projects has increased interest in utilizing the open source model for mature software development. However, the ad hoc nature of open source development may result in poor quality software or failures for a number of volunteer projects. In this paper, projects from SourceForge are assessed to test the hypothesis that there is a relationship between process maturity and the success of free software and open source projects. This study addresses the question of whether the maturity of particular software processes differs in successful and unsuccessful projects. Processes are identified that are key factors in successful free software projects. The insights gained from this study can be applied as to improve the software process used by free software projects. Keywords. Process maturity, quality improvement, free software, open source Introduction The development model employed in free software and open source projects is unique in many respects. Free software and open source projects are traditionally characterized by two factors that have an impact on quality and project management [8], [7]. The first factor is that they are performed by volunteers, the second that the participants are globally distributed. In addition to these two important characteristics, the development model is also crucially determined by the nature of free software and open source itself; all source code is available and shared with others. Raymond suggests that this open exchange leads to a high level of peer review and user involvement [11], [13].
    [Show full text]
  • A Brief History of Debian I
    A Brief History of Debian i A Brief History of Debian A Brief History of Debian ii 1999-2020Debian Documentation Team [email protected] Debian Documentation Team This document may be freely redistributed or modified in any form provided your changes are clearly documented. This document may be redistributed for fee or free, and may be modified (including translation from one type of media or file format to another or from one spoken language to another) provided that all changes from the original are clearly marked as such. Significant contributions were made to this document by • Javier Fernández-Sanguino [email protected] • Bdale Garbee [email protected] • Hartmut Koptein [email protected] • Nils Lohner [email protected] • Will Lowe [email protected] • Bill Mitchell [email protected] • Ian Murdock • Martin Schulze [email protected] • Craig Small [email protected] This document is primarily maintained by Bdale Garbee [email protected]. A Brief History of Debian iii COLLABORATORS TITLE : A Brief History of Debian ACTION NAME DATE SIGNATURE WRITTEN BY September 14, 2020 REVISION HISTORY NUMBER DATE DESCRIPTION NAME A Brief History of Debian iv Contents 1 Introduction -- What is the Debian Project? 1 1.1 In the Beginning ................................................... 1 1.2 Pronouncing Debian ................................................. 1 2 Leadership 2 3 Debian Releases 3 4 A Detailed History 6 4.1 The 0.x Releases ................................................... 6 4.1.1 The Early Debian Packaging System ..................................... 7 4.2 The 1.x Releases ................................................... 7 4.3 The 2.x Releases ................................................... 8 4.4 The 3.x Releases ................................................... 8 4.5 The 4.x Releases ..................................................
    [Show full text]
  • Understanding the Linux Virtual Memory Manager
    1 Understanding The Linux Virtual Memory Manager Mel Gorman 15th February 2004 Contents List of Figures 5 List of Tables 7 Acknowledgements 9 1 Introduction 12 1.1 General Kernel Literature . 13 1.2 Thesis Overview . 14 1.3 Typographic Conventions . 14 1.4 About this Document . 14 1.5 Companion CD . 15 2 Code Management 17 2.1 Managing the Source . 17 2.2 Getting Started . 23 2.3 Submitting Work . 24 3 Describing Physical Memory 26 3.1 Nodes . 27 3.2 Zones . 29 3.3 Pages . 31 3.4 High Memory . 33 4 Page Table Management 36 4.1 Describing the Page Directory . 37 4.2 Describing a Page Table Entry . 38 4.3 Using Page Table Entries . 39 4.4 Translating and Setting Page Table Entries . 42 4.5 Allocating and Freeing Page Tables . 42 4.6 Kernel Page Tables . 43 4.7 Mapping addresses to struct pages .................. 44 5 Process Address Space 47 5.1 Linear Address Space . 48 5.2 Managing the Address Space . 49 2 CONTENTS 3 5.3 Process Address Space Descriptor . 50 5.4 Memory Regions . 55 5.5 Exception Handling . 70 5.6 Page Faulting . 71 5.7 Copying To/From Userspace . 77 6 Boot Memory Allocator 80 6.1 Representing the Boot Map . 81 6.2 Initialising the Boot Memory Allocator . 81 6.3 Allocating Memory . 83 6.4 Freeing Memory . 85 6.5 Retiring the Boot Memory Allocator . 85 7 Physical Page Allocation 90 7.1 Managing Free Blocks . 90 7.2 Allocating Pages . 91 7.3 Free Pages .
    [Show full text]
  • FOSS Foundations Commonalities, Deficiencies, and Recommendations
    FOSS Foundations Commonalities, Deficiencies, and Recommendations Martin Michlmayr April 2021 Preface Background FOSS foundations are organizations (typically non-profit) that support open source projects in a number of ways. Aim This research studied FOSS foundations in order to better understand their role in con- tributing to the success and sustainability of open source projects. The aim is to better understand the operations and challenges FOSS foundations face and to find areas of improvement and collaboration. Topics This report covers topics such as: • Role and activities of foundations • Challenges faced and gaps in the service offerings • Operational aspects, including reasons for starting an org and choice of jurisdiction • Trends, such as the “foundation in a foundation” model • Recommendations for different stakeholders Target audience This report is targeted at those who are interested in better understanding the nature, role and operations of FOSS foundations; in particular, it’s aimed at those involved in running and those considering to create a FOSS foundation as well as those supporting such foundations (grant bodies, corporations, etc). Credits This work was sponsored by the Ford Foundation and the Alfred P. Sloan Foundation. 2 Contents Preface 2 Background . .2 Aim ...........................................2 Topics . .2 Target audience . .2 Credits . .2 FOSS foundations5 Classification . .5 Expanding role of foundations . .5 Diversity of organizations . .6 Limitation on technical influence . .6 Activities . .7 Sustainability . .8 Explicit restrictions . .9 Gaps...........................................9 Challenges . .9 Removing constraints . 10 Awareness . 10 Summary . 11 Incorporation 12 Reasons for creating an incorporated organization . 12 Jurisdiction and legal structure . 12 Starting a new organization . 13 Consolidation and the “foundation in a foundation” model .
    [Show full text]