What is Open Source for Social Good and Why People Contribute?

When you first hear “open source software” your mind will likely go directly to developers building more tools that only developers will use. While projects like TensorFlow or React are popular for open source contributors, there are other galvanizing projects with direct societal impacts that inspire people to contribute to open source.

A gif from the Little Window Project of engaging with a chatbot
A screenshot from the Restroom Refuge Tool

Specifically, one project to consider is Little Window which supports victims of intimate partner violence and provides resources to leave abusive relationships. Another is Restroom Refuge, which identifies and highlights safe restrooms for trans and gender nonconforming individuals. These are only a few of the open source (OSS) for social good projects we identified. But although they may seem to be fewer in quantity, they are definitely powerful in influence.

What we asked

To understand the scope of these unique types of open source projects, we ask the following questions…

RQ1: How do contributors define OSS for Social Good? 

RQ2: What motivations do contributors have to contribute to OSS for Social Good? 

RQ3: What factors do contributors consider to select an OSS for Social Good project? 

RQ4: What are the current challenges to work in OSS for Social Good?

To answer these questions, we conducted a mixed-methods study of semi-structured interviews with Open Source for Social Good (OSS4SG) contributors and distributed a large scale survey to OSS and OSS4SG contributors. We identified OSS4SG projects from Ovio and the Digital Public Goods and strategically selected project topics from those platforms. Additional details on our sampling approach can be found in the paper.

In total, we interviewed 21 OSS4SG contributors and received 517 valid survey responses (8.97% response rate) from OSS and OSS4SG contributors.

What we found

For RQ1, “How do contributors define OSS for Social Good?”, we found that there are core properties that influenced participants perspective of OSS4SG:

  • Whether the project targets people or communities that need help
  • Whether the project aims to solve some societal issues or provide social benefits

Another priority that was mentioned but was not as prevalently featured in our survey was whether the project is for profit or not.

For RQ2, “What motivations do contributors have to contribute to OSS for Social Good?”, we found that OSS4SG contributors were slightly more motivated by the desire to solve a societal issue rather than building something for their own career or school project (more data on this can be found in the figure below). This result encourages us to think about how people decide that an OSS4SG project aligns with these motivations.

For RQ3, “What factors do contributors consider to select an OSS for Social Good project?”, we found that there are several factors that influence the selection process. One consideration that stood out was who the owners of the project are:

If it’s even a charity organization I go and look at who their sponsors are. And if it’s a government I’m already like, no, it’s not gonna happen. A political party maybe. But government is too far for me.” (P14

From our survey responses, we found the OSS4SG group cared significantly more about whether they trusted the owner of the project they were contributing to. Other strategies for identifying projects included having a personal connection to the projects through a friend and also resonating with the issue this project is trying to solve.

To better understand differences in the scale of impact people desired to have on these projects, we designed a set of trolley problem style questions across 3 levels of psychological distance: spatial, temporal, and social proximity. In this survey we found that contributors in our survey overall preferred to work on a project with a global need, would have long term benefits, and that would contribute to a need someone they know personally has (see Table 5 for more).

For RQ4, “What are the current challenges to work in OSS for Social Good?”, we found that there are several challenges including finding a project to contribute to and securing consistent funding:

“It is difficult to know where the projects are. Where the communities are. And getting involved in it. There are many, many, many developers that might want to contribute, but they never get, you know, an announce or publication, a post, something.” (P1) 

“I honestly think the hardest thing about working on social good is very frequently they’re funded by charities, so it’s very hard to get people’s full focus on it. Like, paid full focus on it.” (P4) 

Although we explicitly sought to find challenges that exist for the OSS4SG projects, these issues resonate for the broader open source community as well. However, for OSS4SG projects in particular, these challenges present higher risks for the sustainability as global citizens are more likely to be relying on these projects. 

What this means

From this work, we’ve been able to capture a more confident understanding of Open Source Software for social good in hopes of being able to better support these projects. We’ve outlined a couple opportunities to help the OSS4SG community grow such as highlighting the societal impacts of the project more explicitly through semi-automated badging processes. We also suggest more safety and privacy guidelines to protect contributors working on these high impact (and sometimes polarizing) projects.

Read more

The formal research paper, Leaving My Fingerprints: Motivations and Challenges of Contributing to OSS for Social Good by Yu HuangDenae Ford, and Thomas Zimmermann is published at ICSE‘ 21, 43rd ACM/IEEE International Conference on Software Engineering

The presentation from my former intern Yu Huang’s talk, paper, and study materials are available locally online. This work was also featured in the 2020 GitHub Octoverse report and highlighted on GitHub’s Social Impact website.

Since this work has been published we have also conducted additional research investigating how to support developers growing their open source skills, matching developers who want to contribute to social good projects, and offering community tracking tools to the maintainers and organizers that keep these projects afloat. In fact, the follow ups from this work have also inspired how GitHub measures and sustains newcomer activity through GitHub Discussions Insights Dashboard. I am very proud of the work my interns Jenny T. Liang, Nischal Shrestha, and Mariam Guizani completed that summer.

To find the latest project updates be sure to check out the project website!

The GitHub Social Impact, Tech for Social Good Team partnered with OBI Digital to conduct a deeper investigation into open source work as digital public goods in low- and middle-income countries. This teams included Director Mala Kumar, Gina Assaf, Priyanka Patha, Yacoub Saad, and a host of others. Their in-depth study focused on the countries on India, Kenya, Egypt, and Mexico highlighting opportunities for sustainability and inclusive design. You can check out their summaries on their project website (which also includes the report available in English, Arabic, and Spanish)!

Advertisement

How Programmers REALLY Look at Pull Requests

Social signals are in fact a factor when reviewing a pull request, even when programmers don’t think they are.

Simply put, pull requests are the decoupled process of submitting code to a repository and having it reviewed by others. There’s a bit of unclarity on the decision process from the pull request being opened to the ending outcome of the pull request being merged or closed. Often times this process seems unlawful, bias, and even like a game of pull request roulette is happening to the submitter (or even amongst the project maintainers).

This research unveils this mysterious process within the context of GitHub—an online programming community which embodies this process while also highlighting a detailed profile of users and their activity.

To understand more of the process of signals that are used to determine we build on prior work and conduct an eye-tracking experiment where we go into depth about this process.

What we asked

RQ1: How do programmers review pull requests?

RQ2: Where do programmers think they look vs. where they really look?

RQ3: What strategies do people use to manage signals for their personal identity?

In order to gain insight into the process, we conducted an eye-tracking experiment in which we presented participants with a profile page and pull request. Then we asked them the likelihood of either accepting (merging) or declining (closing) the pull requests.

In our analysis, we classified different Areas of Interests (AOIs) to fit into three categories:

Code signals → areas where the primary content is code

Technical signals → areas where content provides evidence of technical skills or experience

Social signals → areas that communicate unique identifying information about the user

Findings

For RQ1, we find that although programmers focused on code signals the most (mean = 57.15%, median = 64.23%), they also considered technical (mean = 32.42%, median = 28.45%) and social signals (mean = 10.43%, median = 7.38%) as well. The figure below demonstrates how programmers spent their time during the experiment.

For RQ2, we find that programmers review more social signals than reported. As the ranged dot plot below shows, we compared the AOIs they fixated upon and the areas they reported reviewing in the post-survey. One particularly interesting result to point out here is that only 1 developer reported using the submitter’s avatar image(labeled AI in the figure), however, all participants reviewed that element of the profile.

blog-fig-2

For RQ3, we find that programmers use different strategies in traditionally technical online communities (e.g, GitHub) than in traditionally social ones (e.g., Facebook). Our multi-cycle qualitative analysis resulted in 5 themes centered around approaches to protecting their identity and their contributions.

One theme, in particular, emphasized that ’Nameless code should stand alone’. One participant described how they segment their identity across platforms in hopes to encourage the merit-based evaluation of their technical contributions:

“I prefer using my real name on social media platforms but I use other names when it comes to technical communities, I’ve different accounts for the different kinds of work. [...] It may be because my code has nothing to do with my name or my image, the code needs to talk for itself.” (S26)

This strategy can be helpful for implicitly encouraging pull request reviewers. But is it enough to reduce the bias to social signals that reviewers already have? Who’s to say this doesn’t further insight reviewers to rummage online searching for a submitter’s technical clout that warranted an audacious pull request?

Discussion

From a broader perspective, these signals can be seen as representing the submitters’ social and human capital: human capital refers to an individual’s ability while social capital is derived from interactions with others. Such capital can be made explicit using reputation scores as, e.g., customary at Stack Overflow, or visualized using badges akin to those used on GitHub to represent the status of a project. In the future, platform designers must be more mindful in balancing the power of signals that can amplify bias or harm against users, while still providing mechanisms for users to freely evaluate the merits of potential code contributions.

Conclusion

With the data we have presented in this paper, we can say that our findings are in chorus with previous studies:

Social signals are in fact a factor when reviewing a pull request, even when programmers don’t think they are.

We can also say that software developers use strategies for sharing an identity that may also not match up the strategies they expect from others. We will have to conduct further analysis to understand how the types of signals available can influence decisions.

Read more

The formal research paper, Beyond the Code Itself: How Programmers Really Look at Pull Requests by Denae Ford, Mahnaz Behroozi, Alexander Serebrenik, and Chris Parnin is published at ICSE‘19, 41st ACM/IEEE International Conference on Software Engineering, in the Software Engineering in Society track (ICSE SEIS).

The slides from my talk, paper, and study materials are available locally on my website.

%d bloggers like this: