## 2 Preliminaries and Related Work
### Related Work  
#### 2.2.1 Traditional Methodology  
Many researchers have put forward traditional solutions to address OS issues of code control, incentive, interaction and collaboration, automation, transparency and fairness of rights and responsibilities. Although these solutions do not utilize blockchain to achieve decentralization, it is still important to analyze their achievements and shortcomings. The technologies involved in code control exhibit diversity. The rapid development of OS has made code referencing complex, and common traceability technologies can be divided into three directions: benchmark databases, signatures and machine learning. By studying the largest corpus of publicly available source code, the Software Heritage archive, [PERSON] et al. [4] benchmarked different data models for capturing  
Figure 2: Oracle connects the blockchain with the real external environment. software provenance information. However, the pressure on the centralized operation and maintenance of such a massive amount of data is enormous. Based on the code database, [PERSON] et al. [27] studied the identification of modified OSS reuse and adopted a signature-based clone detection method. However, they did not discuss reliable traceability. Machine-learning-based code traceability has better generalization and transfer capabilities. [PERSON] et al. [28] presented the spojitR toolset and workflow, which can assist developers in creating trace links between the commits of version control systems and issues. Yet, spojitR can only establish project-wide traceability, and sufficient data are needed for machine learning. According to the study on incentive factors [29; 30; 31], community experience (policy, innovation and communication) and harvest (knowledge, reputation and donation income) are significant. In OS ecosystems, there are many behaviors that damage the incentive mechanism [27], involving infringement, unfair competition and using loopholes to damage the value system. Good experience and reliable harvest come from the consensus of most participants, which also requires research on the credibility of the processes and results. [PERSON] et al. [32] explored OSS management from problems' feedback, but the perspective was single and did not consider the historical tracing of problems and related modifications. The authors of [33] studied the collaboration and communication of OS developers from a higher-level perspective, which can improve efficiency, but did not consider trust. [PERSON] et al. [34] summarized the common structure and evolutionary characteristics of OS community developer collaboration models and provided relevant management suggestions based on sociology. However, there was insufficient consideration for the joining and exiting of personnel. There are many automation tools in the field of software engineering, such as DevOps, which reshape software processes through automation [35]. Automation problems in OS are often related to development, testing and delivery. Some scenarios unrelated to software engineering in OS governance can also be automated, such as payment automation. In [36], automation was considered a good strategy to govern OS. Although lots of OS or commercial toolsets are available to drive automation, transparency and trustworthiness are always ignored. In [37; 38], some existing organizational forms of OSS community governance were discussed. There are two main leadership modes: top-down, such as sponsor-based Redis Labs and tolerant dictatorship-based Linux in the past; and bottom-up, such as business alliance-based GENIVI Alliance and Eclipse Foundation-based PolarSys. Many OS communities at different stages actually have mixed modes. However, in these so-called democratic governance modes, the decision-making process lacks transparency and fairness, and the participation of ordinary members is very low. This is limited by the inability to fully achieve decentralization.