Hug Reports: Supporting Expression of Appreciation between Users and Contributors of Open Source Software Packages (2024)

2.2.1. Users must incur effort to navigate to existing communication channels and to locate whom to thank

Channels for communicating with contributors are available on GitHub, where contribution activities occur. But these are detached from users’ development environments, where the packages are used. To contact contributors, users need to leave their development environment, find the right GitHub repository, navigate to GitHub, and then either open an issue or locate the contributor’s contact details. Users are more likely to undertake this effort to report issues, since improvements can directly benefit them, than to express appreciation, from which they might not see any direct benefits. This tendency for negative feedback over positive is also observed in consumer research, showing that customers with bad experiences are more inclined to leave online reviews than those with good experiences(Han and Anderson, 2020; Anderson, 1998). Further, using GitHub’s affordances to discover and contact contributors of individual commits or pull requests is straightforward because contribution activities are organized along those low-level units. But affordances that are oriented towards commits or pull-requests quickly become ill-suited when a user wants to thank developers of the entire package or its modules. A module, for instance, may combine several commits and pull requests. So, identifying all relevant contributions, and their authors, can be prohibitively effortful. Because individual commits or pull requests are abstracted away from users when they are working with a package, we suggest it can be beneficial for appreciation systems to be oriented towards the abstractions that users are exposed to—the package or its modules.

2.2.2. Existing communication channels de-emphasize appreciation because they were primarily designed to coordinate contribution activities

In addition to supporting communication around individual commits and pull requests, GitHub provides some support for communicating with the project as a whole through issues and stars. But the uptake of these features for communicating appreciation is limited. This is because in addition to being removed from where users are, these affordances were also designed primarily to coordinate contribution activities, with values of efficiency and productivity in mind. GitHub “Issues”²²2https://docs.github.com/en/issues/tracking-your-work-with-issues/about-issues, for instance, are advertised as a way to “track ideas, feedback, tasks, or bugs for work on GitHub”. To support effective tracking of tasks, projects can further customize the feature to provide users default issue templates for common communication such as bug reporting or feature requests³³3https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository. Together, the name, advertised purpose, and user defaults normatively discourage appreciation. With hesitation, motivated users still reappropriate GitHub’s features to convey appreciation, as visible in issue #2264 in the react boilerplate project⁴⁴4https://github.com/react-boilerplate/react-boilerplate/issues/2264, which is titled: “I don’t know how to thank, and show my appreciation, to the contributors on a good way”. GitHub users have pointed out how the reaction palette available within issues and pull requests lacks emojis to convey the sentiment of “Thank you”⁵⁵5https://github.com/orgs/community/discussions/38201. While stars can be used to convey appreciation, they are also intended to function as a bookmarking tool, and a way for the platform to learn user preferences⁶⁶6https://docs.github.com/en/get-started/exploring-projects-on-github/saving-repositories-with-stars, which obscures the intention behind ‘starring’.

2.2.3. Reduced visibility of contributors’ labor in the development environment diminishes appreciation.

In his book “Exchange and Power in Social Life”(Blau, 2017), Blau argues that “only social exchange tends to engender feelings of personal obligation, gratitude, and trust; purely economic exchange as such does not.” In the development environment, the contributors and their labor are left out of focus. So, it can be easy to forget that the package relies on the labor of its contributors. The package, then, can seem more like a free economic commodity(Widder and Nafus, 2023) rather than a gift of labor(Hammer, 2021; Terranova, 2000). Because the labor of contributors is almost forgotten from the development environment, users may fail to feel a sense of personal obligation or appreciation towards contributors.

To overcome the above barriers to appreciation in open source, our work: (1) attempts to develop a cross-cutting communication channel that brings the ability to contact contributors—for which users presently need to visit and search GitHub—to the development environment, where users work with the packages; (2) attempts to support expression of appreciation in terms of the abstractions users are exposed to—packages, modules, or functions—rather than lower-level units such as individual commits or pull requests; and (3) attempts to provide users with a reminder of contributors’ efforts, within the development environment.

4.2.1. Participants

Like other design methods introduced early in the design process, field studies of technology probes focus on producing a rich qualitative account rather than statistically valid results(Hutchinson etal., 2003; Zimmerman etal., 2007; Leong etal., 2023). These considerations suggest a sample size that balances the researchers’ abilities to do deep qualitative analysis with the ability to observe diverse participant experiences(Sellen etal., 2006). Previous work in CSCW, for instance, has used a dozen dyads(Leong etal., 2023); some prior work suggests a sample of about 10 participants(Leong etal., 2023). To achieve a sample size in this range while accounting for the likely scenario that not all participants might complete all research activities, we halted recruitment when we had onboarded 18 participants to the study. We recruited users through flyers distributed across the campus of a private university in the United States. Flyers were also distributed within the university community (through Slack channels and personal contacts) and publicly via Twitter.

Two criteria were used to screen potential participants. We required that they primarily used VS Code as their development environment and that they anticipated writing Python/JavaScript/TypeScript code at least 3 times a week. The screening survey also included questions about users’ demographics and backgrounds. Responses are summarized in Table 1. The 18 users (12 men and 6 women) were aged 23-30. The survey asked users to report their experience levels as either Beginner, Advanced Beginner, Intermediate, Advanced, or Expert (categories present in the developer skill matrix). As Table 1 shows, users described themselves as Advanced (13/28), Intermediate (4/18), and Expert (1/18). We also asked users to report their weekly average of the amount of time they spent writing code, which ranged from 5 hours to 45 hours a week.

4.2.2. Procedure

We deployed the extension for three weeks so that users would have sufficient time to familiarize themselves with it and explore how they might interact with it in the course of their usual programming activities. To observe naturalistic use, required usage was deliberately kept minimal; however, we still encouraged (without enforcing) users to engage with the extension a meaningful amount so that they had opportunities to reveal their experiences, and so that there would be sufficient messages with which to understand contributor experiences. Each user was required to participate in a 15-minute onboarding session conducted over video call, during which we helped them install the extension and provided a brief tutorial. During this session, they were also required to complete a brief pre-study questionnaire that asked them to provide: (1) an open-ended response describing how often they typically thanked contributors of packages they used; and (2) a rating on a seven point scale (strongly disagree to strongly agree) indicating their agreement with the statement: “There are many developers whose work I am grateful for.” These questions were intended to capture their current feelings and practices of expressing appreciation. These are presented in in Table 3 (Appendix B) to provide more detail about the participant population. At the end of the onboarding session, we encouraged users to send thanks at least two times every day they found themselves coding, while expressing that this would not be enforced. During the three weeks, for every thanks, the extension logged the installation ID¹¹¹¹11For the purpose of the study, we established a link between participants and their installation IDs during the onboarding session., line of code, line number, and personal note if added. Users were compensated $20 for participating in the onboarding session and completing the pre-study questionnaire. At the end of the three weeks, we invited all 18 users to participate in a one-on-one interview, 14 of whom agreed to participate (those who did not are indicated in Table 1). Interviews were conducted in English, remotely via Zoom, and lasted between 20 and 50 minutes, for which users were compensated $15. Interviews were semi-structured and investigated factors that contributed to users’ feelings of appreciation and decisions to express it, the experience of selecting what to thank and what to include in personal notes, trends in their usage, and feedback on the interface and interaction. Across these topics, we asked users if there were ways in which different or new designs could have better supported their experience. All interviews were recorded and transcribed.

We planned to use data from the interviews with users to address RQ1-U1, RQ1-U2, RQ2-U, and RQ3. To address RQ2-U, we also planned to analyze usage data. Finally, we planned to use the thanks messages created over the course of the deployment to pursue our research activities with contributors.

4.3.1. Identifying contributors:

We first identified each unique object that was thanked (content of the line of code at which the button was clicked). For this process, we treated packages, modules, and functions as separate objects since the 20 most recent contributors to each could be different. Thanks logged next to the import of a package were treated as thanks directed at the package as a whole. Similarly thanks logged next to imports of modules, and next to function calls, are treated as being directed at the module and function respectively. We note that each object could have been thanked multiple times (e.g. “import cv2” was thanked twice). Corresponding to each unique object, we maintained a count of the number of thanks it was associated with and all personal notes associated with that object. We identified a total of $70$ unique objects that were thanked, most just once. We then mapped each object of appreciation to its source code on GitHub. Thanked packages were mapped to their repositories, while thanked modules and functions were mapped to their corresponding file. We used this to then find the 20 most recent contributors. For thanked packages, we identified the 20 most recent contributors to the entire repository. For thanked modules and functions, we identified the 20 most recent contributors to the corresponding file. Every commit, contains an email address of the author of the code patch, which provided us with contact information for the contributors. In determining the 20 most recent contributors, we skipped commits where the provided email address was anonymized (emails ending in “users.noreply.github.com”). If the total number of unique contributors was fewer than 20, we recorded all contributors. This process resulted in a total of $550$ contributors to be notified. $470$ had been thanked for $1$ object each, with the remaining being thanked for $2$ to $8$ objects each.

4.3.2. Notification

As shown in Figure 3 (B), the notification was organized so that each segment showed one object that the contributor had been thanked for (B1). Above the object, the notification showed the number of thanks corresponding to it (B3). Below the object, we included any personal notes associated with it (B4). The notification was delivered via an email (as shown in Figure 3 (A)) that provided the contributors with context about our project, so that they could understand the conditions under which the users had directed these thanks and personal notes towards them. The design of the notification message was modeled after notifications in Wikipedia’s “Thanks” system(Matias etal., [n. d.]).

4.3.3. Procedure and Participants

To understand contributors’ reactions to the notifications, the email also included an invitation to participate in our study with a link to a survey. The survey included questions on demographics including age, gender, programming proficiency, and their tenure in the project for which they were thanked. It then asked contributors how they felt on three single-item scales adapted from prior work(Kumar and Epley, 2018): (1) a scale ranging from -5 (much more negative than normal) to 5 (much more positive than normal), with the midpoint of 0 labeled no different than normal; (2) a scale ranging from -5 (not at all surprised) to 5 (extremely surprised); and (3) a scale ranging from -5 (not at all awkward) to 5 (extremely awkward). We also included an open-ended question asking contributors to further describe how the notification made them feel. The survey included three more open ended questions: (1) Prior to this, how often did you receive messages of thanks from users?; (2) What else would you have liked to know about the senders of these thanks?; and (3) Do you have any feedback for us that you would like to share? Finally, the survey invited contributors to participate in an interview. There was no compensation for participating in the survey and all questions on the survey were indicated as optional.

We received 26 responses to the survey (4.7% response rate). This included 23 men and 3 women. Respondents were aged 21-56 (median age was 34). 13 respondents had been involved for less than a year in the project for which they were thanked. Five respondents had been involved for 1-3 years, five had been involved for 3-5 years, and two respondents had been involved in the thanked project for more than 5 years (1 respondent did not disclose their tenure). In describing our findings, contributors who responded to the survey are labeled as C# (C1 to C26).

Of the respondents, $10$ agreed to be interviewed. Interviews were conducted in English, remotely via Zoom, and lasted 30 minutes. Interviews were semi-structured and focused on the experience of receiving thanks, scoping of appreciation, approaches for attribution, frequency and form of notifications, and their ideas for new or different design concepts. Contributors who participated in the interview were compensated $15. One contributor, labeled C27, did not respond to the survey questions but agreed to be interviewed. Table 2 shows demographic information of contributors who participated in interviews.

5.1.1. Patterns of use (RQ2-U)

Over the course of the three-week deployment, the $18$ participants logged $107$ thanks, and $23$ thanks included personal notes There were considerable differences in the frequency with which different users interacted with the extension (see Figure 4 (A) and (B)). We found that the lines of code at which the affordance was clicked, we more often import statements (72 instances) than other lines interfacing with a package (35 instances) (see Figure 4 (B)). Relatedly, the affordance was more often accessed near the start of a file than later on (Figure 4 (C)).

Personal notes varied in their content. Some (7/23) stopped at expressing general sentiments of gratitude towards the developers (e.g. “Thanks! I’m super relying on this!”, expressed at: “import pandas as pd”). Some notes (6/23) additionally described how they appreciated the general functionality the package was intended to provide (e.g. “Numba made my pandas code so much faster!”, expressed at: “from numba import njit”). 5 of the 23 notes, appreciated specific design choices made by contributors, such as supporting interoperability with other utilities, helpful error messages, and effective organization/modularization (e.g. “Thanks for making this library work so well with numpy so I don’t have to write much extra code to support sparse matrices!”, expressed at: “from scipy import sparse as sps”). Three of the notes mentioned the ways in which users were personally using the packages in their work (e.g. “This has been so useful for our project. We’re trying to do satellite localization using a camera and we’re essentially just fine-tuning your model on our dataset and wrapping it around a state estimator. It works so well!”, expressed at: “from ultralytics import YOLO”). In two notes, users revealed aspects of their background that shaped their appreciation (e.g. “I’m not a machine learning/computer vision scientist. OpenCV has helped me a lot with video processing!”, expressed at: “import cv2”). Finally, two notes expressed general sentiments of appreciation towards the organization working on the package (e.g. “Thanks folks at Microsoft for making TypeScript”, expressed at: “import * as ts from ’typescript’;”).

5.1.2. Contributors’ responses (RQ1-C, RQ2-C)

Overall, contributors reacted positively to receiving appreciation. Contributors hoped to know more about why they were being thanked, and would have liked more personalized messages. Some contributors didn’t feel like they deserved the appreciation if they hadn’t substantially contributed to the package for which they were thanked. Figure 5 summarizes the responses were received to the survey, from 26 contributors. 14 contributors reported that receiving the notification made them feel more positive than normal (Figure 5 (A)), 11 reported feeling no different than normal, and only 1 participant reacted negatively (whose survey response suggests it was because they found the thanks and personal note too generic). Reponding to how often they currently received appreciation, most contributors reported it was rare, some suggesting they received “a few per year” (C15), such as in “GitHub Issues once every couple months” (C13) or “once a feature request is closed, primarily with emojis, and it is extremely rare to get a text message” (C23). Participants further described how the notification made them feel. One mentioned how “receiving the hug report was a wonderful surprise, and brightened [their] day” (C3), while another mentioned they “felt happy and feel motivated to do more” (C1). One contributor explicitly mentioned how current channels for appreciation are few: “receiving thanks for open-source work felt nice and very new since I experienced it very rarely so far. Part of why it is so rare may be that there are no convenient and established ways to do so” (C20). However, few contributors noted how there was “nothing personalized about the report” (C9). Without a more specific message, C18 mentioned: “although I do appreciate the feedback, I don’t feel personally touched”. Contributors described wanting to know more about why they were being thanked and what users were using their packages for (e.g. “more than the one sentence of thanks, what was useful for them that they were thanking for?” (U19) and “having a rough idea about types of projects my features are used for is quite beneficial.” (C23)). Most contributors were surprised to receive the notification (Figure 5 (B)), however, few contributors who belonged to large projects were not. Most contributors felt no or low levels of awkwardness being appreciated (Figure 5 (C)). Some participants felt awkward because they did not feel like they had contributed significantly to the project for which they were being thanked (we discuss this further in 5.5). One contributor, who felt “extremely awkward” noted that a ‘hug’ from a stranger felt awkward (quote in Figure 5).

5.2.1. The button served as an ambient reminder of contributors’ effort (RQ1-U2)

5.2.2. Low procedural effort encouraged appreciation (RQ1-U1, RQ1-C)

Further, users liked having the option to express appreciation as a thanks since it was low effort enough that it didn’t disrupt their flow and it gave them a way to express appreciation when they didn’t “know what to say” (U9). Contributors acknowledged this sentiment behind the thanks: “I think it’s helpful. Because sometimes you don’t know what to say in a comment. You don’t have something particularly meaningful, but you still appreciate it” (C12). 14 of the contributors who responded to the survey had received only a thanks without any personal notes, 5 of whom reported feeling no different than normal, 3 reported feeling much more positive than normal, and the remaining 6 reported positive emotions in between the two. None of them reported feeling negatively. Since the extension gave users flexibility in how much effort they could convey, C13 suggested: “in this hierarchy of showing support you go all the way from not doing anything to supporting monetarily right? And somewhere along the rung there is this, the starring of the GitHub Repo. And at a slightly higher, more personalized level, there is thanking”.

5.3.1. Users engaged with the extension when they “came up for air” (RQ2-U)

5.3.2. Users thanked packages retrospectively, repeating if they discovered new use cases (RQ2-U)

Even though thanks was expressed at the top of the file, and in transitional moments, it was not expressed preemptively. Users mentioned how they felt appreciative, and thanked packages, once they had got them to work for their specific use case: “It’s like it did the thing. It has shown me that it can do the thing. And this is a good thing”(U9). As U15 put it: “I wasn’t saying good idea, but good implementation”. Similarly, U3 mentioned: “After I ran the code, then I would scroll up and say thank you.”. U14 also described scrolling up retrospectively: “whenever I saw that I had completed one module, I would just go at the top and see what modules I’ve used”. Further, users often described feeling appreciative when they discovered new functionalities. U7 mentioned: “I’d like to say thanks if I find something useful or something I didn’t know before. I think saying thanks sort of strengthens the my memory of my experience with that specific function.”. Users also mentioned how they would be inclined to thank packages again if they found new use cases, suggesting that thanks can be meaningfully different than one-time exchanges like starring on GitHub. U9 suggested: “I think if there is a unique functionality that hadn’t been captured before, so like you know, I have use case A, and then I find out there’s a use case B, I would definitely thank again.”

5.3.3. Broader rhythms in work influenced appreciation (RQ2-U)

Users described how their engagement with the extension was also influenced by broader rhythms in their work, where they found themselves more prone to reflection during certain periods: “I have my Tuesday meetings. I would just link this to my meeting, and I was like after the meeting. I’ll do this. And so I would do this like bout of thanksgiving(?)” (U10). U1 described how project cycles could also prompt reflection: “if I’m at the end of a project cycle, then I might feel gratitude again”. U3 drew an analogy to borrowing a tool: “If someone gave you a tool for you to use, I feel like you would say thank you to them like once, when you get the tool and a second time when you return the tool.”

5.4.1. Appreciation as a measure of utility (RQ2-U, RQ2-C)

Despite our small scale deployment, users and contributors saw value in the quantitative metrics that could be derived from the thanks. Some contributors envisioned metrics as being useful for providing external evidence of their own impact (e.g. “I wish this was integrated with GitHub/LinkedIn (badge, )etc. It would be good and motivational to share it with my professional network” (C1)) as well as the project’s impact: “We would find it useful because funding agencies want to know that…It’s only the funding people who are like ‘but are people using this?”’ (C8).To access its informational value, contributors preferred a publicly shareable aggregation of data (C19, C13). C13 suggested how the system could “keep aggregating the stats on a website”.

5.4.2. Appreciation as an act of expressive communication (RQ2-U, RQ2-C)

While some personal notes did mention these aspects (5.1.1), many users struggled to find something specific to say, in the moment, which led to them writing generic notes of appreciation or prevented them from writing personal notes altogether. U7 mentioned he was uncertain about what would make “good communication in this relationship between the user and contibutor”. Other users mentioned how it was a “bit tricky to explain why, I’m actually grateful” (U12) and how they sometimes “didn’t have anything specific to say” (U6). U9 suggested: “it was difficult to know what to say other than thanks. It’s a lot easier to write something when things go wrong.”

When considering thanks as a personal expression of gratitude, some users described how their experiences were affected by the size of the anticipated audience of their thanks (U6, U12). In the context of larger packages, these users felt that thanks scoped to the entire package were less meaningful than thanks scoped to individual modules or function.

5.6.1. Nudges

Users proposed ideas of how the extension could encourage appreciation further. For instance, U3 suggested having an ambient indicator of usage: “the button could glow or become a bit more colorful if you have been programming with that package for a while, especially, you know, if you have that package imported that you use a lot of different components from it.” U1 suggested a similar idea: “simple threshold based things, after you’ve imported something 10 times, youshow like a little popup or in the status bar”. U2 mentioned how such reminders could make usage more apparent: “these are not things that I realize until I see the statistics. So, it would be great to have some feature that reminds me of that.” Further, U6 mentioned how the extension could also identify which packages had smaller teams, as those would feel more meaningful to thank.

5.6.2. Opportune moments

Reflecting on patterns in when they tend to express appreciation, users pointed out ways in which the system could harness opportune moments. U1 suggested: “every time you open or close a file maybe you could get a pop up which says that, ‘oh, in this file you use these things”’. U7 had a similar suggestion, mentioning how he would like such notifications to emphasize new features he used that week. U9 and U10 mentioned how they would like to view statistics of their use, at times that they could control (e.g. immediately after a specific recurring meeting), either via a notification or dashboard. C12 suggested that the end of project cycles, if users were themselves publishing work to GitHub, it could be a opportune moment to remind users of the packages they were using: “GitHub, has a feature where you say like, make a release right? You could tie an action into that where it would say, ‘Oh, you’re making a release. Here are all the [packages] you used in your project in this release”’ (C12).

5.6.3. Form and frequency of notifications

Contributors described how the form in which Hug Reports were aggregated and presented could be broadened to support different use cases: “the psychological benefits of it would be garnered more by sending the emails out, and the economic benefits might be garnered better by putting it up on a website and sharing the link around” (C13). Decision-making and fund raising activities could benefit from more aggregated statistics: “from the perspective of the project, we wouldn’t really care about the personal notes, because we would aggregate over them anyway” (C8). Contributors also suggested venues to make the aggregate data public, such as in project “release notes” (C8) and in individuals’ “GitHub profiles” (C27). C20 and C18 also felt having a way to display on the project’s GitHub page, for example as “a GitHub badge” (C18) would be nice: “on GitHub, I look at the number of give stars, the number of different issues and so, it seems the number of happy users, would also be a good metric” (C18)

5.6.4. Scaffolding for personal effort

Both users and contributors suggested it would be useful to have prompts that could help users write more specific personal notes: “maybe giving some instruction of like to users like, here’s an example. What you can write like here was my used case, and why it was useful.” (U9). C19 suggested having something similar to product reviews that ask users “what’s good about it? Is the make good? Is the design good?”. U3 suggested it could be useful to be able to “send pictures, you know, especially if things are hardware related”. In his survey response, C26 suggested having discrete pre-determined categories: “maybe a selection from a few pre-determined thank-types. e.g ‘I am using it for everything, thanks!’ or ‘Saved me a ton of time in my current project”’.

5.6.5. Heuristics for notifying contributors

Contributors suggested that accuracy in notifying relevant contributors was less critical since misdirected thanks were acceptable. In fact, many contributors suggested relaxing the criteria further. Some suggestions included sending “an automated mail on the project mailing list” (C8) or notifying “all the people who have ever committed code” (C13). C20 suggested:“people might just thank popular functionality of a package that you did not contribute anything to butit can just go out to everyone…that seems like the most general approach.”

6.1.1. Opportunity: Encouraging collective recognition and improving visibility into usage

First, our work suggests that capturing appreciation in terms of abstractions of use has the potential to encourage more interactions. Even if it is difficult to derive individual recognition from such appreciation, the fact that contributors reacted positively, suggests it could still provide a valuable form of collective recognition. Further, it gives members of the project new insights into what the project’s users appreciate. Many contributors in our study pointed out the value of thanks as a source of information that could also support project-level decision-making. Taken together, we suggest that this approach could be a valuable supplement to existing appreciation systems that capture appreciation towards low-level units of work. Following the recommendations of contributors in our study, it could be valuable to aggregate such appreciation and make it available to members of the project, even if the system does not solve the challenge of individual attribution.

6.1.2. Limitation: Deriving individual recognition is challenging

Even though contributors reacted positively to the appreciation they received, the extent to which they thought they had ‘claim’ to the appreciation depended on how much they felt they had contributed to the work. This foregrounds an important question: To what extent can systems derive individual recognition after capturing appreciation around abstractions of use?

Prior work suggests that there is a limit to what automated approaches can accomplish. This is because it is challenging to objectively determine a contributor’s relative impact based solely on visible contribution activities. Visible activity traces may not reflect contributions such as intellectual contributions(Howison and Herbsleb, 2013), code review(Young etal., 2021), governance(Young etal., 2021), and fund raising(Young etal., 2021). Several efforts have emerged to address this limitation. For instance, the All Contributors¹³¹³13https://allcontributors.org/ project aims to standardize credit files and bring visibility to non-code contributions. Gitmoji¹⁴¹⁴14https://gitmoji.dev/about aims to provide a standardized way to annotate commits based on the kinds of contribution they are aiming to make. Additionally, several researchers have recommended that team member roles be explicitly recorded(Alliez etal., 2019; Casari etal., 2021; Ramin etal., 2020). But until these approaches are adopted as a standard, there is unlikely to be a generalized approach to deriving individual recognition. Systems attempting to do so would have to work closely with individual projects and either: (1) share the messages of appreciation with the project that members of the project can then redirect to appropriate contributors, or (2) develop heuristics that are fine-tuned to each project based on its specific practices of recognizing contributors (e.g. NumPy lists contributors in its release notes).

Finally, even if these approaches can more accurately ascertain a contributor’s relative impact in objective terms, contributors may still feel uncomfortable ‘claiming’ the appreciation. This is because a contributor’s sense of ownership may not always correspond to objective measures of their impact in a collaborative effort. This is true of open source(Young etal., 2021; Pinto etal., 2016), as well as Wikipedia(Yim etal., 2024). We suggest that capturing appreciation in terms of abstractions of use can be a critical limitation in contexts where individual recognition is paramount.

6.3.1. Limitations in the kinds of contributions considered

Our inquiry was limited to scenarios where open source software use occurred through packages. Future work can explore whether and how these approaches can be extended to other kinds of open source software such as end-user applications and cookie cutter templates. Further, we chose to focus on Python and JavaScript packages because they are commonly used languages with large package ecosystems, and are also languages we are most familiar with. Future work can explore extending this approach to other programming languages/ecosystems. By relying on code activity traces, our work supported appreciation of contributors who made code contributions to projects. However, this approach overlooks many important non-code contributions such as documentation, governance, fund-raising, community-building. Hence, there is an opportunity for future research to investigate how appreciation can be extended to non-code contributions.

6.3.2. Limitations in study methodology

Our inquiry was heavily influenced by field deployment methods(Siek etal., 2014) and design methods(Zimmerman and Forlizzi, 2014) intended to produce richqualitative accounts rather than statistically valid results. As with other field-based design research, our observationsare our own and other researchers working with the same problem framing may create other artifacts or pursuedifferent design activities, arriving at other, equally relevant conclusions(Zimmerman etal., 2007). While our choice of design methods does not allow for statistical validity, we believe our work offers opportunities for what Zimmerman et al. describe as“extensibility” [55]: that future attempts to develop technological support for appreciation, can build on our observations,and our artifacts. Our research was also limited by the fact that users were encouraged to send thanks at least two times every day they found themselves coding. This was to help ensure that each user would be able to try out the probe long enough to understand how its features influenced their interactions, and how it fit into their development practices, while also ensuring we would have a sufficient number of thanks with which to study the experiences of contributors. This practice was consistent with other deployments of probes(Leong etal., 2023), where similar to our study, research questions primarily concern participants’ own descriptions and reflections rather than investigating voluntary adoption (“Will people use this tool?”). This is also consistent with field studies that are concerned less with investigating voluntary adoption, which, as Siek et al. write(Siek etal., 2014), feature“artificial inducements for adoption and use in order to focus on other factors such as the usefulness of specific system features, the appropriateness of the system in the given social context, the ability of the system to be appropriated for particular participant needs and practices, or the impacts of using the system on other factors, such as users’ behavior changes, work productivity, etc.” Nevertheless, we recognize this decision limits the kinds of conclusions that can be drawn from our findings, and we follow the convention recommended by Siek et al.(Siek etal., 2014), of reporting it in the study design, so that “readers can carefully analyze the results in light of the compensation scheme”(Siek etal., 2014).

6.3.3. Studying the long-term impacts of appreciation

As a short-term technology probe deployment, our study could not investigate the long-term impacts of appreciation on motivation and participation in open source projects. Prior work identifies lack of recognition as one of the reasons due to which contributors disengage(Guizani etal., 2021, 2022). Hence, there is an opportunity for future work to investigate whether appreciation can increase retention. Further, prior work has also noted that exchanges that make an individual feel socially attached to a community can be effective at converting them into long-term contributors(Kim and Wang, 2022). From this perspective, encouraging users to express appreciation has the potential to increase their social attachment to the project and eventually motivate them to contribute. Future work can explore whether and how exchanges of appreciation can create and engage a community around software artifacts.