We had another awesome talk from Vicky Steeves. Once again, I left the talk having learned a variety of new tools along with tidbits I would most likely not have come across myself. I also appreciated her direct approach to the topic of code preservation. I was especially struck by how she called out Github’s Arctic Vault program to be a PR stunt, not representative of the grueling work being done by other experts in the field. She also shared with us some of her work in the field of code preservation, namely Reprozip, which is mainly focused on code reproducibility.

As she explained, reproducibility is incredibly important for any area involving computation or software setup. I was able to connect with my own experiences, where I have seen that in bug issues, one of the first questions is how to reproduce the bug. While this is not directly what Vicky was talking about, it also illustrates the wide-ranging need for reproducibility, because it leads to better understanding of the situation, as well as stable and working projects/products. However, what was interesting about her conversation surrounding code preservation were some of the non-typical examples. It was a bit shocking to learn that the word processor George R. R. Martin writes his books on is actually incredibly rare nowadays and the environment is being preserved, as part of a project, by a big-name university.

Her talk was also incredibly resonant with me because I’ve recently had the opportunity to work on some projects that will eventually go live and be used in the real-world. As a result, I’ve come to really appreciate certain tools like virtual environments, that I used to take for granted before. It makes it incredibly easy to set up a project on a new machine when everything is nicely bundled into a directory for you. This has also made me realize that I should sooner rather than later get more familiar with more tools like Docker, as they are industry-standard and frankly seem quite useful.

I’m sure this will be a good habit to develop even when working on the final group projects as we try to set up development environments and potentially recreate bugs in the projects to which we are contributing. Speaking of which, I recently completed an evaluation for Godot and Pytorch3D.

Godot

This was the project I was assigned as part of a class activity. I found the project to actually be very easy to install, considering the scale of it. It also seemed to be incredibly well-documented and filled with a lot of community members. However, I found that, although one may be comfortable with the language (C++), one may need a bit of background in game design to be able to provide code contributions. On the other hand, it doesn’t seem like there would be many glaringly obvious holes in documentation to which one could contribute to. I would consider working on this but I wouldn’t be too keen on it.

Pytorch3D

I was quite excited about this project, as it was introduced to me by a colleague as part of our work together. However, with a little bit of digging I better understood what the project was, which made it less exciting. I was also put off by the fact that all contributors had to complete some sort of paperwork, which I assume allowed Facebook to use the contributions, while the project was open-source, if the project were to be closed-source at some point in the future. Essentially, PyTorch3D is a library that sits on top of PyTorch and allows one to interact with 3D mesh objects and convert them into a format that is compatible with PyTorch. As a result, one may be able to use 3D mesh objects as an input for their neural network. I selected this project for evaluation because it was relatively new (conducive to documentation contributions and good first issues) and also quite active (conducive to communication with the community). However, I soon lost interest after completing the evaluation, especially after I understood the contribution restrictions.

I did end up having a conversation with a classmate about one of his choices, Lemmy, which I think is quite interesting. It aligns with my admiration of decentralized projects, as well as seems like a good opportunity to learn Rust, which may help me contribute to another project (PineTime) I’ve been very excited about (but incapable of contributing to due to lack of knowing Rust).