Method, device and equipment for identifying open source project external developers

Abstract

The application relates to an open source project external developer identification method, device and equipment, which focuses on the role evolution of developers in a project cycle, can automatically and efficiently identify when the developers participate as external contributors and when the developers change into internal developers of the project. The technology deeply analyzes the universality of the role conversion of the developers in the open source community, thereby significantly improving the accuracy of identifying the external developers, and is suitable for identifying the external developers of the open source software project in the open source development community. In addition, the technology can effectively deal with the external developer identification challenge brought by a large number of projects and users in the open source development community, and ensures the feasibility and efficiency of the large-scale identification task.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of computers and relates to an open source project external developer identification method, device and equipment. BACKGROUND

[0002] In the field of modern software development, open source software (OSS) projects play an indispensable role. These projects not only promote technological innovation and knowledge sharing, but also establish a platform for global developers to collaborate and jointly drive the advancement of software projects. As these projects gradually expand in size and the developer community continues to grow, how to effectively attract external developers to join and contribute to the project has become an increasingly prominent problem. External developers are individuals or groups who do not belong to the core team of a project but voluntarily contribute to open source projects. They have great potential but have not yet received sufficient recognition in the community, and are crucial to the innovation and continuous progress of open source projects. Therefore, identifying and analyzing the behavior of these external developers and effectively managing and guiding them are of great significance for the long-term development of open source software projects.

[0003] Identifying external developers is an important task in the field of research. Typically, to ensure the security of the code and the effectiveness of project management, there is a permission list in the repository of an open source project that details which users have special permissions in addition to the default permissions, such as the ability to edit or manage documents, code files, etc. in the repository. These users are usually internal personnel recognized by the core team of the project. Therefore, researchers can accurately distinguish between internal personnel and external developers of a project by checking the permission list of the repository. However, due to the protection of user privacy, the permission list of the repository is usually only accessible to internal personnel of the project, and non-project internal personnel do not have the right to access the permission list of the repository.

[0004] How to develop a new external developer identification method that can accurately and efficiently identify external developers in open source software projects while considering the dynamic changes in the role of developers is an important technical problem that field technicians are extremely concerned about. SUMMARY

[0005] In view of the problems in the above-mentioned traditional method, the application proposes an open source project external developer identification method, an open source project external developer identification device and a computer device, which considers the dynamic changes in the role of developers, can efficiently identify external developers and has high operability and flexibility.

[0006] To achieve the above-mentioned purpose, the embodiments of the application adopt the following technical solutions:

[0007] On the one hand, an open source project external developer identification method is provided, comprising the steps of:

[0008] Obtain the developer identification request sent by the user client; the developer identification request includes the name of the target software project and the unique identifier of the target developer;

[0009] Based on the developer identification request, search the backend server database for the latest developer behavior data of the target software project within a specified time period;

[0010] When the latest developer behavior data is not available in the backend server database, search for and download the latest developer behavior data of the target software project from the Internet to the backend server database.

[0011] Mark the target developer behavior event corresponding to the latest developer behavior data as a privileged event, and store the marked latest developer behavior data in the backend server database; the target developer behavior event is a behavior event that requires write permissions to the repository;

[0012] If no next privileged event executed by the target developer can be found in chronological order, the target developer will be marked as an external developer for the period from the creation time of the privileged event to the set duration.

[0013] Return the time period during which the target developer had external developer tags in the target software project to the user.

[0014] In one embodiment, when the next privileged event executed by the target developer is found in chronological order, the open-source project external developer identification method further includes the following steps:

[0015] Mark the target developer as an internal developer for the period from the creation time of the next privileged event until the set duration; the set duration is three months.

[0016] Start by searching in chronological order for the existence of the next privileged event executed by the target developer, and then execute the developer marking process for the next time period.

[0017] In one embodiment, when the backend server database already contains the latest developer behavior data, the open-source project external developer identification method further includes the following steps:

[0018] Filter out the developer behavior data corresponding to the target developer from all developer behavior data of the target software project based on the target developer's unique identifier;

[0019] Based on the developer behavior data corresponding to the target developer, calculate the time period during which the target developer served as an external developer in the target software project and return it to the user.

[0020] On the other hand, a device for identifying external developers of open-source projects is also provided, including:

[0021] The request receiving module is used to obtain the developer identification request sent by the user client; the developer identification request includes the name of the target software project and the unique identifier of the target developer;

[0022] The database lookup module is used to search the backend server database for the latest developer behavior data of the target software project within a set time period based on the developer identification request.

[0023] The project acquisition module is used to search for and download the latest developer behavior data of the target software project from the Internet to the backend server database when the latest developer behavior data is not available in the backend server database.

[0024] The event marking module is used to mark the target developer behavior event corresponding to the latest developer behavior data as a privileged event, and store the marked latest developer behavior data in the backend server database; the target developer behavior event is a behavior event that requires write permissions to the repository;

[0025] The developer tagging module is used to mark the target developer as an external developer for a set duration from the creation time of the privileged event when no next privileged event executed by the target developer can be found in chronological order.

[0026] The identification return module is used to return the time period during which the target developer had external developer tags in the target software project to the user.

[0027] In one embodiment, when the next privileged event executed by the target developer is found in chronological order, the developer marking module is also used to mark the target developer as an internal developer for a period of time from the creation time of the next privileged event to a set duration, and jump to execute the developer marking process in the next time period; the set duration is three months.

[0028] In one embodiment, when the backend server database already contains the latest developer behavior data, the open-source project external developer identification device further includes:

[0029] The data filtering module is used to filter out the developer behavior data corresponding to the target developer from all developer behavior data of the target software project based on the unique identity of the target developer.

[0030] The identification and return module is also used to calculate the time period during which the target developer served as an external developer in the target software project based on the developer behavior data corresponding to the target developer and return it to the user.

[0031] On the other hand, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the above-mentioned open-source project external developer identification method.

[0032] One of the above technical solutions has the following advantages and beneficial effects:

[0033] The aforementioned method, apparatus, and device for identifying external developers of open-source projects first search the backend server database for the latest developer behavior data of the target software project within a set time period based on the developer identification request sent by the user. If no latest developer behavior data is found, the latest developer behavior data of the target software project is searched for and downloaded from the Internet to the backend server database. The behavior event corresponding to the latest developer behavior data that requires write permissions to the repository is marked as a privileged event and stored in the backend server database. Then, if the next privileged event executed by the target developer cannot be found in chronological order, the target developer is marked as an external developer for the time period from the creation time of the privileged event to the set duration. Finally, the time period during which the target developer has the external developer mark in the target software project is returned to the user, thus completing the current request for external developer identification processing of the open-source project.

[0034] Compared to traditional identification technologies, this technology focuses on the evolution of a developer's role throughout the project lifecycle, automatically and efficiently identifying when a developer participates as an external contributor and when they transition into an internal developer role. This technology deeply analyzes the prevalence of developer role transitions within open-source communities, significantly improving the accuracy of identifying external developers. It is suitable for identifying external developers in open-source software projects within open-source development communities. Furthermore, it effectively addresses the challenges of identifying external developers from the large number of projects and users in open-source development communities, ensuring the feasibility and efficiency of large-scale identification tasks. Attached Figure Description

[0035] To more clearly illustrate the technical solutions in the embodiments of this application or the conventional technology, the drawings used in the description of the embodiments or the conventional technology will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0036] Figure 1 This is a flowchart illustrating a method for identifying external developers of open-source projects in one embodiment.

[0037] Figure 2 This is a flowchart illustrating the method for identifying external developers of open-source projects in another embodiment;

[0038] Figure 3 This is a schematic diagram illustrating the application process of an open-source project external developer identification method in one embodiment.

[0039] Figure 4 This is a schematic diagram of the module structure of an external developer identification device for an open-source project in one embodiment. Detailed Implementation

[0040] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application. Unless otherwise defined, all technical and scientific terms used in this application have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application.

[0041] It should be noted that the reference to "embodiment" in this application means that a specific feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. Those skilled in the art will understand that the embodiments described in this application can be combined with other embodiments. The term "and / or" as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0042] Identifying external developers is a crucial aspect of domain research. Typically, to ensure code security and effective project management, open-source project repositories maintain a permission list detailing which users possess special permissions beyond the default ones. These permissions might include the ability to edit or manage documents and code files within the repository. These users are usually internal personnel approved by the project's core team. Therefore, researchers can accurately distinguish between internal staff and external developers by examining the repository's permission list. However, to protect user privacy, the repository's permission list is usually only accessible to internal project members; non-internal staff do not have access to it.

[0043] Alternatively, external developers can be identified through the intuitive judgment and personal networks of community members. However, this method is not only inefficient but also easily influenced by subjective preferences and internal community dynamics. For example, a potentially talented developer might be overlooked due to a lack of direct contact with the core team or low visibility within the community. As the number of members in the open-source community increases, the feasibility and accuracy of manually identifying and evaluating external developers decrease significantly.

[0044] Furthermore, existing methods for identifying developer roles are typically static and do not consider the dynamic changes in developer roles within the open-source community. Developer role migration is a common phenomenon in the open-source ecosystem. New members can usually gain recognition and acceptance from the core project team through contributions and community interaction, becoming internal staff. Simultaneously, role transitions are bidirectional; internal staff may leave the core team for personal or professional reasons, returning to the role of an external developer. This developer mobility places higher demands on methods for identifying external developers.

[0045] Therefore, how to develop a new method for identifying external developers that can accurately and efficiently identify external developers in open-source software projects, while taking into account the dynamic changes in developer roles, is an important technical issue of great concern to those skilled in the art.

[0046] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0047] In one embodiment, such as Figure 1 As shown, a method for identifying external developers of open-source projects is provided, which may include the following processing steps S12 to S22:

[0048] S12, Obtain the developer identification request sent by the user client; the developer identification request includes the name of the target software project and the unique identifier (ID) of the target developer; it can be understood that after receiving the developer identification request sent by the user client (which may contain the name of the target software project and the ID of the target developer), the server can, based on the name of the target software project, first query the backend server database to see if the latest user behavior data of the target software project already exists, thereby determining the storage status of the complete user behavior data of the target software project that the current user needs to monitor in the backend server database. The target developer is the developer that the current user client needs to identify in the target software project.

[0049] S14. Based on the developer identification request, search the backend server database for the latest developer behavior data of the target software project within a set time period. It can be understood that the server searches its maintained backend server database to determine whether there is updated data for the target software project within a set time period (which can be denoted as N hours). This data may include all developer behavior data of the project up to the current time. The integer N can be set by the user or the relevant system administrator according to the actual identification needs. For example, N=24 means that the data expiration time limit is 1 day, N=48 means that the data expiration time limit is 2 days, and so on.

[0050] S16, When there is no latest developer behavior data in the backend server database, search for and download the latest developer behavior data of the target software project from the Internet to the backend server database; it can be understood that when the server fails to find the latest developer behavior data of the target software project in the backend server database, it is determined that the backend server database does not yet have complete data of the target software project. Therefore, the server can directly search for the data of the target software project from the Internet and download the latest developer behavior data of the target software project from the found open source platform to the backend server database and store it in the backend server database for later use.

[0051] S18: Mark the target developer behavior event corresponding to the latest developer behavior data as a privileged event, and store the marked latest developer behavior data in the backend server database; the target developer behavior event is a behavior event that requires write permissions to the repository; it can be understood that the server can determine whether the target developer behavior event requires write permissions to the repository based on the existing event type descriptions of the open source platform. If so, it marks it as a privileged event. The marked latest developer behavior data is then stored in the backend server database for later use.

[0052] S20: When no next privileged event executed by the target developer can be found in chronological order, the target developer is marked as an external developer for the period from the creation time of the privileged event to the set duration. This can be understood as follows: after obtaining a privileged event executed by the target developer, the server can check the next privileged event executed by the target developer in chronological order. If the next privileged event does not exist, it means that the target developer exists as a non-internal developer for the period from the creation time corresponding to the currently executed privileged event to the set duration. Therefore, the target developer is marked as an external developer during this period. The set duration can be set by the user or relevant system administrator according to the actual identification needs, such as, but not limited to, one month, three months, or half a year.

[0053] S22 returns the time period during which the target developer had external developer tags in the target software project to the user.

[0054] It is understandable that after obtaining the time period during which the target developer acted as an external developer in the target software project, the server can either return that time period to the user in real time, or return all the time periods during which the target developer acted as an external developer in the target software project to the user all at once after completing the identification of all time periods and obtaining the identification results.

[0055] The aforementioned method for identifying external developers of open-source projects first searches the backend server database for the latest developer behavior data of the target software project within a set time period based on the developer identification request sent by the user. If no latest developer behavior data is found, the latest developer behavior data of the target software project is searched for and downloaded from the Internet to the backend server database. The behavior event that requires write permissions to the repository corresponding to the latest developer behavior data is marked as a privileged event and stored in the backend server database. Then, if the next privileged event executed by the target developer cannot be found in chronological order, the target developer is marked as an external developer for the time period from the creation time of the privileged event to the set duration. Finally, the time period during which the target developer has the external developer mark in the target software project is returned to the user, thus completing the current request for external developer identification processing of the open-source project.

[0056] Compared to traditional identification technologies, this technology focuses on the evolution of a developer's role throughout the project lifecycle, automatically and efficiently identifying when a developer participates as an external contributor and when they transition into an internal developer role. This technology deeply analyzes the prevalence of developer role transitions within open-source communities, significantly improving the accuracy of identifying external developers. It is suitable for identifying external developers in open-source software projects within open-source development communities. Furthermore, it effectively addresses the challenges of identifying external developers from the large number of projects and users in open-source development communities, ensuring the feasibility and efficiency of large-scale identification tasks.

[0057] In one embodiment, such as Figure 2 As shown, when the backend server database already contains the latest developer behavior data, the open-source project external developer identification method may further include the following steps S15 to S17:

[0058] S15, filter out the developer behavior data corresponding to the target developer from all developer behavior data of the target software project based on the unique identity of the target developer;

[0059] S17. Based on the developer behavior data corresponding to the target developer, calculate the time period during which the target developer served as an external developer in the target software project and return it to the user.

[0060] This is understandable. Since the server has already found the complete data of the target software project in the backend server database, it can use this data to directly calculate the time period during which the target developer acted as an external developer in the target software project and return it to the user. The automated identification process of the target developer's identity in the target software project is complete; there is no need to search for data online, making the calculation and processing more efficient and consuming fewer computing resources.

[0061] Specifically, the client sends a request to the server to obtain the time period during which the target developer acted as an external developer in the target software project. The server then retrieves all existing developer behavior data related to the target software project from its backend database. It then identifies the developer behavior data belonging to the target developer's ID and calculates (the calculation process is similar to steps S18 to S20 above) the time period during which the target developer acted as an external developer in the target software project, returning this result to the client. This automated identification of developers in the open-source development community simplifies the tedious and repetitive data acquisition process, fully utilizes existing local results, greatly reduces the workload of staff, offers good flexibility, and can handle the identification of external developers from massive projects and users.

[0062] In some implementations, the server can also periodically check all existing local open-source software projects and update the corresponding resource repositories. This means the server can periodically check existing local open-source software projects, examine the local developer behavior data storage for each project, and automatically (or trigger according to a set update interval) update the corresponding local data (resource) repository. It can also calculate and store the time periods during which each developer in each open-source software project acts as an external developer, so that when other users initiate identification requests, the server can immediately return the required time periods of external developers, thereby further improving identification efficiency. Furthermore, by selecting to perform checks and updates during server idle time, the allocation and use of server computing resources can be optimized.

[0063] In one embodiment, such as Figure 3 As shown, when the next privileged event executed by the target developer is found in chronological order, the method for identifying external developers of open-source projects may also include the following steps:

[0064] Mark the target developer as an internal developer for the period from the creation time of the next privileged event until the set duration; the set duration is three months.

[0065] Start by searching in chronological order for the existence of the next privileged event executed by the target developer, and then execute the developer marking process for the next time period.

[0066] Understandably, the server can check the next privileged event executed by the target developer in chronological order. If it does not exist, the process jumps to step S20; otherwise, the server marks the target developer as an internal developer for three months starting from the creation time of the next privileged event. The above steps of finding the next privileged event executed by the target developer in chronological order and marking its time period are repeated until all time periods are marked. This allows the server to obtain the time periods during which the target developer was an external developer and the time periods during which the target developer was an internal developer in the target software project, thus achieving more complete identification and processing.

[0067] It should be understood that, although the above process Figures 1 to 3 The steps in the process are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated in this application, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Furthermore, the above process... Figures 1 to 3 At least some of the steps may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily executed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

[0068] In one embodiment, such as Figure 4As shown, an external developer identification device 100 for the aforementioned open-source project is also provided, including a request receiving module 11, a database lookup module 13, a project acquisition module 15, an event marking module 17, a developer marking module 19, and an identification return module 21. The request receiving module 11 is used to receive a developer identification request sent by a user terminal; the developer identification request includes the name of the target software project and the unique identifier of the target developer. The database lookup module 13 is used to search for the latest developer behavior data of the target software project within a set time period in the backend server database according to the developer identification request. The project acquisition module 15 is used to search for and download the latest developer behavior data of the target software project from the Internet to the backend server database when there is no latest developer behavior data in the backend server database. The event marking module 17 is used to mark the target developer behavior event corresponding to the latest developer behavior data as a privileged event, and store the marked latest developer behavior data in the backend server database; the target developer behavior event is a behavior event that requires write permissions to the repository. The developer marking module 19 is used to mark the target developer as an external developer for a set duration from the creation time of the privileged event to the time period when no next privileged event executed by the target developer can be found in chronological order. The identification return module 21 is used to return the time period during which the target developer has the mark of an external developer in the target software project to the user.

[0069] The aforementioned open-source project external developer identification device 100 first searches the backend server database for the latest developer behavior data of the target software project within a set time period based on the developer identification request sent by the user. If no latest developer behavior data is found, it searches for and downloads the latest developer behavior data of the target software project from the Internet to the backend server database. The behavior event corresponding to the latest developer behavior data that requires write permissions to the repository is marked as a privileged event and stored in the backend server database. Then, if the next privileged event executed by the target developer cannot be found in chronological order, the target developer is marked as an external developer for the time period from the creation time of the privileged event to the set duration. Finally, the time period during which the target developer has the external developer mark in the target software project is returned to the user, thus completing the open-source project external developer identification processing for the current request.

[0070] Compared to traditional identification technologies, this technology focuses on the evolution of a developer's role throughout the project lifecycle, automatically and efficiently identifying when a developer participates as an external contributor and when they transition into an internal developer role. This technology deeply analyzes the prevalence of developer role transitions within open-source communities, significantly improving the accuracy of identifying external developers. It is suitable for identifying external developers in open-source software projects within open-source development communities. Furthermore, it effectively addresses the challenges of identifying external developers from the large number of projects and users in open-source development communities, ensuring the feasibility and efficiency of large-scale identification tasks.

[0071] In one embodiment, when the next privileged event executed by the target developer is found in chronological order, the developer marking module 19 can also be used to mark the target developer as an internal developer for a period of time from the creation time of the next privileged event to a set duration, and jump to execute the developer marking process in the next time period; the set duration is three months.

[0072] In one embodiment, when the backend server database already contains the latest developer behavior data, the open-source project external developer identification device 100 may further include a data filtering module, used to filter out the developer behavior data corresponding to the target developer from all developer behavior data of the target software project based on the unique identifier of the target developer. The identification return module 21 may also be used to calculate the time period during which the target developer served as an external developer in the target software project based on the developer behavior data corresponding to the target developer and return it to the user terminal.

[0073] It is understood that the explanations of the features in the various embodiments of the open-source project external developer identification device 100 can be understood by referring to the explanations of the corresponding features in the various embodiments of the open-source project external developer identification method above, and will not be repeated here. Each module in the open-source project external developer identification device 100 can be implemented entirely or partially through software, hardware, or a combination thereof. Each module can be embedded in hardware or independently of a device with data processing capabilities, or stored in software in the memory of the aforementioned device, so that the processor can call and execute the operations corresponding to each module. The aforementioned device can be, but is not limited to, various types of data computing and processing devices already existing in the art.

[0074] In one embodiment, a computer device is also provided, including a memory and a processor. The memory stores a computer program, and the processor executes the computer program to perform the following processing steps: obtaining a developer identification request sent by a user client; the developer identification request includes the name of the target software project and a unique identifier of the target developer; searching for the latest developer behavior data of the target software project within a set time period in the backend server database according to the developer identification request; when there is no latest developer behavior data in the backend server database, searching for and downloading the latest developer behavior data of the target software project from the Internet to the backend server database; marking the target developer behavior event corresponding to the latest developer behavior data as a privileged event, and storing the marked latest developer behavior data in the backend server database; the target developer behavior event is a behavior event that requires write permissions to the repository; when no next privileged event executed by the target developer can be found in chronological order, marking the target developer as an external developer for a set duration from the creation time of the privileged event; and returning the time period during which the target developer has the external developer mark in the target software project to the user client.

[0075] It is understood that, in addition to the memory and processor mentioned above, the computer equipment may also include other hardware and software components not listed in this specification. The specific components may be determined according to the model of the specific data processing equipment in different application scenarios, and will not be listed and described in detail in this specification.

[0076] In one embodiment, when the processor executes the computer program, it may also implement the steps or sub-steps added to the various embodiments of the above-described method for identifying external developers of open-source projects.

[0077] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), memory bus DRAM (RDRAM), and interface DRAM (DRDRAM), etc.

[0078] The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification. The above embodiments only illustrate several implementation methods of this application, and their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of the invention patent. It should be noted that for those skilled in the art, several modifications and improvements can be made without departing from the concept of this application, and all of these fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. An open source project external developer identification method, characterized by, The method comprises the steps of: acquiring a developer identification request sent by a user end; the developer identification request comprises a name of a target software project and a unique identity of a target developer, and the target developer is a developer currently needed to be identified by the user end in the target software project; finding, according to the developer identification request, latest developer behavior data within a set time period of the target software project in a background server database; when there is no latest developer behavior data in the background server database, searching and downloading the latest developer behavior data of the target software project from the Internet to the background server database; marking a target developer behavior event corresponding to the latest developer behavior data as a privileged event, and storing the latest developer behavior data after being marked in the background server database; the target developer behavior event is a behavior event needing a write permission of a repository; when a next privileged event performed by the target developer cannot be found in a time sequence, marking the target developer as an external developer within a time period from a creation time of the privileged event to a set time length; the set time length comprises one month, three months or half a year; returning the time period in which the target developer has the mark of an external developer in the target software project to the user end.

2. The open source project external developer identification method of claim 1, wherein, when a next privileged event performed by the target developer is found in a time sequence, the method further comprises the steps of: marking the target developer as an internal developer within a time period from a creation time of the next privileged event to a set time length; and the set time length is three months; starting to find, in a time sequence, whether a next next privileged event performed by the target developer exists, and performing a next next time period developer marking process.

3. The open source project external developer identification method according to claim 1 or 2, characterized by, when there is the latest developer behavior data in the background server database, the method further comprises the steps of: filtering, according to the unique identity of the target developer, developer behavior data corresponding to the target developer from all developer behavior data of the target software project; calculating a time period in which the target developer is an external developer in the target software project according to the developer behavior data corresponding to the target developer, and returning the time period to the user end.

4. An open source project external developer identification apparatus characterized by comprising: The method comprises the steps of: a request receiving module, configured to acquire a developer identification request sent by a user end; the developer identification request comprises a name of a target software project and a unique identity of a target developer, and the target developer is a developer currently needed to be identified by the user end in the target software project; a database finding module, configured to find, according to the developer identification request, latest developer behavior data within a set time period of the target software project in a background server database; a project acquiring module, configured to, when there is no latest developer behavior data in the background server database, search and download the latest developer behavior data of the target software project from the Internet to the background server database; a marking module, configured to mark a target developer behavior event corresponding to the latest developer behavior data as a privileged event, and store the latest developer behavior data after being marked in the background server database; an event marking module, configured to mark a target developer behavior event corresponding to the latest developer behavior data as a privileged event, and store the marked latest developer behavior data in a background server database; the target developer behavior event is a behavior event requiring write permission of a repository; a developer marking module, configured to mark the target developer as an external developer within a time period from a creation time of the privileged event to a set time length when a next privileged event performed by the target developer cannot be found in chronological order; the set time length comprises one month, three months or half a year; an identification returning module, configured to return a time period during which the target developer is marked as an external developer in the target software project to the user terminal.

5. The open source project external developer identification apparatus of claim 4, wherein, when the next privileged event performed by the target developer can be found in chronological order, the developer marking module is further configured to mark the target developer as an internal developer within a time period from a creation time of the next privileged event to a set time length, and jump to perform a developer marking process of a next time period; the set time length is three months.

6. The open source project external developer identification apparatus according to claim 4 or 5, characterized by, when the latest developer behavior data already exists in the background server database, the open source project external developer identification apparatus further comprises: a data filtering module, configured to filter out developer behavior data corresponding to the target developer from all developer behavior data of the target software project according to a unique identity of the target developer; the identification returning module is further configured to calculate a time period during which the target developer is an external developer in the target software project according to the developer behavior data corresponding to the target developer, and return the time period to the user terminal. 7.A computer device, comprising a memory and a processor, wherein the memory stores a computer program, and the computer device is configured to perform the method according to any one of claims 1-6 when the computer program is executed by the processor. the processor implements the steps of the open source project external developer identification method in any one of claims 1 to 3 when executing the computer program.

Images