A GitHub URL at least is still an credible identifier, your custom domains is not, and likely will never be given how the system is accustomed to. Domain is for branding, not identification.
Unless of course, it's special domains that has identification built in, such as .onion which is generated in such way (cryptographic keys) no other people can easily obtain control even after the domain is no longer maintained.
If you really don't want to use GitHub, an alternative is just use .internal suffix (i.e. yourproject.internal/project) in combination with `replace` directives in go.mod. But that require your user to manually download/install your package and then edit their own go.mod.
> A GitHub URL at least is still an credible identifier, your custom domains is not, and likely will never be given how the system is accustomed to. Domain is for branding, not identification.
The post is about commercial software. If enterprise’s domain is not credible enough, then there are bigger problems.
I'm guessing by commercial software, you mean GitHub etc.
Well, I too dislikes their enterprise tune, "Changing is consistent, GitHub give you advantage (over other companies)" blahblahblah. Many developers I know are on GitHub because it was/is the place for individual developers to share code, not because the "company advantages".
HOWEVER, I can't ignore the fact that individual developers just can't pay enough to keep the machine running, so it's reasonable for GitHub to pivot towards commercial market. On the other side, GitHub is still benevolent enough to provide some enterprise-class service back to freetier users. This arrangement checks out for me so far.
I do self-host some of my projects too with Gitea. But I never dare to use my domain in my Go packages, due to long-term security concerns.
When I initialize my projects, I just use .internal domain, then if I decided to upload the project to GitHub, I'll change the URL to GitHub to make it more convenient to the users. Otherwise, manual download and `replace` directive like I suggested.
nirui · · focus · HN ↗
Unless of course, it's special domains that has identification built in, such as .onion which is generated in such way (cryptographic keys) no other people can easily obtain control even after the domain is no longer maintained.
If you really don't want to use GitHub, an alternative is just use .internal suffix (i.e. yourproject.internal/project) in combination with `replace` directives in go.mod. But that require your user to manually download/install your package and then edit their own go.mod.
nicce · · focus · HN ↗
The post is about commercial software. If enterprise’s domain is not credible enough, then there are bigger problems.
nirui · · focus · HN ↗
Well, I too dislikes their enterprise tune, "Changing is consistent, GitHub give you advantage (over other companies)" blahblahblah. Many developers I know are on GitHub because it was/is the place for individual developers to share code, not because the "company advantages".
HOWEVER, I can't ignore the fact that individual developers just can't pay enough to keep the machine running, so it's reasonable for GitHub to pivot towards commercial market. On the other side, GitHub is still benevolent enough to provide some enterprise-class service back to freetier users. This arrangement checks out for me so far.
I do self-host some of my projects too with Gitea. But I never dare to use my domain in my Go packages, due to long-term security concerns.
When I initialize my projects, I just use .internal domain, then if I decided to upload the project to GitHub, I'll change the URL to GitHub to make it more convenient to the users. Otherwise, manual download and `replace` directive like I suggested.