The appropriation of GitHub for curation

Motivations to curate in the social media era

Curation is a common practice in Archeology. It is the activity of collecting, evaluating, organizing, and preserving a set of resources for future use (Bamforth, 1986). In the Internet era, technology assists curation is commonly referred to by librarians and archivists as “digital curation” to preserve digital materials (Higgins, 2011). It can share features used for social bookmarking, where users specify keywords or tags for the Internet referencing that helps organize and share curated resources with a larger community (Farooq et al., 2007). There are several early popular social bookmarking tools, such as del.icio.us, which allows sharing of personal bookmarks (Golder & Huberman, 2006); Flickr, a photo tagging and sharing service (Marlow et al., 2006); and Reddit, a community-driven link sharing, comment, and rating service (Singer et al., 2014). Curation behaviors have been further studied since social media was appropriated to enable new forms of curation. Specifically, Duh et al. (2012) report the use of a third party tool, Togetter, for curating tweets, and uncover the intended purposes for these curated lists, including recording a conversation, writing a long article, or summarizing an event (Duh et al., 2012). Zhong et al. (2013) conduct surveys of Pinterest and Last.fm users and find that the majority users engage with the curation site for personal interests rather than social reasons (Zhong et al., 2013). A recent study examines the ways that communities leverage a variety of social tools for curation to support vital community activities in a large enterprise environment (Matthews et al., 2014). The authors also call for future studies on curation in public Internet communities (Matthews et al., 2014).

Curation on GitHub is a unique instance of curation set apart from the above studies in the following ways. First, the user body of GitHub is drastically different. Services like Twitter, Pinterest, and Reddit, are services for the general population with diverse backgrounds and interests, while GitHub is intended for a focused community of software developers. Members of the software developers’ community share a set of common goals and practices, which is likely to affect their participation in curation practices as well. Second, unlike Pinterest, which itself is designed for curation of links, GitHub is an online work platform designed for software developers to collaborate with others on software projects, and curation is an appropriation of the collaborative coding features of the platform. The reasons behind such appropriation and whether GitHub features fully meet curation needs of developers are yet to be discovered. Third, the technology affordances of GitHub largely depart from the above mentioned services. Tools like Pinterest and Flickr, are designed for personal collection and sharing of hyper links. Reddit allows users to vote to promote links, but it hardly preserves resources. GitHub provides a collaborative working space, i.e., the repository, where software developers can work on the same project together and are enforced by Git workflow. Therefore, GitHub is distinct regarding user base, intended purpose, as well as technology affordances. Its appropriation for curation purpose raises an interesting question concerning user’s motivations and experiences.

Software developers’ motivations for participating online communities

Researchers report two main categories of motivations that drive software developers’ voluntary participation in open source software projects: (1) internal motivations, i.e., intrinsic motivations, altruism, and community identification, and (2) external rewards, including expected future rewards and personal needs (Hars & Ou, 2001; Ye & Kishida, 2003). Internal factors include “intrinsic motivation”, which refers to the feeling of competence, satisfaction, and fulfillment as a motivator to participate in open source projects; “altruism” refers to software developers desire to care for others’ welfare at own cost; and “community identification” refers to individual software developers’ alignment of goals with the larger community. External factors include “future rewards” that are inured when software developers view their participation as investment, and expected future returns, including revenues from related products and services, human capital, self-marketing, and peer recognition; “Personal needs” are software developers’ personal demand for their activity, for example, Perl programming language and Apache web server both grew out of software developers’ self-interests to support their work (Hars & Ou, 2001). Both internal and external factors are important motivations that drive software developers’ participation in open source projects.

The rise of social media impacts the way software developers participate in online space. Social media are often referred to as socially enabled tools, where social features are added to software engineering tools (Storey et al., 2014). It lowers the barrier to publishing information, allows fast diffusion, and enables communication at scale, which facilitates a “Participatory Culture” in the software developers’ community (Storey et al., 2014; Jenkins et al., 2009). As a result, software developers increasingly participate in the community via social media that enhances learning, communication, and collaboration (Dabbish et al., 2012; Doll, 2013; Singer et al., 2013). Similarly, software developers are motivated to participate in order to satisfy personal needs (e.g., improve technical skills) and to gain peer recognition (e.g., recognition by the community) (Storey et al., 2014).

Despite the well-studied motivations for software developers’ participation in online communities, software developers’ motivation to engage in curation practices within GitHub by appropriating a collaboration software development features are currently under-explored.

Prior GitHub research

GitHub has drawn attention from researchers in recent years, who have examined its features that promote transparency, such as activity traces, user profiles, issue trackers, source code hosting, and collaboration (Storey et al., 2014; Dabbish et al., 2013). Researchers have examined in detail how such transparency allows software developers to engage with software practices in the community (Dabbish et al., 2012; Doll, 2013; Singer et al., 2013). For example, Dabbish et al. (2012) find that the activity logs and user profiles on GitHub motivate members to contribute to software projects (Dabbish et al., 2012). Marlow, Dabbish & Herbsleb (2013) discover that developers use a variety of social cues available on GitHub to form impressions of others, which in turn moderates their collaboration (Marlow, Dabbish & Herbsleb, 2013). Singer et al. (2013) put GitHub in a larger social media environment, and learned that software developers leverage transparency of socially enabled tools across many social media services for mutual assessment (Singer et al., 2013).

These studies focus on how the technology accordances of GitHub and other social media affect software practices, including learning, communication, and collaboration (Storey et al., 2014). Curation as an emerging practice on GitHub raises interesting questions as to the reasons that such practice is thriving in the software developers’ community, why it emerges and gains popularity on GitHub, and whether GitHub features fully support this type of practice.

Appropriating GitHub for curation

Curation practices are enabled by GitHub features. Specifically, GitHub introduces a README.md file in the root directory of each repository. The contents of the README.md file are displayed in the front page of the repository, i.e., if a user visits the URL of a software repository hosted on GitHub in a browser, the README.md file will be displayed as a web page (Fig. 1) (https://github.com/avelino/awesome-go) along with repository structure and some project statistics, such as the number of forks and stars (McDonald & Goggins, 2013). The content of REAME.md file can be structured with Markdown syntax (https://help.github.com/articles/basic-writing-and-formatting-syntax), which provides rich text features, including table of contents, links, tables, etc. README.md is designed for adding description and documentation for a repository (https://help.github.com/articles/create-a-repo).

Curation on GitHub appropriates the README.md file of a repository to create a list of resource indexes within one page. It categorizes resources into different themes and differentiates them into sections. Typically, each resource is recorded with the resource name and a brief description of the resource (see Fig. 1). In addition, URLs are attached to each of the curated items. Clicking a resource name (shown in blue in Fig. 1) will direct the user to the real web location of the resource.

Participants recruitment

To identify participants engaged in curation practices, we queried the GitHub search API on 12/07/2015 using the keyword “curated list” to search for curation repositories. The query returned 896 repositories hosted on GitHub. We recorded the owner’s user ID for each repository in the list, then we queried GitHub API again to fetch profiles with email addresses of each ID. The query returned 405 unique owners with email addresses, which we used to create a randomized list and sent 172 email invitations to curation project owners. Recipients were asked to engage in a semi-structured online text-based interview carried out via Facebook Messenger, Skype, or Google Hangouts. We began our recruitment process in early December 2015 and completed all interviews in late January 2016.

The resulting 16 participants included 15 males and one female with GitHub experiences ranging from six months to six years. Fourteen of the participants are professional software engineers, one was a graduate student, and one was a microbiologist. Eleven participants used the descriptive word “awesome” as the prefix to name their curation repository. The participants had a varying number of followers: five had less than 10 followers; eight had between 10 and 50 followers, and four had more than 50 followers. In the following section, we refer to individuals by participant number (from P1 to P16).

Interview protocol

We conducted text-based online interview with participants, and each discussion lasted approximately 30 to 60 min. The interviews were semi-structured by the four general areas below.

• Motivations to curate resources,

• Reasons for technology choice (GitHub),

• How curated lists are useful,

• The limitations of current curation practices (on GitHub).

Questions were administered conversationally to engage the participants, and they were open-ended enough that we could pursue new topics raised by the participant.

Participants were interviewed in English. The interview scripts were then downloaded for analysis.

Data analysis procedure

We conducted our iterative analysis through four rounds of interviews allowing the first round of analysis to guide our second round of interviews, and following similarly in the third and the fourth. Themes and codes were identified, discussed, and refined in this process (Lacey & Luff, 2001).

In the first round of analysis, we performed open coding on the responses (Strauss, 1987), grouping examples that are conceptually similar. For each subsequent round of interview, we compared concepts and categories that are similar to previous ones. And in this process, we continued to refine our coding scheme while also revealing new ones. We discussed the codes collaboratively and repeatedly. We concluded the study after reaching the point of theoretical saturation, when categories, themes, and explanations repeated from the data (Marshall, 1996). A second researcher independently coded four sample interviews transcripts. Our analysis showed inter-coder agreement between the two researchers (kappa = 0.73).

In the process of coding, we recognized that some themes and categories are consistent with prior literature, i.e., curator motivations (altruism, personal needs, and peer recognition). Instead of developing new categories, we labeled them according to existing literature. The complete coding scheme is shown in Table 1.

Motivations to curate

Internal factors (i.e., altruism, community identification, and intrinsic motivation) and external rewards (i.e., personal needs and peer recognition) are identified as motivating factors in software developers’ participation in open source software projects (Hars & Ou, 2001). In this study, our participants confirmed altruism (62.5%), personal needs (93.8%), and peer recognition (31.2%) motivated their participation in curation projects.

The technology choice—why GitHub

Compared to the GitHub platform, the features on sites like Wikipedia might be considered better suited for hosting curation projects by providing convenient editing and collaborating features. However, popularly used and referenced curation projects for software developers are predominantly hosted on GitHub, whose features and information structures are designed for source code hosting and project collaborating (Marlow, Dabbish & Herbsleb, 2013; Storey et al., 2014) rather than creating and preserving lists of resources. In this section, we will address why curation has emerged as a common way to appropriate GitHub repositories.

The use of curated resources

Curated resources are useful for software developers to support their work, learn about a new topic, as well as communicate with others.

Limitations of using github for curation

In this section, we summarize constraints that our participants have encountered when carrying out curation on GitHub.

Curator motivations

One primary motivation for engaging in curation is altruism, which is also widely recognized as an important motivation for software developers’ participation in open source projects (Hars & Ou, 2001; Lakhani & Wolf, 2003; Ye & Kishida, 2003). This finding indicates that helping behaviors may be a common reason why software developers are motivated to participate in some online activities. Thus, when designing systems for facilitating software development related practices, we should consider software developers’ desire to support each other.

Enjoyment-based intrinsic motivations are the primary reason that software developers take part in open source projects, but were not specifically mentioned by the participants as a drive for engaging in curation. Researchers have learned that intrinsic motivations drive software developers to spend more time and effort on open source projects (Lakhani & Wolf, 2003), and it is positively reinforced by community recognition (Ye & Kishida, 2003). Therefore, many software developers commit themselves to open source projects for a relatively long time. At the same time, altruism alone is recognized as an unsustainable incentive for open source participation (Ye & Kishida, 2003). The comparison of motivations to curation with participation in open source projects leads to questions concerning curators’ long-term engagement, such as whether intrinsic motivations are involved in driving curators, whether altruism can sustain curator’s long-term participation in curation activities, and if not, whether there is a mechanism that regularly feeds curators’ motivations to curate. The answers to these questions are beyond the scope of this study and requires further investigation.

Leveraging github as a tool for communication

While GitHub is known as a tool for software projects hosting and collaborating (Dabbish et al., 2012; Marlow, Dabbish & Herbsleb, 2013), and communicating knowledge in software artifacts (Storey et al., 2014). This study finds that GitHub is also a good tool for communication of socially generated resources for developers. Here, we describe the features that have supported this practice.

First, GitHub features allow curation repositories to be shared easily. With a robust version control system as we as uniquely assigned public URL for each GitHub repository, GitHub guarantees the integrity and durability of curated contents and enables easy sharing. These technical features make GitHub repositories ideal for communicating resources with others.

Second, GitHub attracts potential audiences who can contribute to curation repositories. By connecting to relevant audience group, GitHub allows others to suggest potential curated items and evaluate existing ones. As such, the emerging of curation repositories indicates that software developers’ community starts to utilize GitHub for communicating knowledge that is socially generated and maintained (Storey et al., 2014).

GitHub as a communication tool establishes its flexibility and reconfigurability. With a simple appropriation of its features, GitHub becomes a favorite tool intended for curation purposes in software developers’ community. Such reconfigurability will lead to other practices besides curation, which can further benefit software developers’ community. For example, GitHub users started to appropriate GitHub repositories to write and publish software development related books (https://github.com/getify/Functional-Light-JS/), which accepted community suggestions as well as changes. Also, software developers initiated sharing training materials for others to discuss related matters as well as retrieving improvements (https://github.com/kentcdodds/es6-workshop).

Curation to strengthen software developers’ community

Onboarding new members and educating existing members are essential for communities of practice to sustain and grow (Lave & Wenger, 1991; Wenger, 1998; Wenger & Snyder, 2000). The results of this study demonstrate that curation repositories on GitHub reflect these core utilities of communities of practices. Software development related resources are changing rapidly, and software developers usually rely on a number of services and channels, such as Stack Overflow and Twitter, to keep themselves up-to-date with the trend (Storey et al., 2014). By centralizing peer-reviewed resources in an active community of relevant audience, curation repositories create a reliable channel that simplifies the process of discovering high quality resources. They are likely to reduce the amount of efforts individual member of the community spent on locating and filtering the resources. In addition, as the curated resources are peer-reviewed, they are more likely to guide one’s learning of a certain topic than random resources encountered on the Internet. Thus curation repositories optimize the way that resources are disseminated and consumed in software developers’ community, which in turn helps the community to grow.

The importance of curation for the software developers’ community also raises interesting questions concerning the professional trajectories of the curators in the community. Curators relate the resource providers, i.e., software developers who develop tools, packages, frameworks, etc., with resource consumers, i.e., software developers who need to learn or work with tools, packages, frameworks, etc. In this sense, they are similar to brokers, who bridge different groups and control information flow in a community, and often bargain for better terms because of their unique positions (Burt, 2004; Burt, 2005; Van Liere, 2010). However, the existing studies of brokers either happen in the cooperate environment (Burt, 2004; Burt, 2005) or community networks (Carroll, 2012), and the brokerage is resulted from establishing social connections, which leads to social capital gain (Carroll, 2012; Burt, 2005; Van Liere, 2010). In contrast curators broker information by creating artifacts in an online social network environment. In this study, we have one participant who obtained a new job in part due to her work on a curation repository. However, whether curation helps curators bargain for better terms in general, and whether curators established social ties and how long such social ties exist as a result of curation requires future investigation.

Design implications and future directions

Our analysis describes GitHub as a technical infrastructure that meets the needs of curation practices. However, there is still substantial room for curation practices to improve. Our participants found that curating software related contents required a great deal of effort to filter resources and to actively maintain the existing ones. In addition, as the length of the curated list grows, it also creates navigational difficulties. The current conditions could be improved by (1) empowering curation with automated filtering tools, and (2) adding navigational support within a curated list.

Automated tools can reduce the amount of effort curators need to spend on curating processes. Curators currently do manual selection and evaluation of potential resources as well as eliminating outdated resources. Selections are usually achieved by employing search engines or following recommendations from others. Automated tools can help curators reduce the manual efforts spent on finding and maintaining resource lists. For example, some of our participants manually refer to third party tools to check resources status, such as last-updated-date. An automated tool that checks and filters resources according to query fields can largely diminish the noise and reduce time and efforts to select and evaluate resources. In addition, an automated tool can also help maintain existing resources, by checking whether a software project is still under active development or it is deprecated.

Providing navigational support aims at solving the following issues: (1) lengthy curated list, (2) lacking a search function, and (3) lacking common themes across different curation projects. To be more specific, anchored table of contents, which is fixated on the screen, gives readers a clear structure of a document, as well as enables them to jump among sections. This change would make navigating a long list easier. Adding a search function within a curation repository, allowing users to query keywords of the curated items, can help users explore and find ideal resources promptly. Also, templates can provide common structure and themes in different curation repositories. For instance, our participants mentioned that one of the features they wanted for each curation repository to have was to include a beginner’s section, where they could easily find out hands-on resources. Curation repositories could adopt a template that includes commonly identified themes, so that users will be familiar with the structure of different curation repositories and thus locate resources more efficiently.

Future work should seek feedback from GitHub users who are consumers of resources in curation projects. Together with what we have learned from this study, we will design and implement tools to help curators select, evaluate, and maintain resource lists more effectively, and allow users to navigate and retrieve desirable resources readily.

Limitations

Our study was a qualitative investigation of self-reported curation practices and experiences of GitHub developers. More specifically, we did not carry out a controlled study to manipulate hypothesized causal relationships among constructs. Also, due to our limited sample size, cross tabulations among responses were unlikely to be generalizable to the larger population of curation repository owners. A general limitation of qualitative field methods is that some well-known approaches to validity, associated with positivist science, cannot be employed, such as construct validity, statistical validity, or predictive validity. For a qualitative research design such as ours, credibility and transferability are key validity issues: credibility is whether the results are believable and transferability refers to the degree to which the results can be transferred to other settings (Guba, 1981; Hoepfl, 1997).

Credibility. We tried to ensure credibility by having two researchers code the data independently, and then calculating the kappa statistic to assess coding agreement. In addition, we used member checking in the interview process to have participants directly corroborate findings. These two approaches were encouraging and convergent, indicating very good credibility for our reported findings (Lincoln & Guba, 1985). We acknowledge that this is only a starting point in understanding curation practices in GitHub, but it succeeded in raising many issues that could be pursued now in more constrained research designs.

Transferability. There are several potential threats to the transferability of this study. First, the owners of the most popular curation repositories did not respond to our interview invitation. Given those celebrity curators’ massive audience base and extensively received contributions and attentions, their motivations and practices might be different from the general curators we focused in this study. Second, the way we recruited our participants was to use the keyword “curated list to search through repository descriptions on GitHub and identified repository owners as our potential interviewers. This search method is transparent and direct, but may have missed curation repositories and owners that did not self-identify with our keywords. Follow-up research can expand the criteria for identifying repositories to further develop our findings. Finally, all of the curators we investigated were recruited on public GitHub, so our results may not generalize to closed source systems. This is another direction for subsequent research to develop our initial findings.