The Problem of Sharing Code

May 15, 2022

Many of the DevOps themes I write about (monorepos, package managers, WebAssembly, Docker, etc.) have something to do with sharing code.

Programs today are often a Frankenstein combination of different open-source libraries. I've spent a lot of time thinking about how to manage all of the dependencies (see Reflections on 10,000 Hours of Programming). How code gets used and reused should be important for developer productivity optimizers.

Some layers I think about when thinking about sharing code.

  • Discovery ("what code exists?"). GitHub does a fairly reasonable job. Sourcegraph can also be invaluable. I've also written about Code Transparency as an organizational solution to this.
  • Vendoring. Is the source code pulled in manually? Is it managed by a language-specific package manager (yarn, go modules, etc.)? Is copied over pre-compiled?
  • Import. How does code import other code? Module systems are often built into the language, but each works very differently (e.g., python imports vs. go imports). Not to mention cross-language code-sharing (e.g., C in Go, Go in JavaScript via WASM).
  • Linking (dynamic or static?). Does the final artifact contain all runtime dependencies? Or are there dynamic or shared libraries that must be present for the program to run (batteries not included)? Linking can have implications for software licensing.
Subscribe for daily posts on startups & engineering.