Tyler Yahn

Looking at the [remove import paths documentation](https://pkg.go.dev/cmd/go#hdr-Remote_import_paths), we need to use some VCS as the protocol to download source code (i.e. commit all the code), or run our own [module...

FWIW, here's an example of another eBPF project checking in their object files: https://github.com/k8spacket/k8spacket/blob/65e5268975cc41a4a1b5daed8a534666a8a4fab5/ebpf/tc/tc_bpfel.o

OBI integration phase 1: https://github.com/open-telemetry/opentelemetry-go-instrumentation/issues/2500

Custom probe API: now tied into the OBI integration. The custom probe API depends on findings from the eBPF program integration first.

Another idea: we could make our releases in release branches. Those branches would contained checked-in `*.o` files. If I understand the GitHub Go releasing model correctly (a big if), we...

We could also post-curate the `generate` steps with a file manipulator that directly defines the object file binary data in the embedded type. This would be equivalent to what protobuf...

@damemi @RonFed: please update the description with any additional proposals or pros/cons you can think of.

> I did not fully understand the advantages relative to just using the object files - is this not the same thing written differently? (i.e will have the same effect...

> With this approach, if a user `go get` our module, the proxy server will provide the `.o` files as if there were in git? > If so, that sounds...

> A common question to most of the propsed soultions is whether we want to support imports of non-official releases (with commit hashes)? I think some of the options rely...