I think making the code available is good, but I think we should be careful how we use the term "reproducibility". Pulling your repo and running it had better give the same results, but it's not the same sort of thing as building my own experimental setup according to a paper's specification. The latter gives more room for variability such that successful replication speaks more strongly to the robustness of the result, and also puts human brain power next to each step of the process in a way where weirdness might be noticed.
Replication should probably involve reimplementation, if it's to carry its traditional weight. In the event that we fail to replicate, though, having the source code for both versions is likely to be hugely informative.
I think think extension also carries similar value. It is less grunt work to do, but still requires a deep understanding of the existing code. "Weirdness" should quickly become apparent.
Many times, I've read a paper, thought something was great, and then implemented the paper and failed to reproduce the author's results. In the cases where I've been able to compare my implementation to a reference on github, I often find the paper doesn't match the code, or a subtle data processing step was left out. Having a replica (a commit hash and a pointed to versioned input data) can often make a huge difference in time.
The bulk of the work to get real-time working is to move more of pipeline to GPU. Mostly things handled by numpy and some image/video transformations.
I've noticed that GPU does help a lot with inference. It would be nice if it were easier to make projects like these mobile.
Google and Apple have SDKs for running nets on phones, but its a shame its so hard to do things like this on the Raspberry pi...