I would hardly say this structure looks "perfect". For a start: - Use of Docker is a serious problem. I have no intention of ever running Docker on my machine

I would hardly say this structure looks "perfect". For a start: - Use of Docker is a serious problem. I have no intention of ever running Docker on my machine to build some random project for which I have the toolchain already installed. Wrapping Docker with a Makefile is even more irritating. - Use of "package pkg" to keep the version number in is bizarre - I've never seen that before. Some use `package version` _inside_ a `pkg` directory which contains other public packages also, and use of `package version` at the top level is also fairly common. - Multiple modules in one git repository presents many challenges for people who want to reference them at different commits in other projects. - `pkg app` under a `cmd` directory is sometimes fine, but if there is only one app and no library, keeping it in the root should be preferred so that `go get` works properly. Furthermore, other packages being nested under it is not often great, since they are highly likely to be reused by other `cmd`s in the same repository. Personally for Go I've never needed a "starter" project, since not much needs configuring out the box as the toolchain is quite reasonable. If I were evaluating a project structured like this as a potential dependency, I'd knock off major marks for the structure and investigate alternatives. I guess if things came down to the wire, the structure wouldn't be a deal breaker, but I'd certainly aim to avoid it.