@user176372 is correct in their answer that it's useful to ensure early on the lifetime of a project that you will be hosting websites, project repositories, Q&A forums, email lists, etc., on domains that you control. This is practical, because it ensures that you can move to another university, give the project to someone else (say, if you retire), or simply because universities change their minds what open ports they want to provide on their machines to host services -- generally, this has become much more difficult than it was twenty years ago when every employee could basically run whatever web service they wanted on their desktop.
There are also legal questions. At least in the US, the intellectual property (copyright) of work that employees produce -- including software -- rests with the employer. That means that, strictly speaking, when you move to another university, the rights to everything that has been developed up to that point remains with your old university. That pertains to the software itself, the documentation, the trademark (if any), etc. In this regard, you're really no different than any employee of a company: If you've worked on something for Google and you move to Microsoft, you can't just take all of the source code you wrote along and expect that to be ok. I will note that that is no different if the software was written for contracts funded by NIH, NSF, or other federal agencies: The Bayh-Dole Act says that even though the Federal government paid for it, the university owns the intellectual property.
Now, in practice, university generally don't have much interest in small software projects -- say, things for which the market potential is less than a few million dollars over the course of a few years. That's because to bring something to market costs money: marketing costs, writing user interfaces, supporting users, etc. As a consequence, most of the time universities will not care much one way or the other what you do with academic software, but that is not something you should rely on. Instead, have a conversation with the IP office of the university, explain the scope and size of the project to them, and see if they're willing to agree that the project can be distributed as open source (which, strictly speaking, you cannot do unilaterally without your university's approval). My experience having this kind of conversation is that it is typically not all that difficult to get an IP officer to send you an email saying "yes, we're ok with you distributing this as open source". In my case, this included explaining to them that I will likely bring in more money through external grants than we could by making things into a commercial product. This is useful because it essentially gives you a perpetual right to keep distributing the software as open source, whether or not you stay at that university.
Then, when you go to a new university, have that conversation with them before you sign the contract. Here, too, my experience is that it is not all that difficult to get them to agree up front that open source is ok with them.
The point I'm trying to make is that it is far preferable to have an email from someone in a position to make a legally binding determination over just "hoping for the best and otherwise feigning ignorance". In the end, this is a legal question. You should inform yourself of at least the basic tenets of who owns intellectual property, the relationship between intellectual property and software licenses, and adjacent questions.
