GitLab plans to implement changes to the service usage rules in September, according to which projects hosted on GitLab.com for free will be automatically deleted if their repositories remain inactive for 12 months. The changes have not been officially announced yet and are in the stage of internal planning.
The change aims to reduce hosting costs by freeing up resources for storing and processing abandoned projects and inactive forks. It is estimated that maintaining infrastructure for abandoned projects accounts for up to a quarter of all operational expenses. hosting GitLab.com and the automatic cleaning of such projects could save up to a million dollars a year.
Before the actual deletion, owners of repositories eligible for removal will receive notifications several weeks or months in advance, warning them to confirm the project's relevance. Only abandoned projects will be deleted, where authors do not respond to warnings, no changes have been made in the repository for a year, no new issues have been published, and no comments have been submitted.
However, some community members consider the proposed deletion a flawed practice, as code from inactive repositories may be used as dependencies in other projects that remain active. It is also noted that constant changes are not the goal for some authors, who may feel that the current state of their project has reached an optimal level, and the code is good enough and doesn't need improvement, or originally release completed works that are not planned for further development but may still be useful to others.
Additionally, external resources may link to the code of inactive projects, and its removal will lead to the loss of the confirmed reference copy that can be cited (unofficial copies do not guarantee the absence of malicious activity). Therefore, instead of deleting, a more optimal solution would likely be to move it to an archived state while retaining access to the code in read-only mode. To save disk space when storing unwanted forks, more efficient methods for processing duplicates can be utilized. For example, GitHub prevents data duplication by keeping all objects from the main repository and its related forks together, logically separating the ownership of commits.
Source: opennet.ru
