No full-text available
To read the full-text of this research,
you can request a copy directly from the authors.
GitHub sponsors: exploring a new way to contribute to open source
... For GitHub users, we also collected the network of followers and sponsors each user has using the same API. GitHub implemented sponsorships for developers in 2019 33 , enabling developers to crowdfund from users who appreciate their work directly on their GitHub pages. Data processing. ...
Open Source Software (OSS) is widely spread in industry, research, and government. OSS represents an effective development model because it harnesses the decentralized efforts of many developers in a way that scales. As OSS developers work independently on interdependent modules, they create a larger cohesive whole in the form of an ecosystem, leaving traces of their contributions and collaborations. Data harvested from these traces enable the study of large-scale decentralized collaborative work. We present curated data on the activity of tens of thousands of developers in the Rust ecosystem and the evolving dependencies between their libraries. The data covers eight years of developer contributions to Rust libraries and can be used to reconstruct the ecosystem’s development history, such as growing developer collaboration networks or dependency networks. These are complemented by data on downloads and popularity, tracking dynamics of use, visibility, and success over time. Altogether the data give a comprehensive view of several dimensions of the ecosystem. Measurement(s)Software dependencies and downloads • Software contributions • Social network dataTechnology Type(s)crates.io dump • Raw git • GitHub/GitLab APIsSample Characteristic - EnvironmentPackages of the Rust programming language Measurement(s) Software dependencies and downloads • Software contributions • Social network data Technology Type(s) crates.io dump • Raw git • GitHub/GitLab APIs Sample Characteristic - Environment Packages of the Rust programming language
Open-source software (OSS) is widely spread in industry, research, and government. OSS represents an effective development model because it harnesses the decentralized efforts of many developers in a way that scales. As OSS developers work independently on interdependent modules, they create a larger cohesive whole in the form of an ecosystem, leaving traces of their contributions and collaborations. Data harvested from these traces enable the study of large-scale decentralized collaborative work. We present curated data on the activity of tens of thousands of developers in the Rust ecosystem and the evolving dependencies between their libraries. The data covers seven years of developer contributions to Rust libraries and can be used to reconstruct the ecosystem's development history, such as growing developer collaboration networks or dependency networks. These are complemented by statistics on downloads and popularity, tracking the dynamics of use and success over time. Altogether the data give a comprehensive view of several dimensions of the ecosystem.
Issue addressing is a vital task in the evolution of software projects. However, in practice, not all issues can be addressed on time. To facilitate the issue addressing process, monetary incentives (e.g., bounties) are used to attract developers to address issues. There are two types of core roles who are involved in this process: bounty backers, who propose bounties for an issue report via bounty platforms (e.g., Bountysource), and bounty hunters, who address the bounty issues and win the bounties. We wish to study the process of bounty issue addressing from the angle of two important roles (i.e., backers and hunters) and their related behaviors. With a better understanding of how they address bounty issues, stakeholders (e.g., operators and developers) of open source projects may have a reasonable estimation of what they can expect from backers and hunters. In this study, we investigate 2,955 bounty backers and 882 bounty hunters, and their associated 3,579 GitHub issue reports with 5,589 bounties that were proposed on Bountysource. We find that: 1) Overall, the value of a bounty is small (median bounty value of $20). Both individual and corporate backers prefer to support implementing new features rather than fixing bugs. Corporate backers tend to propose larger bounties and propose bounties more frequently than individual backers. 2) 85.0% of the bounty hunters addressed less than 3 bounty issues. The income of 56.7% of the bounty hunters is no more than $100 and only 2.7% of the hunters have earned more than $2,000. In addition, most of the regular hunters and big hunters are developers that made at least one commit before addressing a bounty issue. 3) The value of a bounty issue is not a statistically significant factor that attracts developers that have never made any commit before to address an issue. Based on our findings, we provide several suggestions for stakeholders of open source projects and hunters.
Due to the voluntary nature of open source software, it can be hard to find a developer to work on a particular task. For example, some issue reports may be too cumbersome and unexciting for someone to volunteer to do them, yet these issue reports may be of high priority to the success of a project. To provide an incentive for implementing such issue reports, one can propose a monetary reward, i.e., a bounty, to the developer who completes that particular task. In this paper, we study bounties in open source projects on GitHub to better understand how bounties can be leveraged to evolve such projects in terms of addressing issue reports. We investigated 5,445 bounties for GitHub projects. These bounties were proposed through the Bountysource platform with a total bounty value of 406,425. We find that 1) in general, the timing of proposing bounties is the most important factor that is associated with the likelihood of an issue being addressed. More specifically, issue reports are more likely to be addressed if they are for projects in which bounties are used more frequently and if they are proposed earlier. 2) The bounty value of an issue report is the most important factor that is associated with the issue-addressing likelihood in the projects in which no bounties were used before. 3) There is a risk of wasting money for backers who invest money on long-standing issue reports.
Technical question and answer (Q&A) websites provide a platform for developers to communicate with each other by asking and answering questions. Stack Overflow is the most prominent of such websites. With the rapidly increasing number of questions on Stack Overflow, it is becoming difficult to get an answer to all questions and as a result, millions of questions on Stack Overflow remain unsolved. In an attempt to improve the visibility of unsolved questions, Stack Overflow introduced a bounty system to motivate users to solve such questions. In this bounty system, users can offer reputation points in an effort to encourage users to answer their question. In this paper, we study 129,202 bounty questions that were proposed by 61,824 bounty backers. We observe that bounty questions have a higher solving-likelihood than non-bounty questions. This is particularly true for long-standing unsolved questions. For example, questions that were unsolved for 100 days for which a bounty is proposed are more likely to be solved (55%) than those without bounties (1.7%). In addition, we studied the factors that are important for the solving-likelihood and solving-time of a bounty question. We found that: (1) Questions are likely to attract more traffic after receiving a bounty than non-bounty questions. (2) Bounties work particularly well in very large communities with a relatively low question solving-likelihood. (3) High-valued bounties are associated with a higher solving-likelihood, but we did not observe a likelihood for expedited solutions.
Open source communities have contributed widely to modern software development. The number of open source software (OSS) has increased rapidly in the past two decades. Most open source foundations (such as Eclipse, Mozilla and Apache) operate as non-profit; those foundations usually seek donations from users/developers to financially support their activities. Without such support, some projects might discontinue to develop, or even disappear. However, contributions to those foundations are usually solicited in a very simple and modest way, with no special promotions or attractions for such contributions. The aim of this study is to promote new strategies that can help to increase donations to OSS projects. We analyzed how existing donation pages are structured. We then introduce behavioral economics and psychological theories that have been used in other disciplines to promote donations in OSS. In particular, we used the social proof theory, i.e., where people tend to consider the actions of others in an attempt to reflect correct behavior when they choose their own actions, and legitimization of paltry contributions strategy i.e., using specific phrases such as "even a very small amount will help" to encourage donations. In this study, we conducted an experiment with University students to examine if those theories are effective in encouraging donations to OSS. Our initial results indicate that the two strategies were indeed effective in promoting donations, and showed that users were more open for donation compared to traditional methods. This is only a preliminary analysis-we aim to include more users in the future for a more comprehensive analysis. We anticipate that such techniques might help OSS projects to secure more donations in the future.
Eclipse, an open source software project, acknowledges its donors by presenting donation badges in its issue tracking system Bugzilla. However, the rewarding effect of this strategy is currently unknown. We applied a framework of causal inference to investigate relative promptness of developer response to bug reports with donation badges compared with bug reports without the badges, and estimated that donation badges decrease developer response time by about two hours in median. The appearance of donation badges is appealing for both donors and organizers because of its inexpensive but practical effects.
Bug-bounty programs have the potential to harvest the effort and diverse knowledge of thousands of independent security researchers, but running them at scale is challenging due to misaligned incentives and misallocation of effort. In our research, we discuss these challenges in detail and present relevant empirical data. We develop an economic framework consisting of two models that focus on evaluating different policies for improving the effectiveness of bug-bounty programs. Further, we discuss regulatory policy challenges and questions related to vulnerability research and disclosure, such as mandatory bug bounties and the relation to other cybersecurity policies.
Although development activities, such as submitting patches and working with bug reports, are common contributions in open source software (OSS) projects, making donations is also an important contribution. Some OSS development projects actively collect donations by preparing benefits for donors who promote donations. In this research, we study the Eclipse project to analyze donations. We analyzed donor lists and release dates, and found the following: (1) benefits can be motivations for donations, (2) although the number of developers is small in all donors, they donated more than others, and (3) new releases are triggers of donations, but bugs negatively affect the amount of donations.
Software forges like GitHub host millions of repositories. Software engineering researchers have been able to take advantage of such a large corpora of potential study subjects with the help of tools like GHTorrent and Boa. However, the simplicity in querying comes with a caveat: there are limited means of separating the signal (e.g. repositories containing engineered software projects) from the noise (e.g. repositories containing home work assignments). The proportion of noise in a random sample of repositories could skew the study and may lead to researchers reaching unrealistic, potentially inaccurate, conclusions. We argue that it is imperative to have the ability to sieve out the noise in such large repository forges. We propose a framework, and present a reference implementation of the framework as a tool called reaper, to enable researchers to select GitHub repositories that contain evidence of an engineered software project. We identify software engineering practices (called dimensions) and propose means for validating their existence in a GitHub repository. We used reaper to measure the dimensions of 1,857,423 GitHub repositories. We then used manually classified data sets of repositories to train classifiers capable of predicting if a given GitHub repository contains an engineered software project. The performance of the classifiers was evaluated using a set of 200 repositories with known ground truth classification. We also compared the performance of the classifiers to other approaches to classification (e.g. number of GitHub Stargazers) and found our classifiers to outperform existing approaches. We found stargazers-based classifier (with 10 as the threshold for number of stargazers) to exhibit high precision (97%) but an inversely proportional recall (32%). On the other hand, our best classifier exhibited a high precision (82%) and a high recall (86%). The stargazer-based criteria offers precision but fails to recall a significant portion of the population.
In recent years, the success of open source software (OSS) has attracted proprietary
software firms, who now actively participate, and sponsor OSS development. Though
researchers agree that for the progress of OSS projects, financial support, rewards, and
incentives are critical if not essential, we are yet to understand the dynamics of
compensation structures/policies and their impact on the long-term sustainability of
OSS projects and communities. In this research, we aim to explore the role of developers’
perceived asymmetry in compensation in OSS projects. Using grounded theory
procedures to code and analyse the textual responses from the developers, we find a
mixed opinion on whether the perceived asymmetric distribution of project’s financial
resources, helps or impedes the progress of an OSS project. We find that fair-terms,
transparency and effective communication practices are essential to the sustainability
of OSS projects, even with perceived asymmetric compensation. Future research aims to
develop a comprehensive theory of the role of rewards in open source software
development.
Bug bounty programs offer a modern platform for organizations to crowdsource their software security and for security researchers to be fairly rewarded for the vulnerabilities they find. Little is known however on the incentives set by bug bounty programs: How they drive new bug discoveries, and how they supposedly improve security through the progressive exhaustion of discoverable vulnerabilities. Here, we recognize that bug bounty programs create tensions, for organizations running them on the one hand, and for security researchers on the other hand. At the level of one bug bounty program, security researchers face a sort of St-Petersburg paradox: The probability of finding additional bugs decays fast, and thus can hardly be matched with a sufficient increase of monetary rewards. Furthermore, bug bounty program managers have an incentive to gather the largest possible crowd to ensure a larger pool of expertise, which in turn increases competition among security researchers. As a result, we find that researchers have high incentives to switch to newly launched programs, for which a reserve of low-hanging fruit vulnerabilities is still available. Our results inform on the technical and economic mechanisms underlying the dynamics of bug bounty program contributions, and may in turn help improve the mechanism design of bug bounty programs that get increasingly adopted by cybersecurity savvy organizations.
Many open source projects have long become commercial. This paper shows just how much of open source software de-velopment is paid work and how much has remained volun-teer work. Using a conservative approach, we find that about 50% of all open source software development has been paid work for many years now and that many small projects are fully paid for by companies. However, we also find that any non-trivial project balances the amount of paid developer with volunteer work, and we suggest that the ratio of volun-teer to paid work can serve as an indicator for the health of open source projects and aid the management of the respec-tive communities. Index Terms—Open source software, empirical software engineering, volunteer open source, paid open source.
Open source software projects, are based on volunteers collaboration and require a continuous influx of newcomers for their continuity. Newcomers face difficulties and obstacles when starting their contributions, resulting in a low retention rate. This paper presents an analysis of the first interactions of newcomers on a project, checking if the dropout may have been influenced by lack of answer, answers politeness and helpfulness, and the answer author. We have collected five years data from the developers' mailing list communication and issue manager (Jira) discussions of the Hadoop Common project. We observed developers' communication, identifying newcomers and classifying questions and answers content. In the analyzed period, less than 20% of newcomers became long-term contributors. There are evidences that the newcomers decision to abandon the project was influenced by the authors of the answers and by the type of answer received. However, the lack of answer was not evidenced as a factor that influences newcomers' decision to remain or abandon the project.
Free/Open source software (FOSS) is an important part of the IT ecosystem. Due to the voluntary nature of participation, continual recruitment is key to the growth and sustainability of these communities. It is therefore important to understand how and why potential contributors fail in the process of transitioning from user to contributor. Most newcomers, or "newbies", have their first interaction with a community through a mailing list. To understand how this first contact influences future interactions, we studied eight mailing lists across four FOSS projects: MediaWiki, GIMP, PostgreSQL, and Subversion. We analyzed discussions initiated by newbies to determine the effect of gender, nationality, politeness, helpfulness and timeliness of response. We found that nearly 80% of newbie posts received replies, and that receiving timely responses, especially within 48 hours, was positively correlated with future participation. We also found that while the majority of interactions were positive, 1.5% of responses were rude or hostile.
This chapter describes the impact of a bounty program on a corporation, an individual developer and a project. Bounty programs are commonly used in Free/Libre/Open Source Software (FLOSS) communities to motivate developers for the tasks which are not of their primary interest by providing monetary incentives. These tasks include creating new programs, improving the security of an existing software, solving a specific bug, giving product improvement suggestions, helping maintain the codebase, and preparing documentation. The rational response to a bounty by applying the model is analyzed. This chapter focuses on the financial rewards to FLOSS developers via bounty programs. They are used to improve the security of an existing product, to solve a specific bug, to obtain product improvement suggestions, to help maintain the code base and to prepare documentation. Agents that offer bounties benefit by a favorable reprioritization of project development tasks and, influence the agenda of the project.
The success of the Linux operating system has demonstrated the viability of an alternative form of software development — open source software — that challenges traditional assumptions about software markets. Understanding what drives open source developers to participate in open source projects is crucial for assessing the impact of open source software. This article identifies two broad types of motivations that account for their participation in open source projects. The first category includes internal factors such as intrinsic motivation and altruism, and the second category focuses on external rewards such as expected future returns and personal needs. This article also reports the results of a survey administered to open source programmers.
Online open source software platforms, such as Sourceforge.net, play a vital role in creating an ecosystem that enables the creation and growth of open source projects. However, there is little research exploring the interactions between open source stakeholders and the platform. We believe that the sustainability of the platform crucially depends on financial incentives. While platforms can obtain these incentives through multiple means, in this paper we focus on one form of financial incentives—voluntary monetary donations by open source community members. We report findings from two empirical studies that examine factors that impact donations. Study 1 investigates the factors that cause some community members to donate and not others. We find that the decision to donate is impacted by relational commitment with open source software platform, donation to projects and accepting donations from others. Study 2 examines what drives the level of donation. We find that the length of association with the platform and relational commitment affects donation levels.
What differentiates successful from unsuccessful open source software projects? This paper develops and tests a model of the impacts of license restrictiveness and organizational sponsorship on two indicators of success: user interest in, and development activity on, open source software development projects. Using data gathered from Freshmeat.net and project home pages, the main conclusions derived from the analysis are that (1) license restrictiveness and organizational sponsorship interact to influence user perceptions of the likely utility of open source software in such a way that users are most attracted to projects that are sponsored by nonmarket organizations and that employ nonrestrictive licenses, and (2) licensing and sponsorship address complementary developer motivations such that the influence of licensing on development activity depends on what kind of organizational sponsor a project has. Theoretical and practical implications are discussed, and the paper outlines several avenues for future research.
Announcing GitHub Sponsors: a new way to contribute to open source
- Devon Zuegel