# Fall in GitHub code frequency

**URL:** <https://discourse.julialang.org/t/fall-in-github-code-frequency/46941>\
**Category:** General Usage\
**Tags:** question\
**Created:** [September 19, 2020, 11:18pm UTC](https://discourse.julialang.org/t/fall-in-github-code-frequency/46941 "2020-09-19T23:18:15Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![rakesh4real](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/rakesh4real/32/18889_2.png) [@rakesh4real](https://discourse.julialang.org/u/rakesh4real)\
**Post date:** [September 19, 2020, 11:18pm UTC](https://discourse.julialang.org/t/fall-in-github-code-frequency/46941/1 "2020-09-19T23:18:15Z")

</div>

Hi,

I work extensively in deep learning projects and had known Julia for quite a while. Today, I was skimming through [code frequency graph](https://github.com/JuliaLang/julia/graphs/code-frequency) and the **fall really concerned me**. Can I know if is something that I should worry about when I think about Julia is going in the right direction to achieve what it it was really meant to achieve?

 ![image](https://global.discourse-cdn.com/julialang/original/3X/6/b/6bbc4cf6f2778a446322a47bab8f8e5f5fd5d4f1.png)

Thanks,  
Rakesh

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [September 19, 2020, 11:32pm UTC](https://discourse.julialang.org/t/fall-in-github-code-frequency/46941/2 "2020-09-19T23:32:32Z")

</div>

Why does this matter? This plot doesn’t include the package ecosystem which is where the vast majority of the work is.

---

<div class="post-metadata">

**Author:** ![giordano](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/giordano/32/2166_2.png) [@giordano](https://discourse.julialang.org/u/giordano)\
**Post date:** [September 19, 2020, 11:48pm UTC](https://discourse.julialang.org/t/fall-in-github-code-frequency/46941/3 "2020-09-19T23:48:17Z")

</div>

Can you really measure commit frequency by eye in that graph or you got the data and analysed it? Because what I see by eye is that _large_ code refactoring (high spikes in both additions and deletions) became less common after mid-2018, which simply reflects the fact that in August 2018 version 1.0 of Julia was released and after that development of Julia itself became less hectic and refactoring the code got much less likely.

---

<div class="post-metadata">

**Author:** ![Keno](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/keno/32/285_2.png) [@Keno](https://discourse.julialang.org/u/Keno)\
**Post date:** [September 20, 2020, 12:00am UTC](https://discourse.julialang.org/t/fall-in-github-code-frequency/46941/4 "2020-09-20T00:00:11Z")

</div>

Heh, a lot of the big spikes are actually people accidentally committing something and then having that immediately deleted (plus a few actually big changes - e.g. the manual format conversion). A lot of that doesn’t happen anymore.

---

<div class="post-metadata">

**Author:** ![rakesh4real](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/rakesh4real/32/18889_2.png) [@rakesh4real](https://discourse.julialang.org/u/rakesh4real)\
**Post date:** [September 20, 2020, 1:06am UTC](https://discourse.julialang.org/t/fall-in-github-code-frequency/46941/5 "2020-09-20T01:06:33Z")

</div>

Ah, good that I have asked it! I am quite new to open source and I misinterpreted the graph. I thought there might be atleast some correlation between the spikes and the progress made in Julia and I am happy that there isn’t any. Thank you. But I cannot deny the fact that for someone (such as me) who is relatively new to open source, the graph can be misleading

---

<div class="post-metadata">

**Author:** ![Oscar\_Smith](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oscar_smith/32/25343_2.png) [@Oscar\_Smith](https://discourse.julialang.org/u/Oscar_Smith)\
**Post date:** [September 20, 2020, 1:19am UTC](https://discourse.julialang.org/t/fall-in-github-code-frequency/46941/6 "2020-09-20T01:19:35Z")

</div>

The other thing to note is that lines of code is only correlates loosely with development effort. If I do a refactor that moves 1000 lok from 1 file to another, that is way easier and often less impactful than writing 10 lines of new code.

---

<div class="post-metadata">

**Author:** ![anon92994695](https://avatars.discourse-cdn.com/v4/letter/a/ce7236/32.png) [@anon92994695](https://discourse.julialang.org/u/anon92994695)\
**Post date:** [September 20, 2020, 1:21am UTC](https://discourse.julialang.org/t/fall-in-github-code-frequency/46941/7 "2020-09-20T01:21:36Z")

</div>

This is something I’ve thought about to some extent…

I think at some point, when a programming language/project or an ensemble of those begins to reach some level of maturity, the size of the changes and even the frequency of those changes should decrease over time barring complete rewrites (eek). Even with new package creation. I haven’t sat down and worked out any models for it, but maybe it would be something fun to do.

As a surrogate, we do see some decay in the number of OSS contributions over the past few years. That is what should be happening! More complex behavours can be added with 2-3 lines of code(import/dependency/compat/etc). So seeing smaller contributions is not a bad thing, actually it can be a sign things are working as expected.

---

<div class="post-metadata">

**Author:** ![viralbshah](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/viralbshah/32/54_2.png) [@viralbshah](https://discourse.julialang.org/u/viralbshah)\
**Post date:** [September 20, 2020, 1:47am UTC](https://discourse.julialang.org/t/fall-in-github-code-frequency/46941/8 "2020-09-20T01:47:30Z")

</div>

Note that the spikes are huge anomalies. Like major external libraries we used to check into the repo in the very early days that then obviously were refactored out into separate packages. They are large enough C codebases that they make everything else look small in comparison.