## 1 Introduction  
The prevention, identification, triage, and correction of bugs is a fundamental part of the software engineering process, which pervades, to some extent, all components of the software development lifecycle (SDLC). Although this is a normal and expected part of any non-trivial development effort, programmers should, and do, aim to minimize the occurrence of defects in code. In the open-source environment, where developers volunteer their time and efforts to building something large-scale, this effort garners even more attention. Developers work in cohesion, checking each other's code changes and ensuring that their additions do not impact others' work. In the past, some have argued that, by nature, open-source software (OSS) should have fewer bugs, and more importantly, fewer safety-critical bugs. This concept is known as [PERSON] law. It states, \"Given enough eyeballs, all bugs are shallow\". However, research by Synopsys Inc. has found that this may not necessarily be true [1]. Synopsys states that a mere number of bug researchers and project contributors may not be enough to catch all types of bugs, specifically Heartbleed Bugs, which are safety-critical. Due to this, the interest of the research and software development community in studying and formulating automatic bug detection algorithms has grown. Numerous methods have shown promise by leveraging techniques such as fuzzing [2], Graph Transformations [3], and Conditional Branch Enforcerments [4]. Some software-bug-tracking products have also surfaced, such as BackLog [5] and BUgZilla [6]. Whilethese techniques are yet to be widely adopted, developers currently use cutting-edge version control systems VCS and repository hosting services, such as GitHub and Maven, where they employ a combination of branches, patches, and pull requests to mitigate the introduction of bugs to the core software. These VCSs have two primary ways of preventing bugs. First, they allow other developers to review new code before finalizing it into the project, thus moderating its integrity and malicious or buggy code. Second, the VCS keeps a log of authors and their changes, which keeps developers accountable. If a developer consistently submits bugs, whether purposefully or not, they can be held responsible. This type of accountability was recently showcased by the Linux project's ban on the University of Minnesota [7]. Hence, while offering substantial benefits, using a VCS does not ensure that bugs are never introduced into projects. The work in Ref. [8] showed that roughly one-third of all commits made to 729 top projects across all programming languages on GitHub were for fixing bugs. These findings present an exciting research area: understanding how bugs are introduced and fixed and what factors affect the time it takes to fix them. In their study analyzing the time taken to fix bugs in Eclipse and Mozilla, two large-scale open source projects, Ref. [9] found that, on average, 61% of all bugs were fixed within three months, while 16.5% took as long as three years. The bugs, in their analysis, were of varying complexities and required varying efforts to fix them. To fully understand the science of bug-fixing in open source projects, a natural place to start is by analyzing simple bugs that can be fixed with a single line of code. Termed as SSTUBs, these bugs are rarely complex and do not require a computationally advanced fix. Studying these SSTUBs, their fix duration, and the factors that determine the fix duration will allow us to look at driving factors beyond the complexity of the language and the bug. A study of this kind on numerous open-source projects will present an opportunity to generalize simple bug fixing practices that developers employ. Our paper's objectives are two-fold: creating a process to find how long it takes to fix SSTUBs and analyzing the fix time across different bug types in the main development branch of popular open-source software projects written in Java.