This significant number of casual contributors might lead one to believe that an important proportion of the projects are intrinsically made by casual contributions. In reality, we found the opposite: these casual contributors are responsible for only 1.73% of the total number of contributions in our corpus of OSS projects (linux: 1.02%, rails: 3.46%, django: 3.19%). For a more detailed perspective, next figure shows the percentage of the casual contributors (top) and contributions (bottom) for each programming language analyzed.
We observed that the number of additions, deletions and files touched of contributions do not vary signifi- cantly among the analyzed projects. In particular, the project paperclip is the one with the highest number of additions and deletions among the Ruby projects. See table below. With more than 8 years old, 63% of its contributors are casual ones, who contributed to 12.74% of the project.
|Change||Mean||3rd Quartile||Std. Dev|
We also analyzed the contributions with the lowest number of additions and deletions. In fact, 22.7% of the casual contributions performed on Ruby projects changed a single line of code. Some of them include, (1) preventing a type from being null, (2) updating documentation files, or (3) setting an option to a default value.
We also analyzed a statistically significant sample of 384 casual contributions. We identified 8 categories of casual contributions, summarized next. Afterwards, we discuss the top 3 ones.
|Add new feature||72||18.75%|
|Improve error message||14||3.64%|
|Improve resource usage||8||2.08%|
|Add test cases||5||1.30%|
Bug fix. It is the most common kind of casual contribution found in our dataset. Some examples include: (1) layout fix, (2) fixing compilation problems, and (3) fixing a broken URL. Still, some bug fixes are far from being trivial, as the one that fixed a race condition at the linux operating system. Not only difficult to identify (such bugs are non-deterministic), the solution employed was also scattered between C preprocessors, which difficulties the reasoning of the compiled program.
Documentation. This category includes fix for typos, grammar, translation, formatting, and documentation issues. Although these contributions do not require significant programming effort, we found contributions that have thoroughly rewritten the original material. Also, we found that 27 out of these 110 contributions were fixing typos on code examples. This finding reinforces the importance of complete and verified working code examples.
Add New Feature. Some of the examples include (1) adding a new option for a command line tool, (2) adding support for disabling an option, and (3) adding support for IPv6 remote hosts. Interestingly, 24 out of the 72 contributions in this category were performed at the Linux operating system. Most of them were adding support for a new driver/device, which usually require few additions.
We explicitly asked casual contributors and project maintainers “what motivates casual contributors’ behavior”, and the top cited perceived motivation was scratch their own itch, highly mentioned by both casual contributors (90 out of 197) and project maintainers (23 out of 64). Part of this high number of casual contributions can be explained by the pull-request model, which provided a clear and easy contribution process. It was mentioned by 9 out of 64 project maintainters.
Aligned with some studies on the motivation behind OSS contributors, we found that give back to community fosters casual contributions, as said by one casual contributor “As I use a lot of OSS projects, I like to give back to the community”. Another motivation that is inline with the literature is gaining reputation and prestige.
Not among the top cited motivations, we found that four casual contributors reported that their motivation was improving the project. The following quotes clearly illustrate such motivation: “I want to improve the quality of the project”, “That the project is in better shape after my contribution”.
In addition to motivation, we investigated the reasons why casual contributors do not become full active contributors. Lack of time was far the most cited reason by the casual contributors (96 out of 197), like one mentioned “I don’t have time to devote to a more active role”. From the perspective of the project maintainters, Lack of time was also the most mentioned reason why casual contributors do not become a long term contributor (17 out of 64 respondents). The following quote exemplify it: “People often don’t have the time or desire to be long term contributors”.
We also found people who reported that they do not contribute because of their limited skills or knowledge. Some also mentioned that the effort and knowledge needed to become a full contributor was too high. In both cases, they prefer to work on small or peripheral issues, which do not need specific abilities and usually require low effort. Like one of them said: “lack of skills (most of the low hanging fruit is gone)”. Project maintainers noticed this, and eight participants mentioned that code/project is hard to learn was a reason why casual contributors do not become more active.
We also asked the participants their opinion about the main benefits and problems brought by the casual contributors phenomenon. The overall impression is that the benefits overcome the drawbacks brought by this phenomenon. One quote from a project maintainter shows: “Every little piece helps everyone else. We stand on the shoulders of many small giants. Problems? None”.
On the other side, the most reported problems were Time spent by the core members to review newcomers’ code (reported by 12 people) and contributions may go unmaintained (reported by 5 people).
Casual contributors can see that they are not alone, and this behavior is, in fact, rather common in OSS communities. Also, we found that 22.93% of the casual contributions changed a single line of code. Thus, a developer does not need to be shy to contribute, even though her contribution is small. Yet, this study revealed that project maintainers believe that casual contributions are a healthy way of contributing to OSS. Therefore, casual contributors can become even more motivated to do this kind of contribution.
Project owners can label tasks specific for casual contributors. Similarly, some casual contributors are more comfortable on solving low effort tasks. Thus, project owners can create specific roles for casual contributors (e.g., casual translators), which could also foster more engagement. Finally, since several projects maintainers do not have enough time to review casual contributions, they can introduce “contributions guidelines”, so that newcomers can read and get acquainted with them, therefore reducing code review effort.