Code Handling

Git, a creation of Linus Torvalds, the father of Linux, revolutionized the source control systems space in 2005. Most of the software development has been moved to Git since. Usually organisations host their own Git installation or rely on cloud providers such as GitLab for their repository management. This model did great things to the whole software industry in general and open source in particular over the last 15 years.

For centralized projects, even if they are open source, the centralized Git repository may make sense. Though we would argue that virtually all free software projects in fact require a decentralized organization, decentralised governance model, through the DAO with some form of Meritocratic Token Distribution. We argue that without these components, managed by a foundation or just a group of independent contributors these projects can not be regarded as true Free Software. Today pure Free Software projects must be decentralized, or it just does not make any sense.

Moreover if we are talking about decentralized projects and their code it is simply absurd for them to use a centralized Git repository. It presents risks that nullify all their decentralized governance efforts. Yet almost all blockchain projects are holding their code in a centralized repository today, and therefore can not claim decentralization as one of their properties. The time will come when software repository content will be subject to the same censorship as centralized internet today. Like social networks ban political figures or just simple citizens expressing their contrarian views with fake-morality arguments, the time will come when repository code will be censored for the same reasons.

In this section we particularly are talking about how these and other DAOs should manage their code to avoid centralization and censorship.

Git development today requires a centralized management of repository rights. With decentralized tools repository keys could be dynamically managed by a set of smart contracts.

Governance tokens could be distributed among project stakeholders according to their ever-changing rights. Such tokens on top of repository management abilities will give its holders a stake in the ecosystem such a project aims to create.

Tokens can be minted based on inherited repository performance metrics, such as forks, followers, external and internal commits, reviews, releases and so on. Important decisions regarding the project's future would be taken using decentralized governance tools developed in Everscale.

Once an ecosystem is created and growing, such tokens can then naturally transform into the project's cryptocurrency supporting any monetization model the project chooses to adopt. Helping rewarding long-term contributions to the repository as well as inclusion of new members and investors.

To support such decentralization with immutability of the Git repository, an append-only Git database can be moved to a high performance, low latency Everscale blockchain entirely. In fact, without such a move no project could claim decentralization because of a centralized way its code is managed. Simply speaking, putting Git on Everscale should be viewed as a must-have Everscale objective.

Fortunately there is no problem using Ever OS to build a decentralized Git. The tree structures work very well with Ever OS and blobs of code can be easily stored on DriveChain.