Paper-to-Podcast

Paper Summary

Title: The Promises and Perils of Mining GitHub


Source: Proceedings of the 11th Working Conference on Mining Software Repositories


Authors: Eirini Kalliamvakou et al.


Published Date: 2014-05-31




Copy RSS Feed Link

Podcast Transcript

Hello, and welcome to paper-to-podcast.

Today, we're diving into a research paper that's as revealing as a magician's tell-all book, but instead of pulling rabbits out of hats, we're uncovering the hidden challenges of GitHub. The paper we're discussing is the riveting "The Promises and Perils of Mining GitHub," authored by Eirini Kalliamvakou and colleagues, and published on the 31st of May, 2014, in the Proceedings of the 11th Working Conference on Mining Software Repositories.

Now, prepare to be flabbergasted! Did you know that GitHub, the bustling metropolis of code collaboration, is actually teeming with digital hermits? A jaw-dropping 67% of projects on GitHub are personal projects with a single committer. That's right, GitHub is the prime real estate for lone wolves typing away in their coding dens.

And if you thought that was surprising, get ready for this: the median project on GitHub has only seen 9.9 days of activity and a grand total of six commits. To put it in perspective, that's like having a conversation with a snail. It's there, but it's not saying much.

But wait, there's more! Approximately three-quarters of the repositories are like forgotten leftovers in the back of the fridge, with no updates in the last half a year. And despite GitHub's "Fork & Pull" philosophy, a mere 10% of multi-committer projects actually dance the pull request tango. It's like hosting a masquerade ball and everyone showing up in their everyday clothes.

For those repositories that do engage in the pull request rumba, there's a plot twist: nearly 40% of pull requests that were merged are like ninjas—present, but not visible in GitHub's records. They're the Clark Kents of the coding world, secretly saving the day without a trace.

Now, how did the researchers uncover these findings? They started with an online survey, chatting with GitHub users like a curious barista asking about your day, to understand why people use GitHub beyond just software development. The responses were more varied than a box of assorted chocolates.

Then, they rolled up their sleeves and got quantitative, using the GHTorrent dataset to analyze project metadata like a detective scrutinizing clues. They also manually investigated a sample of 434 repositories, sorting them into categories with the precision of a librarian. They even developed heuristics to sniff out those elusive merged pull requests that were playing hide and seek.

The strength of this study lies in its Sherlock Holmes-level of detail. The researchers didn't just skim the surface; they plunged into the depths of GitHub, recognizing that it's a patchwork quilt of personal, inactive, and non-software projects. They surveyed, they sampled, they scrutinized, and they shared their methods for all to replicate, like an open cookbook for research.

However, every superhero has a weakness, and this study is no exception. Its reliance on GitHub as a lone data source is like using only one spice for every meal—it might not capture all the flavors of software development. The GHTorrent dataset, while comprehensive, isn't perfect, and the manual analysis could be influenced by the researchers' own biases, like a chef's personal taste affecting a recipe.

Still, the potential applications of this research are as varied as the projects on GitHub itself. From guiding software engineering research to improving GitHub's platform, from helping project managers to influencing how we teach coding and collaboration, this study is a treasure trove of insights.

So, whether you're a software engineer, an open-source aficionado, or just someone who enjoys a good data detective story, this paper is sure to pique your interest.

You can find this paper and more on the paper2podcast.com website.

Supporting Analysis

Findings:
One of the most eye-opening findings from the study is that a whopping 67% of projects on GitHub are actually personal projects with only a single committer, which suggests that GitHub isn't just a hub for collaborative software development—it's also a popular hangout for lone wolves working on their own code. Also, it turns out that most of the projects on GitHub are pretty quiet; the median project has had only 9.9 days of activity and a mere 6 commits. That's like the software development equivalent of a tumbleweed blowing through a ghost town! Another zinger is that about 75% of all the repositories are just hanging out and haven't had any updates in the last six months. And get this—despite GitHub being all about that "Fork & Pull" lifestyle for code changes, only 10% of projects with more than one committer actually used pull requests, which is kinda like throwing a party and nobody coming to dance. And for those repositories that do shimmy on the dance floor with pull requests, there's a bit of a twist: almost 40% of pull requests that were actually merged don't show up as merged in GitHub's records. Talk about a masquerade! It's like throwing on a superhero cape but everyone still knows you're just an average Joe.
Methods:
The researchers embarked on a multi-method investigation to understand the characteristics of GitHub repositories and how users engage with its features. Initially, they conducted an exploratory online survey with GitHub users to identify reasons for using the platform and the nature of collaboration. This survey revealed that GitHub is used for more than just software development, prompting a deeper dive into the data. The team then performed quantitative analysis using the GHTorrent dataset, which mirrors the data accessible through GitHub's API, to get insights into project metadata. This analysis focused on commit activity, the presence of forked repositories, and pull request usage. To complement their quantitative findings, they conducted a manual analysis of a sample of 434 GitHub repositories. This involved categorizing the repositories by their content and purpose, such as software development, academic projects, or personal storage. Additionally, they investigated the use of pull requests as a code review mechanism and identified several perils related to their detection and classification in GitHub. They developed heuristics to improve the detection of merged pull requests that were not identified by GitHub's native tools. The researchers also considered the completeness of the data on GitHub, acknowledging that some projects might use external tools for certain development activities. They suggested strategies to identify active software development projects and to avoid potential biases in the data.
Strengths:
What's most compelling about the research is how it peels back the layers of GitHub to reveal the complexities and challenges of using it as a data source for software engineering research. The researchers didn't just take the data at face value; they delved deep to uncover the nuances and potential biases that could skew research findings, which is a best practice in data-driven research. They acknowledged that while GitHub is a rich source of information, it's also a mixed bag with personal projects, inactive projects, and projects not intended for software development, all of which could lead to misleading conclusions if not carefully considered. The researchers followed several best practices in their methodology. Firstly, they conducted an exploratory survey to gather qualitative data from GitHub users, which informed the direction of their quantitative analysis. This mixed methods approach enriched their understanding and provided a solid foundation for their findings. Secondly, they used a large, representative sample of GitHub projects for manual analysis, ensuring a high confidence level in their statistical conclusions. Lastly, they developed heuristics to better identify merged pull requests, showing a dedication to accuracy in the face of incomplete data. They also provided a replication package, which reinforces the transparency and reproducibility of their research, a hallmark of rigorous scientific inquiry.
Limitations:
Some possible limitations of this research could include the reliance on the GitHub platform, which may not represent all software development practices and could limit the generalizability of the findings. The study's dependence on the GHTorrent dataset and its "best effort" approach may introduce inaccuracies or incomplete data, affecting the reliability of the results. Additionally, the manual analysis of GitHub repositories, while illustrative, could be subject to the researchers' interpretation, and the sample size may not capture the diversity of GitHub's millions of repositories. The survey approach could suffer from self-selection bias, as those who chose to respond may not represent the broader GitHub user population. Furthermore, the dynamic nature of GitHub means that the practices and usage patterns may have evolved since the data was collected, which could make the findings less applicable over time. Lastly, identifying non-software development repositories or personal projects requires manual classification, which can be subjective and may not scale well for larger datasets.
Applications:
The research into GitHub's use and data quality has several potential applications that could benefit various stakeholders: 1. **Software Engineering Research**: The insights regarding the perils and promises of mining GitHub data can guide future research efforts, ensuring more accurate studies on software development practices, collaboration, and open-source project dynamics. 2. **Project Management**: Understanding the activity levels and purposes behind GitHub repositories can help project managers and team leads make informed decisions about the health and viability of their projects. 3. **Platform Improvement**: GitHub itself could use these findings to improve its platform by addressing the needs of users who are leveraging the service for non-traditional purposes, such as personal projects or storage. 4. **Educational Use**: Educators and students could utilize the findings to better understand how social coding platforms are used, potentially influencing how coding and collaboration are taught in computer science courses. 5. **Tool Development**: Developers of third-party tools and integrations for GitHub could use these findings to refine their products to better serve the diverse uses and user base of GitHub. 6. **Community Building**: Open-source community leaders could apply the research to foster more active and engaged communities by understanding the factors that lead to successful collaboration on GitHub.