DOCSLIB.ORG

Using Software Archaeology to Measure Knowledge Loss in Software Projects Due to Developer Turnover ∗

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Using Software Archaeology to Measure Knowledge Loss in Software Projects Due to Developer Turnover ∗ Proceedings of the 42nd Hawaii International Conference on System Sciences - 2009 Using Software Archaeology To Measure Knowledge Loss in Software Projects Due To Developer Turnover ∗ Daniel Izquierdo-Cortazar, Gregorio Robles, Felipe Ortega and Jesus M. Gonzalez-Barahona GSyC/LibreSoft Universidad Rey Juan Carlos (Madrid, Spain) dizquierdo, grex, jfelipe, jgb @gsyc.escet.urjc.es { } Abstract The lifespan of a software system can range from sev- eral years to decades. In such scenarios, the develop- Developer turnover can result in a major problem ment team in charge of the software may suffer from when developing software. When senior developers turnover: old developers leave while new developers abandon a software project, they leave a knowledge gap join the project. With the abandonment of old, senior that has to be managed. In addition, new (junior) devel- developers, projects lose human resources experienced opers require some time in order to achieve the desired both with the details of the software system and with the level of productivity. In this paper, we present a method- organizational and cultural circumstances of the project. ology to measure the effect of knowledge loss due to de- New developers will need some time to become famil- veloper turnover in software projects. For a given soft- iar with both issues. In this regard, the time for volun- ware project, we measure the quantity of code that has teers to become core contributors to FLOSS 1 projects been authored by developers that do not belong to the has been measured to be 30 months in mean, since their current development team, which we define as orphaned first contribution [11]. code. Besides, we study how orphaned code is managed Although maintaining the current development team by the project. Our methodology is based on the concept could be thought as a plausible solution to mitigate of software archaeology, a derivation of software evolu- this problem, turnover is usually unavoidable. Being tion. As case studies we have selected four FLOSS (free, a highly intellectual work, developers have a tendency libre, open source software) projects, from purely driven to lose the original motivation on the software system as by volunteers to company-supported. The application time passes by, and they have the natural desire to search of our methodology to these case studies will give in- for new objectives. In this sense, high turnovers have sight into the turnover that these projects suffer and how been observed in most large FLOSS projects, where sev- they have managed it and shows that this methodology eral generations of successive development teams have is worth being augmented in future research. been identified [21]. Although these environments are Keywords: developer turnover, orphaning, software partially, if not mostly, driven by volunteers, turnover in risk management, software archaeology industrial environments is also high. In this paper, we present a methodology to measure the effect of developer turnover in software projects. It 1. Introduction is based on quantifying the knowledge that developers contribute to a project based on the number of lines of code written for it. In case developers leave, their lines Software development is an activity intense in hu- become orphaned.Theamountoforphaned lines can man resources. The work of many developers is re- be considered as a measure of the knowledge that the quired to create almost any non-trivial piece of code. 1Through this paper we will use the term FLOSS to refer to “free, ∗This work has been funded in part by the European Commission, libre, open source software”, including code that conforms either to the under the FLOSSMETRICS (FP6-IST-5-033547), QUALOSS (FP6- definition of “free software” (according to the Free Software Founda- IST-5-033547) and QUALIPSO (FP6-IST-034763) projects, and by tion) or “open source software” (according to the Open Source Initia- the Spanish CICyT, project SobreSalto (TIN2007-66172). tive). 978-0-7695-3450-3/09 $25.00 © 2009 IEEE 1 Proceedings of the 42nd Hawaii International Conference on System Sciences - 2009 project has lost with the abandonment of developers. chapters are devoted to the management of such issues. Hence, orphaned lines constitute a legacy of past devel- Developer turnover is one of the most important factors opers. As the amount of orphaned lines increases, the to be considered. Nonetheless, in the editors notice of a project may become more obscure to the current devel- special issue on software risk management [2], Boehm opment team, since major parts of the code were written and DeMarco state that “Indian software managers re- by developers who are no longer available. vealed that they perceived personnel turnover as their Our methodology can be useful to determine the biggest source of risk”. A questionnaire addressed by knowledge that the current development team has about Otte [18] shows that around a 12% of the total SLOCs the software system. This is specially interesting in in average is abandoned code. He demonstrated that the case of software maintenance, a non-trivial task projects with high levels of abandoned code tend to re- that accumulates over 80% of total activity in software port more bugs. projects [3]. In our vision, projects with a high share of Beyond pure industrial settings, recent research has orphaned lines have an inferior starting position, since focused on this issue in the case of FLOSS projects. they need to maintain code authored by others. Mockus et al. identified that in FLOSS projects a small, We have applied our methodology to several FLOSS but very active number of developers perform a large projects. Among them there are some led by companies, part of the software development; they labelled this following development models which can be considered group as the core group [16]. Robles et al. studied similar to those of non-FLOSS software development. the composition of the core group for several FLOSS Therefore results can (in part) be extended to traditional projects over time and found that only a minority of software development. However, the methodology is es- projects shown a stable core group for many years [21]. pecially interesting for FLOSS projects, since the de- Most projects showed a pattern where generations of de- scriptive information obtained can be of great interest velopers successively take the lead for a limited amount for decision-making developers. It should be noted that of time, generally in the range of two to four years. regarding in-house development, companies may have Michlmayr et al. introduced the measure of half-life for much more knowledge over projects they manage di- the human resources of a project [15]. They analyzed the rectly. Nonetheless, in the FLOSS world, where devel- population of developers participating in a project and opment is performed following distributed, highly dy- identified the point in time when only half of them are namic patterns, and involving volunteers, gaining insight still active. In the case of Debian, the half-life observed into a project is a major issue. was 7.5 years. However, other studies have pointed The structure of this paper is as follows. Next sec- out that packages maintained by Debian developers who tion presents related research. The third section intro- abandoned the project were later maintained by others, duces our methodology, based on extracting authorship showing a natural “regeneration” process [22]. information by mining the source control management system of software projects. We also highlight the new In general, developers who leave a project some- aspects that software archaeology introduces in research how carry with them their knowledge about it. If that on software maintenance and evolution. The fourth sec- knowledge is not shared with other developers, it can tion gives some insight into the four FLOSS projects that be considered as disappearing from the project. How to have been selected as case studies, while the fifth one characterize that knowledge is a common case of study. shows the results of applying our methodology on them. Hutchison [13] concludes that “The knowledge system Then, the methodology is discussed in detail, as well as is not the individual but the entire history of problem current limitations and challenges that further research solving teams in which individuals actively participate”. may target are also presented. Finally, conclusions are Ge et al., focusing on FLOSS projects, state that the ex- drawn in the last section. pertise is not centered in just one member [7]. They conclude that no single member is the owner of the whole knowledge, even for specific parts of the code. 2. Related research However it is a challenge to recover all this expertise (knowledge) when developers leave, because it is usu- Risk management during the software development ally not recorded anywhere. In the case of FLOSS and maintenance process has been a matter of research projects, it is recorded only in part, in mailing lists for a long time [1]. Some of the risks affecting soft- archives, source code management or bug tracking sys- ware development are related to human resources. In tems, where source code, new ideas or comments are DeMarco and Lister’s classic Peopleware [4], several registered. All this common knowledge can help the 2 Proceedings of the 42nd Hawaii International Conference on System Sciences - 2009 “regeneration” of knowledge once a given developers time, as the software experiments further changes. leaves. The life of orphaned lines is different depending on German observed empirically that developers have what is happening in the project. For instance, if de- a tendency to work on specific parts of their software velopers are focused on adding new functionality, it is project, so that it is easy to determine the files in which likely that orphaned lines are only seldom touched.
Load more

Recommended publications
  • What Every Engineer Should Know About Software Engineering
    7228_C000.fm Page v Tuesday, March 20, 2007 6:04 PM WHAT EVERY ENGINEER SHOULD KNOW ABOUT SOFTWARE ENGINEERING Phillip A. Laplante Boca Raton London New York CRC Press is an imprint of the Taylor & Francis Group, an informa business © 2007 by Taylor & Francis Group, LLC 7228_C000.fm Page vi Tuesday, March 20, 2007 6:04 PM CRC Press Taylor & Francis Group 6000 Broken Sound Parkway NW, Suite 300 Boca Raton, FL 33487-2742 © 2007 by Taylor & Francis Group, LLC CRC Press is an imprint of Taylor & Francis Group, an Informa business No claim to original U.S. Government works Printed in the United States of America on acid-free paper 10 9 8 7 6 5 4 3 2 1 International Standard Book Number-10: 0-8493-7228-3 (Softcover) International Standard Book Number-13: 978-0-8493-7228-5 (Softcover) This book contains information obtained from authentic and highly regarded sources. Reprinted material is quoted with permission, and sources are indicated. A wide variety of references are listed. Reasonable efforts have been made to publish reliable data and information, but the author and the publisher cannot assume responsibility for the validity of all materials or for the conse- quences of their use. No part of this book may be reprinted, reproduced, transmitted, or utilized in any form by any electronic, mechanical, or other means, now known or hereafter invented, including photocopying, microfilming, and recording, or in any information storage or retrieval system, without written permission from the publishers. For permission to photocopy or use material electronically from this work, please access www.
    [Show full text]
  • Third Party Terms for Modular Messaging 3.0 (July 2005)
    Third Party Terms for Modular Messaging 3.0 (July 2005) Certain portions of the product ("Open Source Components") are licensed under open source license agreements that require Avaya to make the source code for such Open Source Components available in source code format to its licensees, or that require Avaya to disclose the license terms for such Open Source Components. If you are a licensee of this Product, and wish to receive information on how to access the source code for such Open Source Components, or the details of such licenses, you may contact Avaya at (408) 577-7666 for further information. The Open Source Components are provided “AS IS”. ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR THE CONTRIBUTORS OF THE OPEN SOURCE COMPONENTS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THE PRODUCT, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Avaya provides a limited warranty on the Product that incorporates the Open Source Components. Refer to your customer sales agreement to establish the terms of the limited warranty. In addition, Avaya’s standard warranty language as well as information regarding support for the Product, while under warranty, is available through the following web site: http://www.avaya.com/support.
    [Show full text]
  • A Brief History of GNOME
    A Brief History of GNOME Jonathan Blandford <[email protected]> July 29, 2017 MANCHESTER, UK 2 A Brief History of GNOME 2 Setting the Stage 1984 - 1997 A Brief History of GNOME 3 Setting the stage ● 1984 — X Windows created at MIT ● ● 1985 — GNU Manifesto Early graphics system for ● 1991 — GNU General Public License v2.0 Unix systems ● 1991 — Initial Linux release ● Created by MIT ● 1991 — Era of big projects ● Focused on mechanism, ● 1993 — Distributions appear not policy ● 1995 — Windows 95 released ● Holy Moly! X11 is almost ● 1995 — The GIMP released 35 years old ● 1996 — KDE Announced A Brief History of GNOME 4 twm circa 1995 ● Network Transparency ● Window Managers ● Netscape Navigator ● Toolkits (aw, motif) ● Simple apps ● Virtual Desktops / Workspaces A Brief History of GNOME 5 Setting the stage ● 1984 — X Windows created at MIT ● 1985 — GNU Manifesto ● Founded by Richard Stallman ● ● 1991 — GNU General Public License v2.0 Our fundamental Freedoms: ○ Freedom to run ● 1991 — Initial Linux release ○ Freedom to study ● 1991 — Era of big projects ○ Freedom to redistribute ○ Freedom to modify and ● 1993 — Distributions appear improve ● 1995 — Windows 95 released ● Also, a set of compilers, ● 1995 — The GIMP released userspace tools, editors, etc. ● 1996 — KDE Announced This was an overtly political movement and act A Brief History of GNOME 6 Setting the stage ● 1984 — X Windows created at MIT “The licenses for most software are ● 1985 — GNU Manifesto designed to take away your freedom to ● 1991 — GNU General Public License share and change it. By contrast, the v2.0 GNU General Public License is intended to guarantee your freedom to share and ● 1991 — Initial Linux release change free software--to make sure the ● 1991 — Era of big projects software is free for all its users.
    [Show full text]
  • Software Development Process for Teams with Low Expertise, High-Rotation and No- Architect: a Systematic Mapping Study
    Software Development Process for Teams with Low Expertise, High-Rotation and No- Architect: A Systematic Mapping Study Paulina Valencia Franco Angelina Espinoza, Humberto Cervantes Maceda Electrical Engineering Department, Electrical Engineering Department, Universidad Autónoma Metropolitana Universidad Autónoma Metropolitana Iztapalapa, México Iztapalapa, México Email: paulatina63 –at- gmail.com Email: aespinoza, hcm -at- xanum.uam.mx Abstract —To have a well-organized software team is Process) [1], TSP (Team Software Process) [2], PSP (Personal fundamental to achieve the business goals in a software Software Process) [3], XP (Extreme Programming) [4] or development project, such as: functionality and quality in the SCRUM [5]. planned times. However, the teams present a particular problematic that are common in both industrial and academic These methodologies, for their nature, are more or less settings, this paper focuses on three: a) Teams with members prepared to face the team features previously mentioned, but with low expertise on methodologies, b) Teams with high member the real big challenge is to combine these models, to get an rotations, or c) Teams lacking a software architect. One adapted process model for overcoming all the three previous approach to address this situation is to define a software features in development teams. Particularly, these kinds of development process, adapted from the adaptability teams are commonly found in academic environments where characteristics and benefits offered by several methodologies there are not resources to hire a technical leader, nor currently used, in order that the development team obtains the experienced staff, so that development teams are mainly expected results in terms of productivity, time and quality of the comprised of students who are in constant rotation.
    [Show full text]
  • Adapting the Harris Matrix for Software Stratigraphy
    Adapting the Harris Matrix for Software Stratigraphy Andrew Reinhard Edward Harris’s (1979) landmark work, Principles of preservation of these born-digital archaeological Archaeological Stratigraphy, from which sprouted sites. the idea and practice of the Harris matrix, became This is not a new concern for people who work within the broad my windmill (or albatross) in 2017 as I attempted to umbrella of “digital humanities.” “Software archaeology”—the leverage its data visualization technique onto a digital attempt to reverse-engineer poorly documented (or undocu- mented) software in order to restore and preserve functionality— archaeological site. This visualization would not only has existed formally for over 15 years.1 Digital preservation is allow archaeologists to understand the composition also not a new idea and forms a border of software archaeology; namely, what to do with software post-use or post-“excavation.”2 and history of a digital built environment—something None of the software archaeology approaches, however, treat important to the emerging field of digital heritage— software as archaeological sites in the traditional sense, and I wanted to see what would happen if I conducted a truly archaeo- but also would contribute to the conservation and logical investigation of a software application using a tool known ABSTRACT In 1979, Edward C. Harris invented and published his eponymous matrix for visualizing stratigraphy, creating an indispensable tool for generations of archaeologists. When presenting his matrix, Harris also detailed his four laws of archaeological stratigraphy: superposition, original horizontal, original continuity, and stratigraphic succession. In 2017, I created the first stratigraphic matrix for software, using as a test the 2016 video game No Man’s Sky (Hello Games).
    [Show full text]
  • Software Preservation Benefits Framework
    Software Preservation Benefits framework CC443D006-1.0 7 December 2010 Cover + 74 pages Neil Chue Hong Steve Crouch Simon Hettrick Tim Parkinson Matt Shreeve Software Sustainability Institute Curtis+Cartwright Consulting Ltd The University of Edinburgh Main Office: Surrey Technology Centre, Registered in England: number 3707458 James Clerk Maxwell Building Surrey Research Park, Guildford Mayfield Road Surrey GU2 7YG Registered address: Edinburgh EH9 3JZ Baker Tilly, The Clock House, tel: +44 (0)1483 685020 140 London Road, Guildford, tel: +44 (0) 131 650 5030 fax: +44 (0)1483 685021 Surrey GU1 1UW email: [email protected] email: [email protected] web: http://www.software.ac.uk web: http://www.curtiscartwright.co.uk Summary of framework 1 An investigation of software preservation has been carried out by Curtis+Cartwright Consulting Limited, in partnership with the Software Sustainability Institute (SSI), on behalf of the JISC.1 The aim of the study was to raise awareness and build capacity throughout the Further and Higher Education (FE/HE) sector to engage with preservation issues as part of the process of software development. Part of this involved examining the purpose and benefits of employing preservation measures in relation to software, both at the development stage and retrospectively to legacy software. The study built on the JISC-funded ‘Significant Properties of Software’ study2 that produced an excellent introduction and comprehensive framework to software preservation. 2 This is a framework document that assists developer groups and their sponsoring bodies to understand and gauge the benefits or disbenefits of allocating effort to: – ensuring that preservation measures are built into software development processes; – actively preserving legacy software.
    [Show full text]
  • Sustainable Software Development Through Overlapping Pair Rotation Todd Sedano Paul Ralph Cécile Péraire
    Carnegie Mellon University From the SelectedWorks of Cécile Péraire September, 2016 Sustainable Software Development through Overlapping Pair Rotation Todd Sedano Paul Ralph Cécile Péraire Available at: https://works.bepress.com/cecile_peraire/35/ Sustainable Software Development through Overlapping Pair Rotation Todd Sedano Paul Ralph Cécile Péraire Pivotal University of Auckland Carnegie Mellon Unveristy 3495 Deer Creak Road Auckland Silicon Valley Campus Palo Alto, CA New Zealand Moffett Field, CA 94035, USA [email protected] [email protected] [email protected] ABSTRACT Keywords Context: Conventional wisdom says that team disruptions Extreme Programming, Grounded Theory, Code ownership, (like team churn) should be avoided. However, we have ob- Sustainable software development served software development projects that succeed despite high disruption. 1. INTRODUCTION Objective: The purpose of this paper is to understand Imagine being a software development manager when one how to develop software effectively, even in the face of team of your top engineers, Dakota, gives notice and is moving on disruption. to a new job opportunity. You are simultaneously excited Method: We followed Constructivist Grounded Theory. because the new position provides a great career opportu- We conducted participant-observation of several projects at nity for someone you respect, yet distressed that her depar- Pivotal (a software development company), and interviewed ture may exacerbate your own project. How will the team 21 software engineers, interaction designers, and product overcome this disruption? Your investment in this engineer managers. The researchers iteratively sampled and analyzed and her entire accumulated knowledge about the project is the collected data until achieving theoretical saturation. evaporating. Dakota developed some of the systems' tricki- Results: This paper introduces a descriptive theory of Sus- est, most important components.
    [Show full text]
  • Software Guide the Computer with Growth Potential
    February 1980 Volume 3 Issue 2 NEW: Professional software guide The computer with growth potential The System Three is Cromemco's best selling small business computer. It's easy to see why. Not only is it ideal for the first time computer user. But perhaps more important, it can be expanded into a comprehensive business facility servicing many varied company requirements. Single -user system You can start small. A 64K computer with a megabyte of floppy disc storage costs under £4,000.* Perhaps your initial reason for choosing Cromemco was its flexible database management system-ideal for client records, order processing, sales analysis, inventory control, and many more business uses; or you might have required the full screen word processing system, capable of printing up to 20 original letters an hour; possibly you needed Cobol, Basic or Fortran to develop your own customised packages. Single -user System Three, with 64K memory, 2 discs, terminal and printer. Easy to use Ideal for small businesses. Whatever the reason, you were highly impressed with the ease with which your Will it expand? Multi-user system very first computer application got off the It was then you discovered that the Fortunately, we can readily expand your ground. So you added another. And terminal is the limiting factor, because ofCromemco. Unlike other makers' systems, another. And pretty soon quite a lot of the time taken to input data. If only you all we need to do is add some memory and a company business was running on your could connect a second terminal you ®TU-ART interface, and the multi-user Cromemco.
    [Show full text]
  • Table of Contents
    A Comprehensive Introduction to Vista Operating System Table of Contents Chapter 1 - Windows Vista Chapter 2 - Development of Windows Vista Chapter 3 - Features New to Windows Vista Chapter 4 - Technical Features New to Windows Vista Chapter 5 - Security and Safety Features New to Windows Vista Chapter 6 - Windows Vista Editions Chapter 7 - Criticism of Windows Vista Chapter 8 - Windows Vista Networking Technologies Chapter 9 -WT Vista Transformation Pack _____________________ WORLD TECHNOLOGIES _____________________ Abstraction and Closure in Computer Science Table of Contents Chapter 1 - Abstraction (Computer Science) Chapter 2 - Closure (Computer Science) Chapter 3 - Control Flow and Structured Programming Chapter 4 - Abstract Data Type and Object (Computer Science) Chapter 5 - Levels of Abstraction Chapter 6 - Anonymous Function WT _____________________ WORLD TECHNOLOGIES _____________________ Advanced Linux Operating Systems Table of Contents Chapter 1 - Introduction to Linux Chapter 2 - Linux Kernel Chapter 3 - History of Linux Chapter 4 - Linux Adoption Chapter 5 - Linux Distribution Chapter 6 - SCO-Linux Controversies Chapter 7 - GNU/Linux Naming Controversy Chapter 8 -WT Criticism of Desktop Linux _____________________ WORLD TECHNOLOGIES _____________________ Advanced Software Testing Table of Contents Chapter 1 - Software Testing Chapter 2 - Application Programming Interface and Code Coverage Chapter 3 - Fault Injection and Mutation Testing Chapter 4 - Exploratory Testing, Fuzz Testing and Equivalence Partitioning Chapter 5
    [Show full text]
  • About This Particular Macintosh 6.03
    Cover ATPM About This Particular Macintosh™ 6.03: About the personal computing experience™ Volume 6, Number 3 March 1, 2000 Sign up for free subscriptions at: http://www.atpm.com/subscribe or send email to: [email protected] ATPM 6.03 ←→1 Cover Cover Art Copyright © 2000 David Knopfler david@knopfler.com http://www.knopfler.com We need new cover art every month! Write to us! Contributors Eric Blair Daniel Chvatik Paul Fatula Scott Feldstein Matthew Glidden Edward Goss Lisa Haller Tom Iov ino Nick Kratz Robert Paul Leitao William Lovett Colin Mansfield Jamie McCornack Grant Osborne David Ozab David Spencer Michael Tsai Christopher Turner Macintosh users like you Please write for ATPM! Check out the FAQ. Editorial Staff Publisher/Editor-in-Chief - Michael Tsai Managing Editor - Daniel Chvatik Associate Editor/Reviews - Paul Fatula ATPM 6.03 ←→2 Cover Associate Editor/Shareware Reviews - William Lovett Copy Editors - Raena Armitage Johann Campbell Paul Fatula Brooke Smith Adam Zaner Publicity Manager - Christopher Turner Contributing Editor/Welcome - Robert Paul Leitao Contributing Editors/Opinion - Tom Iovino Scott Feldstein Contributing Editors/Reviews - Eric Blair Evan Trent Vac a nt Contributing Editor/How To’s & Reviews - Jamie McCornack Contributing Editor/Trivia - Edward Goss Contibuting Editor/Music - David Ozab Contributing Editor/Networking - Matthew Glidden Contributing Editor/Web - David Spencer Help Jedi - Christopher Turner Hollywood Guy - Mike Shields Webmaster - Michael Tsai Assistant Webmaster - A. Lee Bennett Interviews
    [Show full text]
  • Archaeology of the Amsterdam Digital City; Why Digital Data Are Dynamic and Should Be Treated Accordingly
    UvA-DARE (Digital Academic Repository) Archaeology of the Amsterdam digital city; why digital data are dynamic and should be treated accordingly Alberts, G.; Went, M.; Jansma, R. DOI 10.1080/24701475.2017.1309852 Publication date 2017 Document Version Final published version Published in Internet Histories: Digital Technology, Culture and Society License CC BY-NC-ND Link to publication Citation for published version (APA): Alberts, G., Went, M., & Jansma, R. (2017). Archaeology of the Amsterdam digital city; why digital data are dynamic and should be treated accordingly. Internet Histories: Digital Technology, Culture and Society , 1(1-2), 146-159 . https://doi.org/10.1080/24701475.2017.1309852 General rights It is not permitted to download or to forward/distribute the text or part of it without the consent of the author(s) and/or copyright holder(s), other than for strictly personal, individual use, unless the work is under an open content license (like Creative Commons). Disclaimer/Complaints regulations If you believe that digital publication of certain material infringes any of your rights or (privacy) interests, please let the Library know, stating your reasons. In case of a legitimate complaint, the Library will make the material inaccessible and/or remove it from the website. Please Ask the Library: https://uba.uva.nl/en/contact, or a letter to: Library of the University of Amsterdam, Secretariat, Singel 425, 1012 WP Amsterdam, The Netherlands. You will be contacted as soon as possible. UvA-DARE is a service provided by the library of the University of Amsterdam (https://dare.uva.nl) Download date:28 Sep 2021 INTERNET HISTORIES, 2017 VOL.
    [Show full text]
  • GNOME Annual Report 2008
    1 Table of Contents Foreword Letter from the Executive Director 4 A year in review GNOME in 2008 8 GNOME Mobile 16 Events and Community initiatives Interview with Willie Walker 20 GNOME around the world 24 GNOME Foundation Foundation Finances 30 List of all 2008 donors 33 2 Letter from Stormy Peters Stormy Peters is the GNOME Foundation Executive Director and has great experience in the industry and with the open source culture. Hello GNOME Lovers! seek them out and to invite them to come play. (Actually, I felt welcome from day -1, GNOME's goal is to bring free and open as I met a bunch of guys on the plane who source computing to everyone regardless of turned out to also be going to GUADEC. I ability. I consider myself extremely lucky to spent my first day in Copenhagen walking have joined the project as executive director around with some guys from Red Hat and of the GNOME Foundation. It's a pleasure Eazel trying to stay awake through jetlag. I and a privilege to work with thousands of pe- remember Havoc Pennington saying we just ople dedicated to making free had to stay awake until dinner software available for everyone The spirit and time.) on desktops and mobile plat- dedication of the forms. I don't think it's an GNOME community to One of the most common exaggeration to say that their goals of creating questions I get asked is GNOME technology is chan- a free and open source why did you take this job? ging the world for many from software ..
    [Show full text]