PaperlayerView exact revision on arXiv

Source-linked AI summary

What's in a GitHub Star? Understanding Repository Starring Practices in a Social Coding Platform

Hudson Borges, Marco Tulio Valente

arXiv:1811.07643v1cs.SE

TL;DR

The practical meaning of GitHub repository starring lacked an in-depth empirical investigation. The paper quantitatively characterizes highly starred repositories and reports that three out of four developers consider stars before using or contributing to projects.

  • Problem

    The practical meaning of GitHub repository starring had not been the subject of an in-depth empirical investigation.

  • Method

    The paper provides a quantitative characterization of the top-5,000 most starred repositories and investigates the impact of new features on stars.

  • Results

    Three out of four developers consider repository stars before using or contributing to GitHub projects, while stars show no correlation with repository age.

  • Takeaways & Limitations

    Repository stars are considered by many developers when selecting projects, although stars do not correlate with repository age.

  • Takeaways & Limitations

    The growth-pattern analysis depends on the selected number of clusters, and manual classification is subject to errors and inaccuracies.

Abstract

from arXiv · show

Besides a git-based version control system, GitHub integrates several social coding features. Particularly, GitHub users can star a repository, presumably to manifest interest or satisfaction with an open source project. However, the real and practical meaning of starring a project was never the subject of an in-depth and well-founded empirical investigation. Therefore, we provide in this paper a throughout study on the meaning, characteristics, and dynamic growth of GitHub stars. First, by surveying 791 developers, we report that three out of four developers consider the number of stars before using or contributing to a GitHub project. Then, we report a quantitative analysis on the characteristics of the top-5,000 most starred GitHub repositories. We propose four patterns to describe stars growth, which are derived after clustering the time series representing the number of stars of the studied repositories; we also reveal the perception of 115 developers about these growth patterns. To conclude, we provide a list of recommendations to open source project managers (e.g., on the importance of social media promotion) and to GitHub users and Software Engineering researchers (e.g., on the risks faced when selecting projects by GitHub stars).

1. Introduction

The paper investigates the practical meaning and growth of GitHub stars, motivated by their use in project selection despite limited empirical evidence. It combines surveys with quantitative analysis to characterize starring practices, growth patterns, and associated risks.

  • Motivating Survey: 83% of survey answers rated stars as useful or very useful for assessing GitHub project popularity.Stars received scores of 3 or 4 from 31% and 52% of respondents, respectively.
  • Motivation: Stars are used by researchers and developers when selecting GitHub projects, creating risks because popularity may reflect active marketing.The paper warns that selection may favor projects with marketing and advertising strategies over projects following established engineering practices.
  • Proposed Study: Four star-growth patterns—slow, moderate, fast, and viral—describe repositories’ differing growth trajectories.The patterns were derived from clustered time series of repository stars.
  • Proposed Study: The study extends prior analysis from 2,500 to 5,000 public GitHub repositories.It also adds surveys of 791 developers and 115 project owners.
  • Contributions: The paper recommends that maintainers monitor stars and emphasizes active promotion, particularly through social media.It also provides a public dataset and an open source tool for exploring star histories and growth patterns.

2. Dataset

The dataset comprises the top 5,000 public GitHub repositories by star count, characterized using repository metadata, historical star events, languages, ownership, and manually classified domains. Its coverage emphasizes highly starred projects but excludes 18 repositories from time-series analyses because complete star histories were unavailable.

  • Dataset Construction: The dataset contains the top 5,000 public repositories by number of GitHub stars.Repository data were collected through the GitHub API, including historical star events.
  • Dataset Limitations: 18 repositories with more than 40K stars were excluded from Sections 5–7 because all star events could not be retrieved.The exclusion affects analyses requiring complete time series for clustering and growth-pattern derivation.
  • Star Counts: Repository star counts range from 1,596 to 224,136, with a median of 2,866.The minimum is for mapnik/mapnik and the maximum for FreeCodeCamp/FreeCodeCamp.
  • Repository Characteristics: The dataset’s first, second, and third quartiles are 114, 186, and 272 weeks for age; 102, 393, and 1,230 for commits; 8, 25, and 64 for contributors; and 252, 460, and 879 for forks.These distributions indicate repositories with substantial development histories and participation.
  • Programming Languages: JavaScript is the most common primary language, appearing in 1,559 repositories (31.1%), followed by Ruby in 305 (6.1%).The dataset spans 71 languages.
  • Ownership: Users own 2,569 repositories (51.3%), while organizations own 2,431 (48.7%).Ownership was obtained from repository metadata.

3. Survey Study

The survey investigated why developers star GitHub repositories and whether stars influence decisions to use or contribute to projects. Developers mainly used stars for appreciation, bookmarking, or project usage, and three out of four considered star counts before using or contributing.

  • Survey design: The survey used open-ended questions and thematic analysis to examine developers’ starring motivations and whether stars affect closer project relationships.The questions addressed why participants starred a repository and whether they considered its star count before using or contributing.
  • Why developers star: 4.6% starred because of third-party recommendations, while 0.6% did not know or remember why they starred the repositories.Recommendations came from friends, websites, or other developers.
  • Why developers star: 52.5% starred to show appreciation, 51.1% to bookmark projects for later retrieval, and 36.7% because they used or were using the projects.Responses could receive more than one theme, so these percentages are not mutually exclusive.
  • Stars in project decisions: 73% considered the number of stars before using or contributing, while 23.3% did not and 3.7% did not answer.Among those who considered stars, 29.3% also evaluated factors such as source-code quality, license, and documentation.
  • Stars in project decisions: Among respondents who considered stars, 26.5% described star counts as highly influential, while 8.8% considered them for using but not contributing.Some responses linked a minimum number of stars with confidence that a project would not soon become unmaintained.

4. Characterization Study

The characterization study analyzed star counts across 5,000 GitHub repositories by language, domain, owner, and repository characteristics. Stars were unrelated to repository age but showed low correlation with commits and moderate correlation with contributors and forks.

  • Study scope: The study expanded the analyzed sample from 2,500 to 5,000 public GitHub repositories and examined four research questions about star distributions and correlations.The questions covered programming language, application domain, repository owner, age, commits, contributors, forks, star timing, and release effects.
  • Distributions by owner: Repositories owned by organizations had a median of 3,067 stars versus 2,723 for user-owned repositories, with p-value < 0.001 and Cohen’s d = −0.178.The authors describe this as a statistically different distribution with a very small effect size.
  • Distributions by language and domain: JavaScript repositories had the highest median star count at 3,163 stars, while non-web libraries and frameworks had the lowest at 2,642 stars.Application-domain distributions differed significantly, with p-value < 0.001.
  • Correlation analysis: Only 28 systems, or 0.56%, had more forks than stars.Examples included a forking tutorial and a popular puzzle game whose success motivated many variations.

RQ #3: How early do repositories get their stars?

Repositories tended to receive stars soon after becoming public, followed by a more stable growth rate. Early concentration varied substantially across repositories, with many reaching initial star milestones quickly.

  • Star timing: Around 32% of repositories received 10% of their stars in the first days after the initial public release.The authors hypothesize that early adopters contributed many of these initial stars.
  • Star timing: Half of the repositories took 48% of their age to receive 50% of their stars, while around half took 87% of their age to receive 90%.These results indicate an initial burst followed by slower, more stable growth.
  • Star timing: During the first four weeks, the fraction of stars gained had quartiles of 0.4%, 7.0%, and 21.6%.The cited values are the first, second, and third quartiles, respectively.
  • Star timing: During the last four weeks, the fraction of stars gained had quartiles of 0.8%, 1.6%, and 2.7%.The distributions for the first and last four weeks differed with p-value < 0.001 and Cohen’s d = 0.856.
  • Star timing: The study summarizes repository star growth as greater immediately after public release, followed by a tendency for the growth rate to stabilize.This conclusion is stated as the section summary.

RQ #4: What is the impact of new features on stars?

The release analysis examined whether new features coincide with increased star acquisition. Stars were concentrated after releases for some repositories, but the effect generally declined after the first few weeks and was small when comparing major releases with other releases.

  • Post-release stars: For Reportr/dashboard, 52.5% of stars were gained in weeks following releases, while those weeks represented only 1.9% of the repository’s age.The resulting RAll was 27.047, indicating disproportionately many stars during post-release weeks for this repository.
  • Post-release stars: For all releases, the first-week post-release star fraction had quartiles of 1.0%, 3.1%, and 10.5%; for major releases, the values were 0.5%, 1.2%, and 3.8%.The all-release and major-release distributions differed with p-value < 0.001, but Cohen’s d = 0.316 indicated a small effect size.
  • Post-release stars: The repository yarnpkg/yarn gained 83.0% of its 21,809 stars in weeks following releases during its first year.The repository had the highest fraction of post-release stars among the example repositories discussed.
  • Post-release stars: Across repositories, RAll quartiles were 0.89, 1.35, and 2.20, while RMajor quartiles were 0.83, 1.49, and 3.37.These ratios compare post-release star fractions with the corresponding fractions of repository age.
  • Post-release stars: The median RAll and RMajor ratios decreased as the post-release interval expanded from one to four weeks.The analysis computed ratios using stars gained after n weeks, with 1 ≤ n ≤ 4.
  • Implications: Star-based selection favors JavaScript systems, web libraries and frameworks, large projects, and projects whose stars arrive in short intervals such as after public release.The authors recommend checking these selection effects when choosing projects for empirical studies or practice.

5. Stars Growth Patterns

Using KSC clustering on one-year star time series, the study identifies four repository growth patterns—Slow, Moderate, Fast, and Viral—and examines their ranking dynamics.

  • Clustering method: The KSC algorithm assigns equal-length star time series to clusters using a scaling- and shifting-invariant distance metric.This reduces the influence of outliers during centroid refinement.
  • Clustering method: Four clusters were selected because βCV values stabilized from k = 4 onward.The study used four clusters after observing near-stable βCV values for k = 4, 6, and 7.
  • Proposed growth patterns: The four clusters represent Slow, Moderate, Fast, and Viral growth, with the first three suggesting linear growth and the fourth sudden growth.The analysis compares projects using their most recent 52 weeks of stars.
  • Pattern prevalence: 58.2% of repositories followed Slow growth, compared with 30.0% Moderate and 9.3% Fast growth.The corresponding centroid star increases were 19.8%, 63.9%, and 218.6% over one year.
  • Pattern prevalence: Viral growth was uncommon at 2.3% of repositories but included sharp increases such as 19,270 stars in two weeks.The examples include Apollo–11 and tesseract.js.
  • Ranking dynamics: At least 75% of Slow repositories lost ranking positions, whereas 109 of 110 Viral repositories improved their ranks.Ranking distributions differed significantly across patterns, with p-value < 0.001.

6. Growth Patterns Characterization

The study characterizes growth patterns using 31 repository, owner, and activity factors, then evaluates their discriminative importance with Random Forest. Age, Issues, and Last Push are especially influential, while prediction is weakest for Viral growth.

  • Factors and classification: The analysis collected 31 factors across Repository, Owner, and Activity dimensions to distinguish the four growth patterns.The factors include repository-page characteristics, owner attributes, and coding activity during the analyzed period.
  • Factors and classification: Random Forest feature importance ranked the factors after hierarchical clustering removed highly correlated variables.The removed features were a.pull_requests, a.contributors, r.network, and o.type.
  • Most influential factors: Slow-growth repositories had the longest median time since their last update and the fewest commits, while Moderate and Fast repositories had more issues.Median weeks since last update were 3.53, 0.80, 0.52, and 0.49 for Slow, Moderate, Fast, and Viral growth.
  • Practical interpretation: Frequent updates, rich development history, and frequent releases tended to coincide with more stars, although the study cautions that correlation does not imply causation.Popularity could instead trigger frequent pushes, commits, and releases.
  • Classifier effectiveness: Random Forest achieved 65.81% precision, 68.40% recall, and 67.08% F-measure overall, with F-measure of 81.47% for Slow and 6.61% for Viral.The authors suggest exogenous factors may make Viral growth difficult to predict.
  • Most influential factors: Age was the most discriminative feature, followed by Issues and Last Push; slow growth was more common in older repositories.Fast and Viral growth were associated with newer repositories in the observed data.

7. Developers’ Perceptions on Growth Patterns

A second survey collected developers’ explanations for the four growth patterns and received 115 responses. Promotion, activity, technology trends, innovation, and audience characteristics were recurring explanations, varying by pattern.

  • Survey design: The survey received 115 responses from developers associated with sampled repositories, producing a 33.3% response ratio.Repositories were sampled across the four growth patterns, with fewer viral-growth participants because of public-email availability.
  • Slow growth: Slow growth was mainly attributed to deprecation or low activity, reported by 14 developers (53.8%).Surveyed developers also mentioned niche audiences, limited promotion, and project age.
  • Moderate growth: Moderate growth reflected both positive influences, such as promotion and active development, and constraints, such as niche audiences or limited promotion.Active promotion was cited by 15 developers (45.4%), while trending technologies were cited by nine (27.2%).
  • Fast growth: Fast growth was most often linked to active promotion, cited by 22 developers (64.7%), followed by trending technology and innovation.Trending technology was mentioned by 11 developers (32.3%), and innovation by eight (24.5%).
  • Viral growth: Viral growth was primarily linked to successful social-media posts, cited by 16 developers (72.7%), especially coverage on Hacker News.Code or documentation quality was mentioned by six developers (27.2%), and trending technologies by four (19.0%).
  • Cross-pattern findings: Across patterns, the survey connects star growth with promotion, project activity, technology trends, innovation, quality, usefulness, maturity, and audience scope.The reported explanations differ between slower and faster patterns rather than identifying one universal reason.

8. Threats to Validity

The validity of the study is constrained by its focus on highly starred repositories, one-year time series, manual classifications, and survey-response limitations.

  • Dataset scope: The dataset covers the top 5,000 repositories by stars, a small fraction of GitHub’s repository universe.The selection intentionally targets the most-starred projects rather than typical repositories.
  • Classification: Application domains were classified manually, making the domain labels vulnerable to errors and inaccuracies.The authors mitigated this threat by discussing dubious decisions together.
  • Survey analysis: The manual classification of survey answers may introduce interpretation errors despite the first author’s careful review.This limitation concerns deriving starring motivations from free-text responses.
  • Survey scope: The second survey produced 115 answers from a 33.3% response ratio, so perceptions reflect respondents rather than all contacted developers.Only developers with public email addresses were eligible for the sampled survey.

9. Related Work

Prior work uses GitHub stars and other popularity metrics to select and characterize repositories, while studies also examine popularity in mobile apps and social media. Research on project-selection rigor highlights that star-based selection can identify engineered projects but may miss many others.

  • Criteria for Selecting GitHub Projects: GitHub stars are widely used to select repositories for empirical software-engineering studies.Examples include studies of continuous integration, refactoring, language features, defects, and participation in open-source communities.
  • Criteria for Selecting GitHub Projects: Researchers have proposed alternatives and frameworks that select projects using diversity, fit, quality, engineering practices, or multiple repository metrics.STRESS supports user-defined diversity, fit, and quality, while Reaper targets documentation, testing, and project-management practices.
  • Criteria for Selecting GitHub Projects: Star-based selection has high precision but low recall for identifying engineered GitHub projects.Highly starred repositories are usually engineered projects, but many engineered projects do not have large star counts.
  • Studies on GitHub Popularity Metrics: Studies of GitHub popularity examine repository characteristics, social interactions, documentation, inactive assignees, programming-language influence, and relationships between popularity and perceived quality.Reported findings include more than 80% inactive assignees in some projects and evidence that popularity can affect perceived quality.
  • Popularity of Mobile Apps and Social Media Content: Mobile-app and social-media research likewise analyzes popularity through code properties, external promotion, updates, ratings, correlations among metrics, and popularity peaks.These studies span app success, survival, cross-platform ratings, YouTube videos, hashtags, and news-aggregator behavior.

10. Conclusion

The paper finds that developers star repositories for appreciation, bookmarking, and current use, and that stars matter when choosing whether to use or contribute to projects. Its analysis characterizes star counts and growth patterns, while its recommendations address promotion and risks in star-based project selection.

  • Meaning of GitHub Stars: 52.5% of developers reported starring repositories to show appreciation, alongside bookmarking projects and indicating current use.The reported reasons frequently overlap, and stars can function like “likes” on other social networks.
  • Importance to Practitioners: Three out of four developers consider GitHub stars before using or contributing to projects.The survey therefore confirms stars’ practical importance to practitioners.
  • Repository Characteristics: The top-5,000 repository analysis found more stars for organization-owned repositories and moderate correlations with contributors and forks.Stars showed low correlation with commits and no correlation with repository age.
  • Growth Patterns: Slow growth is mainly associated with deprecation or inactivity, while fast and viral growth is mainly associated with active promotion, trending technologies, or innovative projects.Moderate growth reflects both positive factors such as promotion and negative factors such as a niche audience.
  • Threats and Recommendations: Selecting projects by stars can favor large, highly connected, rapidly viral, or effectively marketed repositories that do not necessarily follow solid engineering practices.The authors recommend checking whether stars are concentrated in a short period or linked to social-media promotion.
Loading 1811.07643v1…