Provide updates through project repositories
Another important place to post information about project changes is the project’s repository itself on GitHub or related destinations. There you can place detailed notes explaining what’s happening, including readme files to help get the messages to participants.
As the project moves on, it’s time to officially transfer the assets, if necessary, to its new operators. If you are bringing in new administrators while maintaining the actual assets within your existing company, you can keep the copyrights on the affected code and let them use it with the open source licenses of their choice.
To keep the project repositories well organized, you might consider setting up a designated area where you can store and make available all transitioned open source projects that your company no longer supports (e.g., https://github.com/twitter-archive). In this way, the projects are still available for users to get code, and potential users can also still find readme files explaining the status of the projects. This designated section of the repository can provide clarity for users and help them understand the difference between active and retired projects, while also ensuring that enterprises can properly showcase their latest live open source projects in their active repositories.
Several steps are involved in archiving a project. For example, moving it to a read-only status helps make it clear, without having to change any URLs, that the project is now archived and no longer open to regular updates in its previous form.
Also important is to provide users with a clear alternative plan for their projects, including how to get and fork the code for their ongoing uses. As part of that responsibility, you should provide users with a way to contact you so they can have their fork listed and made available to other interested users. Some companies provide this assistance, while other choose not to do so.
Once a repository is archived, you cannot add or remove collaborators or teams, and issues become read-only. To make changes in an archived repository, you must unarchive the repository first. See the GitHub documentation for more details: https://help.github.com/articles/about-archiving-repositories/
Infrastructure updates when shuttering projects
Ending a project can also affect your project’s infrastructure and support, which must be judged on a case-by-case basis, depending on how your project was set up. Some projects use and maintain only a small set of code, so there might not be much to do. If it is all code and it’s posted on your repository, then you’re probably done and need not take additional steps to transfer or secure it.
Other projects, however, may require significant effort to shutter them using various backend tools to do the work. These may include services that may have been shared for many purposes, such as a test infrastructure. Although that test infrastructure has been used for the project previously, you may want to remove it before transferring the code so you can use the tool to test other work later. It may be hard to disentangle, but it can be done if desired.