Influence Of Developer Sentiment And Stack Overflow Developers On Open Source Project Success: An Empirical Examination

The collaborative effort of software developers around the world produces Open Source Software (OSS) products, and most importantly, the source code of the software product is shared publicly. A recent survey of 1300 IT professionals by Black Duck Software showed that the percentage of companies using open source software grew from 42% to 78% between 2010 and 2015. There has been a significant increase in the formation of self-organizing virtual teams to produce open source software products and services. The current literature does not address the factors affecting the success of open source projects through the lens of self-organizing virtual teams and the sentiment among the developers and the sentiment among software developers. This phenomenon suggests a need to understand how successful project teams are created in a virtual collaborative environment. This research investigates how successful virtual teams are formed through the influence of an online developer community. The focus of this research is to assess how the online developer community, Stack Overflow (SO), influences the success of open source projects. More precisely, the study empirically tests the influence of the SO community on successful Github (GH) projects. The investigation also empirically examines how the ties among the software developers in the SO community initiate the self-creation of OSS project teams. The research also explores the perception of the developers about open source projects. Furthermore, the study probes the impact of OSS artifacts, namely “feature” and “patch” requests, on open source projects. The findings indicate that the perception of the developers in the SO community, prior ties among the developers in the community, and the artifact type of the project are the factors that influence the success of OSS projects. The research discusses the implications of the outcomes concerning self-organizing open source project teams

Automated Testing For Software Process Automation

Robotic Process Automation is a way of automatizing business processes within short timespans. At the case company the initial automation step is implemented by business experts, rather than software developers. Using developers with limited software engineering experience allows for high speed but raises concerns of automation quality. One way to reduce these concerns is extensive testing, which takes up much time for integration developers. The aim of this thesis is to increase the quality of the development process, while minimizing impact on development time through test automation. The research is carried out as a part of the Robotic Process Automation project at the case company. The artifact produced by this thesis is a process for automatically testing software automation products. Automated testing of software automation solutions was found to be technically feasible, but difficult. Robotic process automation provides several novel challenges for test automation, but certain uses such as regression and integration testing are still possible. Benefits of the chosen approach are traceability for quality, developer confidence and potentially increased development speed. In addition, test automation facilitates the adoption of agile software development methods, such as continuous integration and deployment. The usage of continuous integration in relation to Robotic Process Automation was demonstrated via a newly developed workflow.Ohjelmistoautomaatio on nopea tapa automatisoida liiketoimintaprosessien rutiineja. Tapausyrityksessä automaation luovat ohjelmistonkehittäjien sijasta liiketoiminnan asiantuntijat. Käyttämällä alkukehittäjiä, joilla on vähäisesti kokemusta ohjelmistokehityksestä, saadaan nopeita ratkaisuja, mutta samalla yrityksellä on huolia laadusta. Laatua voidaan mitata testaamalla automaatioratkaisuja laajasti, mutta tähän menee huomattavasti aikaa. Tämän tutkielman tarkoituksena on testiautomaatiota käyttämällä nostaa kehitysprosessin laatua ilman että työmäärä kasvaa merkittävästi. Tutkimus suoritettiin osana tapausyrityksen ohjelmistorobotiikkaprojektia. Tutkielmassa luotiin prosessi, jossa automaattisesti testataan ohjelmistoautomaatioprosesseja. Testaus todettiin tutkimuksessa mahdolliseksi mutta käytännössä haasteelliseksi. Testauksessa ilmeni useita ongelmia, mutta muutamat ratkaisut kuten regressio- ja integraatiotestaus todettiin kuitenkin hyödyllisiksi. Lähestymistavan hyödyiksi todettiin laadun jäljitettävyyden, kehittäjien itseluottamuksen ja kehitysnopeuden kasvu. Lisäksi testiautomaatio mahdollistaa nykyaikaisten ketterien menetelmien kuten jatkuvan integraation käytön. Jatkuvan integraation käyttömahdollisuus demonstroitiin uudistetulla työtavalla

(No) influence of continuous integration on the commit activity in GitHub projects

A core goal of Continuous Integration (CI) is to make small incremental changes to software projects, which are integrated frequently into a mainline repository or branch. This paper presents an empirical study that investigates if developers adjust their commit activity towards the above-mentioned goal after projects start using CI. We analyzed the commit and merge activity in 93 GitHub projects that introduced the hosted CI system Travis CI, but have previously been developed for at least one year before introducing CI. In our analysis, we only found one non-negligible effect, an increased merge ratio, meaning that there were more merging commits in relation to all commits after the projects started using Travis CI. This effect has also been reported in related work. However, we observed the same effect in a random sample of 60 GitHub projects not using CI. Thus, it is unlikely that the effect is caused by the introduction of CI alone. We conclude that: (1) in our sample of projects, the introduction of CI did not lead to major changes in developers' commit activity, and (2) it is important to compare the commit activity to a baseline before attributing an effect to a treatment that may not be the cause for the observed effect.Sebastian Baltes, Jascha Knack, Daniel Anastasiou, Ralf Tymann, Stephan Dieh

(No) Influence of Continuous Integration on the Commit Activity in GitHub Projects — Supplementary Material

A core goal of Continuous Integration (CI) is to make small incremental changes to software projects, which are integrated frequently into a mainline repository or branch. Our paper presents an empirical study that investigates if developers adjust their commit activity towards the above-mentioned goal after projects start using CI. We analyzed the commit and merge activity in 93 GitHub projects that introduced the hosted CI system Travis CI, but have also been developed on GitHub for at least one year before introducing CI. In our analysis, we only found one non-negligible effect, an increased merge ratio, meaning that there were more merging commits in relation to all commits after the projects started using Travis CI. This effect has also been reported in related work. However, we observed the same effect in a random sample of 60 GitHub projects not using CI. Thus, it is unlikely that the effect is caused by the introduction of CI alone. We conclude that: (1) in our sample of projects, the introduction of CI did not lead to major changes in developers' commit activity, and (2) it is important to compare the commit activity to a baseline before attributing an effect to a treatment that may not be the cause for the observed effect.To execute the analysis scripts, you also need to download the corresponding dataset: https://doi.org/10.5281/zenodo.114026

(No) Influence of Continuous Integration on the Commit Activity in GitHub Projects — Supplementary Material

<p>A core goal of Continuous Integration (CI) is to make small incremental changes to software projects, which are integrated frequently into a mainline repository or branch. Our paper presents an empirical study that investigates if developers adjust their commit activity towards the above-mentioned goal after projects start using CI. We analyzed the commit and merge activity in 93 GitHub projects that introduced the hosted CI system <em>Travis CI</em>, but have also been developed on GitHub for at least one year before introducing CI. In our analysis, we only found one non-negligible effect, an increased merge ratio, meaning that there were more merging commits in relation to all commits after the projects started using <em>Travis CI</em>. This effect has also been reported in related work. However, we observed the same effect in a random sample of 60 GitHub projects not using CI. Thus, it is unlikely that the effect is caused by the introduction of CI alone. We conclude that: (1) in our sample of projects, the introduction of CI did not lead to major changes in developers' commit activity, and (2) it is important to compare the commit activity to a baseline before attributing an effect to a treatment that may not be the cause for the observed effect.</p