Change blindness is the inability to detect changes that occur in a scene, when the scene is briefly obscured while the change happens. It has been found to occur during driving simulations and computer use for example. Scene-Complexity, stimulus On-Time and time for which a scene is obscured can all affect our ability to detect changes (or change blindness). In most studies parameters have been selected to induce change blindness with little consideration of the extent to which change blindness might be induced. There is however evidence that variables that describe the visual scene can affect likelihood of detecting changes (Rensink Visual Cognition 7:345–376, 2000 ). These effects have in this paper been explored in combination. Increasing Scene-Complexity, decreasing stimulus On-Time and increasing the duration for which a scene is obscured all increase change blindness but they all interact to further increase the likelihood of changes being missed. In order to reduce change blindness in a changing scene, all the variables need to be considered.

Medium-sized, open-participation Open Source Software (OSS) projects do not usually perform explicit software process improvement on any routine basis. It would be useful to understand how to get such a project to accept a process improvement proposal and hence to perform process innovation. We want to determine an effective and feasible qualitative research method for studying the above question. We present (narratively) a case study of how we worked towards and eventually found such a research method. The case involves four attempts at collecting suitable data about innovation episodes (direct participation (twice), polling developers for episodes, manually finding episodes in mailing list archives) and the adaptation of the Grounded Theory data analysis methodology. Direct participation allows gathering rather rich data, but does not allow for observing a sufficiently large number of innovation episodes. Polling developers for episodes did not prove to be useful. Using mailing list archives to find data to be analyzed is both feasible and effective. We also describe how the data thus found can be analyzed based on the Grounded Theory Method with suitable adjustments. By-and-large, our findings ought to apply to studying various phenomena in OSS development processes that are similarly heavyweight and infrequent. However, specific details may block this possibility and we cannot predict which details that might be. The amount of effort involved in direct participation approaches to qualitative research can easily be underestimated. Also, survey approaches are not well-suited for many process issues in OSS, because too few developers are sufficiently process-conscious. An approach based on passive observation is a viable alternative in the OSS context due to the availability of large amounts of fairly complete archival data.

Background: More and more software development companies decide to share their workload between teams which are geographically distributed. One of the biggest challenges is to start up work when new team members are introduced at a distant site of a global cooperation. Usually existing development processes do not cover integrating distributed collaboration, hence there is a need to adjust them to make project starts comfortable, easy and fast. A field study was conducted to introduce distributed pair programming (DPP), a derivative of pair programming (PP) in a distributed context, as a new development method to support communication and enhance knowledge transfer right from the beginning of the project. Objective: The objective of the study was to uncover relevant procedures and problems of establishing DPP and to collect supporting procedure steps for future project starts in distributed collaborations. Methods: A variation of canonical action research (CAR) was used to both establish DPP, gather insights and allow feedback from the developers involved. Results: This paper describes the establishment of DPP in a corporate project kick-off. It also reveals some benefits and major problems about distributed collaboration like conflicts in role fulfillment, ambiguity about session goals and missing awareness. Limitations: The validity of this study is threatened by the small number of participants and their particular cultural backgrounds.

This paper describes the social practice of distributed party programming as a natural extension of pair programming in a distributed context with two or more software developers working together. To this end we provide an overview of the Eclipse plug-in Saros, a software implementation supporting this practice, and explain its technical architecture. The central contribution of this paper is a detailed description of four concrete scenarios of distributed collaboration where one of them is distributed party programming. Furthermore it will be shown how each scenario is supported by Saros. The paper closes with a discussion of preliminary findings about establishing Saros in Open Source projects.

To learn how to introduce automated regression testing to existing medium scale Open Source projects, a long-term field experiment was performed with the Open Source project FreeCol. Results indicate that (1) introducing testing is both beneficial for the project and feasible for an outside innovator, (2) testing can enhance communication between developers, (3) signaling is important for engaging the project participants to fill a newly vacant position left by a withdrawal of the innovator. Five prescriptive strategies are extracted for the innovator and two conjectures offered about the ability of an Open Source project to learn about innovations.

Background: People contribute to OSS projects in wildly different degrees, from reporting a single defect once and never coming back to spending many hours each workday on the project over several years - or anything in between. It is a common conception that these degrees of participation sort the participants into a number of similar groups which are layered like the peels of an onion: The onion model. Objective: We check whether this model of gradually different degrees of participation is valid with respect to the participation in OSS project mailing-list traffic. Methods: We perform social network analysis based on replies to mailing-list messages and use visualization to check the nature of three different groups of participants. Results: There appears to be a discontinuity with respect to core members: The degree to which very active core members (as opposed to less active co-developers) react to e-mails of senders from the project's periphery is significantly higher than would be expected from their level of activity in general. Limitations: The effect might be an artifact of the assumption that each mailing-list message can be treated the same. Conclusions: We conclude that core member status may be qualitatively (rather than just quantitatively) different and the transition of individual mailing-list participants towards ever higher participation is qualitatively discontinuous.

This document provides an overview of the progress made with my research into the introduction of innovation between May and September 2008. It continues where the first milestone [49] left off and discusses first the methodical advances regarding Grounded Theory methodology. Second, it presents the first set of results regarding the introduction of innovation such as the concepts of hosting, partial migration, enactment scopes, adapter innovations and decision making. Lastly, it closes with ideas about how to conclude this dissertation.

The public visibility of Free and Open Source Software development has sparked interest in the research communities of business, social and computer sciences to use the projects as research subjects. This article tries to open a discussion about the implications of this interest, whether the Free and Open Source communities appreciate being under “surveillance” and how we can deal with the ethical problems related to the human subject research.

Globally distributed teams of volunteers and communication by electronic means are at the core of Open Source Software development. To help projects in managing their information, we defined a lightweight , role-based process improvement and observed its use in a longitudinal case study. Results gathered by mailing-list analysis give insights into the different types of information managed and their relative importance: While technical content such as how-tos and to-dos is most frequent, the amount of information regarding decision making is surprisingly low.

This document provides an overview of the current state of my research into the introduction of innovation as of April 2008.

Die im folgenden vorgestellte Diplomarbeit legt den theoretischen Rahmen fur die verteilte Paarprogrammierung als Weiterentwicklung der klassischen Paarprogrammierung und beschreibt die Implementierung eines entsprechenden EclipsePlugins. Ein besonderes Augenmerk lag darin sinnvolle und realistische Anforderungen zu erarbeiten. Die Daten der Literaturanalyse wurden dazu mittels einer eigenen Umfrage unter Entwicklern erganzt. Die Arbeit wurde von Riad Djemili durchgefuhrt und von Christopher Oezbek und Stephan Salinger als Forschungsprojekt der Arbeitsgruppe Software-Engineering am Institut fur Informatik der Freien Universitat Berlin betreut. 1 Paarprogrammierung Paarprogrammierung (PP) bezeichnet eine Arbeitstechnik, bei der zwei Programmierer an einem Computer gemeinsame Artefakt (meist Code) bearbeiten [WKCJ00]. Man unterscheidet dabei zwei Rollen: Der Driver bearbeitet die Artefakte aktiv mit Maus und Tastatur, wahrend der Observer die Eingaben kontrolliert und bei Entwurfsentscheidungen berat. Im Verlauf einer Sitzung kann die Rollenverteilung mehrmals wechseln. PP ist vor allem als Praktik des Extreme Programming (XP) bekannt geworden [Bec99]. Ziele von PP sind die Defektreduzierung, verbesserter Entwurf, Wissensaustausch und schnellere Produktentwicklung. Kritisiert wird jedoch haufig der Kostenaspekt und der Bedarf an raumlicher Nahe und geraumigen Arbeitsplatzen [Nos98]. Befurworter der PP betonen hingegen, dass die eventuell hoheren Kosten vor allem durch die verbesserte Codequalitat, mehr als kompensiert werden [WKCJ00]. 2 Verteilte Paarprogrammierung Bei der verteilten Paarprogrammierung (engl. distributed pair programming, DPP) findet die gleichzeitige und gemeinsame Bearbeitung des Artefakts von verschiedenen Arbeitsplatzen aus statt [SS01]. Diese allgemeine Definition ermoglicht unterschiedliche Umsetzungen in der Praxis: Mussen nur Textanderungen ubertragen werden oder auch Dateioperationen? Ist die Ubertragung von Gestiken und Gesichtsausdrucken per Video notwendig? Sollte der Observer sich vom Sichtbereich des Drivers losen durfen? Ein Vorteil von DPP ist die Unterstutzung virtueller Teams, welche Software-Entwicklung bei raumlicher Trennung betreiben und in erster Linie mittels elektronischer Medien kommunizieren. In der Open-Source-Entwicklung stellen diese Teams den Normalfall dar. Wahrend bei PP der Driver den Aufmerksamkeitsbereich des Paares bestimmt, identifizieren wir bei verteilter Paarprogrammierung drei Grade von Parallelitat: Parallelitat auf Programmebene: Der Observer kann das Fenster des DPP-Werkzeugs in den Hintergrund rucken, um mit anderen Programmen zu interagieren. Parallelitat auf Sichtebene: Der Observer kann von dem Aufmerksamkeitsbereich des Drivers abweichen und eigenstandig im gemeinsamen Projekt lesen. Parallelitat auf Schreibebene: Es gibt mehr als einen Driver, das heist mehrere Personen konnen gleichzeitig in dem Projekt schreiben. Dabei ist zu beachten, dass mit steigender Parallelitat die ursprunglich postulierten Vorteile der PP, z.B. die aus der stetigen Durchsicht resultierende Qualitatsverbesserung, verloren gehen konnen. Insofern bleibt zu untersuchen, welcher Grad an Parallelitat noch zu einer Effizienzund Qualitatssteigerung beitragen kann und ab wann diese kontraproduktiv wirkt. Eine weitere Kritik an DPP richtet sich gegen die eingeschrankten Moglichkeiten fur den Observer die Aktivitaten des Drivers nachzuvollziehen (engl. awareness), z.B. anhand von Sprache und Gestik. 3 Technische Werkzeugansatze Der Forschungsbereich der Computer Supported Cooperative Work (CSCW) unterscheidet im Wesentlichen zwei Implementierungsansatze [Han05]. Beim Desktop Sharing wird die Ansicht einer Arbeitsflache uber ein Netzwerk auf den Schirm eines oder mehrerer anderer Systeme ubertragen, haufig zum Zweck von Fernadministration oder Demonstrationen. Vorteilhaft an diesem Ansatz ist, dass Werkzeuge, die in der DPP-Sitzung verwendet werden, nicht speziell angepasst werden mussen. Der im Rahmen der Diplomarbeit favorisierter Ansatz ist die Collaboration Awareness, bei der die Mehrbenutzer-Unterstutzung unmittelbar in das Werkzeug integriert wird. Von Vorteil ist hier, dass das Werkzeug durch das Verstehen des Kontextes unterstutzende PP-Funktionalitaten anbieten kann (beispielsweise eine Historie der letzten Aktionen des Drivers) und zudem einen hoheren Grad an Parallelitat erlaubt. Zudem leidet dieser Ansatz nicht unter den technischen Restriktionen des Desktop Sharing: Es gibt keine Probleme mit abzustimmenden Auflosungen oder geringen Bildwiederholraten.

Wir berichten von zwei ahnlichen Softwaretechnikpraktika mit Schwerpunkt Qualitatssicherung. In der ersten Version wurde ein freies Softwaresystem entlang wochentlicher Ubungsblatter hinsichtlich Qualitatsmangel untersucht. Im Kontrast zu diesem sehr angeleiteten Vorgehen gab es in der zweiten Version lediglich die eine Zielvorgabe, moglichst viele Schwachstellen zu finden. Der Weg dorthin blieb den Studierenden uberlassen. Im Vergleich der beiden Durchfuhrungen ergab sich eine hohere fachliche Erfolgsquote in der zweiten Version, aber auch eine grosere Unzufriedenheit mit dem Ergebnis bei den Studierenden. Wichtiger als dies, deckte die zweite Durchfuhrung Schwachen, aber auch Lernfortschritte bei einem unerwarteten und wichtigen Thema auf: Der Arbeitsmethodik der Studierenden.

nuestra propuesta trata de investigar la introduccion de nuevas tecnologias o innovaciones en el campo de la ingenieria del software en proyectos basados en software libre, (1) para ayudar a los investigadores a evaluar sus herramientas, metodologia y diseno de procesos en el mundo real, y (2) para contribuir a que los proyectos basados en Software Libre mejoren sus metodos de trabajo gracias a conocimientos mas modernos e innovadores. Esta investigacion tratara de ir mas alla de la simple difusion de la innovacion, adentrandonos en una introduccion activa, para aumentar las posibilidades de que el proyecto adopte la nueva tecnologia. Tambien hablaremos de la metodologia seguida en nuestra investigacion, nuestros primeros resultados, las limitaciones de nuestra metodologia y por que los investigadores interesados en evaluar sus propias innovaciones deberian leer este estudio.

Many small and medium-sized systems have little or no design documentation, which makes program understanding during maintenance enormously more difficult when performed by outsiders. Thus, if only minimal design documentation is available, which form should it take to maximize its usefulness? We suggest that it is helpful if the documentation describes a tour through the source code, leading the user directly to relevant details. This work reports an evaluation of this conceptual idea in the form of a controlled experiment with 59 student subjects working on a difficult program understanding task in the context of the 27 KLOC JHotDraw graphics framework. One group received a plain text documentation, the other received tour-structured documentation which they navigated by using an Eclipse plugin called JTourBus that we constructed for the experiment. The results indicate that program understanding can be achieved somewhat faster (albeit not more correctly) with JTourBus than with a plain text document.

We propose to research the introduction of Software Engineering inventions into Open Source projects (1) to help researchers with creating opportunities for evaluating their tools, methods and process designs in real-life settings, and (2) to help Open Source projects with improving their processes based on state-of-the-art knowledge. Such research will go beyond diffusion and dissemination of inventions to active introduction, and thus increase the chances of adoption. We will discuss the research approach, our preliminary insights, limitations of the approach, and why researchers interested in evaluating their own inventions should be interested in this research.

The growing importance of the Open Source development paradigm for industry and public institutions leads to the question of how the efficiency and productivity of projects under this paradigm can be improved. The notable difference to a process improvement effort in an industrial setting (for instance using the CMMI), is the collaborative nature of the project: the absence of hierarchical power makes it impossible to drive change in a top-down fashion. This on-going Ph.D. thesis seeks to provide a thorough understanding of the mechanisms for introducing tool and process improvements into OSS projects from the perspective of the individual stakeholders to increase the success chances of their improvement efforts.