Open source project external developer identification method, device and equipment

Abstract

The invention relates to an open source project external developer identification method, device and equipment, and the technology focuses on the role evolution of a developer in a project period, and can automatically and efficiently identify when the developer participates in the identity of an external contributor and when the developer is converted into a project internal developer. The technology deeply analyzes the universality of role conversion of developers in the open source community, so that the accuracy of identifying the external developers is remarkably improved, and the technology is suitable for identifying the external developers of the open source software project in the open source development community. In addition, external developer identification challenges brought by a large number of projects and users in an open source development community can be effectively handled, and the feasibility and efficiency of large-scale identification tasks are ensured.

Description

Technical Field

[0001] The present invention belongs to the field of computer technology and relates to a method, device and equipment for identifying external developers of an open source project. Background Art

[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 promote the advancement of software projects. As the scale of these projects gradually expands and the developer community continues to grow, how to effectively attract external developers to join and continue to contribute to the project has become an increasingly prominent issue. External developers are individuals or groups who do not belong to the core team of the project but voluntarily contribute to the open source project. They have great potential but have not yet received sufficient recognition in the community. They 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 profound significance to the long-term development of open source software projects.

[0003] Identifying external developers is an important task in field research. Usually, in order to ensure the security of the code and the effectiveness of project management, there will be a permission list in the repository of the open source project to record in detail which users have special permissions in addition to the default permissions, such as being able to edit or manage documents and code files 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, in order to protect user privacy, the permission list of the repository is usually only open to internal personnel of the project, and non-internal personnel of the project do not have the permission to obtain 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 taking into account the dynamic changes in developer roles is an important technical issue that technicians in this field are extremely concerned about. Summary of the invention

[0005] In response to the problems existing in the above-mentioned traditional methods, the present invention proposes a method for identifying external developers of open source projects, an apparatus for identifying external developers of open source projects, and a computer device, which take into account the dynamic changes of developer roles, can efficiently identify external developers and have high operability and flexibility.

[0006] In order to achieve the above objectives, the embodiments of the present invention adopt the following technical solutions:

[0007] On the one hand, a method for identifying external developers of an open source project is provided, comprising the steps of:

[0008] Obtaining a developer identification request sent by the user; the developer identification request includes the name of the target software project and the unique identity of the target developer;

[0009] Searching the backend server database for the latest developer behavior data of the target software project within a set period of time according to the developer identification request;

[0010] When there is no latest developer behavior data in the backend server database, searching and downloading 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 permission for the repository;

[0012] When the next privileged event executed by the target developer cannot be found in chronological order, the target developer is marked as an external developer in the time period from the creation time of the privileged event to the set time period;

[0013] The time period during which the target developer has the mark of the external developer in the target software project is returned to the user terminal.

[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 steps of:

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

[0016] Start searching in chronological order whether the next privileged event executed by the target developer exists, and perform developer marking processing for the next time period.

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

[0018] Filtering the developer behavior data corresponding to the target developer from all developer behavior data of the target software project according to the unique identity of the target developer;

[0019] According to the developer behavior data corresponding to the target developer, the time period during which the target developer serves as an external developer in the target software project is calculated and returned to the user end.

[0020] On the other hand, a device for identifying external developers of an open source project is also provided, comprising:

[0021] A request receiving module, used to obtain a developer identification request sent by a user; the developer identification request includes the name of the target software project and the unique identity of the target developer;

[0022] A database search module is used to search the backend server database for the latest developer behavior data of the target software project within a set period of time according to the developer identification request;

[0023] The project acquisition module is used to search 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;

[0024] An 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 permission for the repository;

[0025] A developer marking module is used to mark the target developer as an external developer in the time period from the creation time of the privileged event to the set time period when the next privileged event executed by the target developer cannot be found in chronological order;

[0026] The identification and returning module is used to return the time period during which the target developer has the mark of the external developer in the target software project to the user end.

[0027] In one of the embodiments, 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 in the period from the creation time of the next privileged event to a set time period, and jump to execute the developer marking process in the next time period; the set time period is three months.

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

[0029] A data filtering module, used to filter out developer behavior data corresponding to a target developer from all developer behavior data of a target software project according to a unique identity identifier of the target developer;

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

[0031] On the other hand, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor implements the steps of the above-mentioned method for identifying external developers of open source projects when executing the computer program.

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

[0033] The above-mentioned open source project external developer identification method, device and equipment first searches the background server database for the latest developer behavior data of the target software project within a set time period according to the developer identification request sent by the user end. If there is no latest developer behavior data, the latest developer behavior data of the target software project is searched and downloaded from the Internet to the background server database. The behavior event that requires write permission of the repository corresponding to the latest developer behavior data is marked as a privileged event and stored in the background server database. Then, when the next privileged event executed by the target developer cannot be found in chronological order, the target developer is marked as an external developer in the time period from the creation time of the privileged event to the set duration. Finally, the time period when the target developer has the external developer mark in the target software project is returned to the user end, thereby completing the open source project external developer identification processing currently requested.

[0034] Compared with traditional identification technologies, this technology focuses on the evolution of developers' roles during the project cycle, and can automatically and efficiently identify when developers participate as external contributors and when they become internal developers of the project. This technology deeply analyzes the prevalence of developer role transitions in the open source community, thereby significantly improving the accuracy of identifying external developers, and is suitable for identifying external developers of open source software projects in the open source development community. In addition, it can also effectively cope with the challenges of identifying external developers brought about by a large number of projects and users in the open source development community, ensuring the feasibility and efficiency of large-scale identification tasks. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the conventional technology, the drawings required for use in the embodiments or the conventional technology descriptions are briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0036] Figure 1 A schematic diagram of a flow chart of a method for identifying external developers of an open source project in one embodiment;

[0037] Figure 2 A schematic diagram of a flow chart of a method for identifying external developers of an open source project in another embodiment;

[0038] Figure 3 A schematic diagram of an application flow of a method for identifying external developers of an open source project in one embodiment;

[0039] Figure 4 The module structure diagram of an apparatus for identifying external developers of open source projects in one embodiment is shown. DETAILED DESCRIPTION

[0040] In order to make the purpose, technical scheme and advantages of the present application clearer, the present application is further described in detail below in conjunction with the accompanying drawings and Examples. It should be understood that the specific embodiments described herein are only used to explain the present application and are not intended to limit the present application. Unless otherwise defined, all technical and scientific terms used in the present application have the same meaning as those commonly understood by those skilled in the art of the present application. The terms used in the specification of the present application are only for the purpose of describing specific embodiments and are not intended to limit the present application.

[0041] It should be noted that the reference to "embodiment" in this application means that the specific features, structures or characteristics described in conjunction with the embodiment may be included in at least one embodiment of the present invention. The presentation of this phrase at various locations in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment that is mutually exclusive with other embodiments. It will be appreciated by those skilled in the art that the embodiments described in this application may be combined with other embodiments. The term "and / or" used in the specification of the present invention and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes these combinations.

[0042] Identifying external developers is an important task in field research. Usually, in order to ensure the security of the code and the effectiveness of project management, there will be a permission list in the repository of the open source project to record in detail which users have special permissions in addition to the default permissions, such as being able to edit or manage documents and code files 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, in order to protect user privacy, the permission list of the repository is usually only open to internal personnel of the project, and non-internal personnel of the project do not have the permission to obtain the permission list of the repository.

[0043] Alternatively, external developers are identified through intuitive judgment and personal networks of community members, but this approach is not only inefficient but also susceptible to subjective preferences and internal community dynamics. For example, a potentially capable developer may be overlooked due to a lack of direct contact with the core team or low visibility in the community. As the number of open source community members increases, the feasibility and accuracy of manually identifying and evaluating external developers is greatly reduced.

[0044] In addition, existing methods for identifying developer roles are usually static and do not take into account the dynamic changes in developer roles in the open source community. The migration of developer roles is a common phenomenon in the open source ecosystem. Usually, new members can be gradually recognized and accepted as internal staff by the core team of the project through contributions and community interactions; at the same time, role transition is two-way, and internal staff may also leave the core team for personal or professional reasons and return to the role of external developers. This developer mobility puts higher demands on the identification method of external developers.

[0045] Therefore, how to develop a new external developer identification method 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 that technical personnel in this field are extremely concerned about.

[0046] The following will describe the implementation of the present invention in detail with reference to the accompanying drawings in the embodiment diagram of the present invention.

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

[0048] S12, obtaining a developer identification request sent by the user; the developer identification request includes the name of the target software project and the unique identity (ID) of the target developer; it is understood that after receiving the developer identification request sent by the user (which may include the name of the target software project and the ID of the target developer), the server can first query whether there is the latest user behavior data of the target software project in the backend server database according to the name of the target software project, 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 also the developer that the current user needs to identify in the target software project.

[0049] S14, searching the background server database for the latest developer behavior data of the target software project within a set period of time according to the developer identification request; it can be understood that the server searches the background server database maintained by it to determine whether there is updated data within a set period of time (which can be recorded as within N hours) for the target software project, which 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 period is 1 day, N=48 means that the data expiration period is 2 days, and so on.

[0050] S16, 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; it can be understood that when the server fails to find the latest developer behavior data of the target software project from the background server database, it is determined that the background server database does not yet have complete data of the target software project, and therefore the data search for the target software project can be performed directly from the Internet and the latest developer behavior data of the target software project can be downloaded from the found open source platform to the background server database, and stored in the background server database for backup.

[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 permission to the repository; it is understandable that the server can determine whether the target developer behavior event requires write permission to the repository based on the existing event type description of the open source platform, and if so, mark it as a privileged event. The marked latest developer behavior data is stored in the backend server database for standby.

[0052] S20, when the next privileged event executed by the target developer cannot be found in chronological order, the target developer is marked as an external developer in the time period from the creation time of the privileged event to the set duration; it can be understood that after obtaining a privileged event executed by the current 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 in the time 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 in this time period. The set duration can be set by the user or the relevant system administrator according to the actual identification needs, for example but not limited to one month, three months or half a year.

[0053] S22, returning the time period during which the target developer has the mark of the external developer in the target software project to the user end.

[0054] It can be understood that after obtaining the time period when the target developer acts as an external developer in the target software project, the server can return the time period to the user end in real time, or it can return all the time periods when the target developer acts as an external developer in the target software project to the user end at one time after completing all identified time periods and obtaining the identification results.

[0055] The above-mentioned method for identifying external developers of open source projects first searches the background server database for the latest developer behavior data of the target software project within a set time period according to the developer identification request sent by the user end. If there is no latest developer behavior data, the latest developer behavior data of the target software project is searched and downloaded from the Internet to the background server database. The behavior events that require write permission of the repository corresponding to the latest developer behavior data are marked as privileged events and stored in the background server database. When the next privileged event executed by the target developer cannot be found in chronological order, the target developer is marked as an external developer in the time period from the creation time of the privileged event to the set time length. Finally, the time period when the target developer has the external developer mark in the target software project is returned to the user end, thereby completing the external developer identification processing of the open source project currently requested.

[0056] Compared with traditional identification technologies, this technology focuses on the evolution of developers' roles during the project cycle, and can automatically and efficiently identify when developers participate as external contributors and when they become internal developers of the project. This technology deeply analyzes the prevalence of developer role transitions in the open source community, thereby significantly improving the accuracy of identifying external developers, and is suitable for identifying external developers of open source software projects in the open source development community. In addition, it can also effectively cope with the challenges of identifying external developers brought about by a large number of projects and users in the open source development community, ensuring the feasibility and efficiency of large-scale identification tasks.

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

[0058] S15, filtering developer behavior data corresponding to the target developer from all developer behavior data of the target software project according to 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 serves as an external developer in the target software project and return the calculated time period to the user end.

[0060] It is understandable that, since the server has found the complete data of the target software project in the backend server database, it can use these data to directly calculate the time period during which the target developer is an external developer in the target software project and return it to the user. The automatic identification process of the target developer in the target software project is completed, and there is no need to search for data online, so the calculation process is more efficient and consumes less computing resources.

[0061] Specifically, after the user makes a corresponding request to the server to obtain the time period when the target developer in the target software project is an external developer, the server finds all the existing developer behavior data about the target software project in the background server database, and then finds the developer behavior data belonging to the target developer's ID, and then calculates (the calculation process is the same as the above steps S18 to S20) the time period when the target developer is an external developer in the target software project from these data, and returns it to the user. The automated identification of the identity of developers in the open source development community simplifies the tedious and repetitive data acquisition process, makes full use of the existing local results, greatly simplifies the workload of the staff, has good flexibility, and can cope with the external developer identification of massive projects and users.

[0062] In some embodiments, the server can also perform regular checks on all locally available open source software projects and update the corresponding resource libraries. It is understandable that the server can also perform regular checks on locally available open source software projects, check the local developer behavior data storage of the project, and can update the corresponding local database (resource) library by itself (or according to the set update time interval trigger), calculate the time period of each developer as an external developer in each open source software project and store it for backup, so that when other users initiate an identification request, they can return the time period of the external developer they need as soon as possible, thereby further improving the identification efficiency, and can optimize the allocation and use of the server's computing resources by selecting to check and update during the server's idle time.

[0063] In one embodiment, 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 an open source project may further include the steps of:

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

[0065] Start searching in chronological order whether the next privileged event executed by the target developer exists, and perform developer marking processing for the next time period.

[0066] It can be understood that the server can check the next privileged event executed by the target developer in chronological order from the earliest to the latest. If it does not exist, then jump to step S20; otherwise, the target developer is marked as an internal developer for three months starting from the creation time of the next privileged event, and the above steps of finding the next privileged event executed by the target developer and its time period marking processing in chronological order are repeated until the marking processing of all time periods is completed, so as to obtain the time period of the target developer as an external developer and the time period as an internal developer in the target software project, thereby achieving more complete identification processing.

[0067] It should be understood that although the above process Figures 1 to 3 The steps in the flowchart are shown in sequence as indicated by the arrows, but the steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified in the application, there is no strict order restriction for the execution of the steps, and the steps can be executed in other orders. Figures 1 to 3 At least part 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 sequentially, but can be executed in turn or alternately with other steps or at least part of the sub-steps or stages of other steps.

[0068] In one embodiment, Figure 4As shown, there is also provided an open source project external developer identification device 100, comprising a request receiving module 11, a database search module 13, a project acquisition module 15, an event marking module 17, a developer marking module 19 and an identification return module 21. Among them, the request receiving module 11 is used to obtain a developer identification request sent by a user end; the developer identification request includes the name of the target software project and the unique identity of the target developer. The database search module 13 is used to search the background server database for the latest developer behavior data of the target software project within a set period of time according to the developer identification request. The project acquisition module 15 is used to search and download the latest developer behavior data of the target software project from the Internet to the background server database when there is no latest developer behavior data in the background 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 background server database; the target developer behavior event is a behavior event that requires the write permission of the repository. The developer marking module 19 is used to mark the target developer as an external developer in the time period from the creation time of the privileged event to the set duration when the next privileged event executed by the target developer cannot be found in chronological order. The identification and returning module 21 is used to return the time period during which the target developer has the mark of the external developer in the target software project to the user end.

[0069] The above-mentioned open source project external developer identification device 100 first searches for the latest developer behavior data of the target software project within a set time period in the background server database according to the developer identification request sent by the user terminal. If there is no latest developer behavior data, the latest developer behavior data of the target software project is searched and downloaded from the Internet to the background server database. The behavior event that requires the write permission of the repository corresponding to the latest developer behavior data is marked as a privileged event and then stored in the background server database. When the next privileged event executed by the target developer cannot be found in chronological order, the target developer is marked as an external developer in the time period from the creation time of the privileged event to the set time length. Finally, the time period when the target developer has the external developer mark in the target software project is returned to the user terminal, thereby completing the open source project external developer identification processing currently requested.

[0070] Compared with traditional identification technologies, this technology focuses on the evolution of developers' roles during the project cycle, and can automatically and efficiently identify when developers participate as external contributors and when they become internal developers of the project. This technology deeply analyzes the prevalence of developer role transitions in the open source community, thereby significantly improving the accuracy of identifying external developers, and is suitable for identifying external developers of open source software projects in the open source development community. In addition, it can also effectively cope with the challenges of identifying external developers brought about by a large number of projects and users in the open source development community, 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 in the period from the creation time of the next privileged event to a set time period, and jump to execute the developer marking process in the next time period; the set time period is three months.

[0072] In one embodiment, when the latest developer behavior data is already in the backend server database, the open source project external developer identification device 100 may also include a data filtering module for filtering the developer behavior data corresponding to the target developer from all developer behavior data of the target software project according to the unique identity of the target developer. The identification return module 21 may also be used to calculate the time period of the target developer as an external developer in the target software project according to the developer behavior data corresponding to the target developer and return it to the user end.

[0073] It can be understood that the explanation of each feature in each embodiment of the above-mentioned open source project external developer identification device 100 can be understood by referring to the explanation of the corresponding features of each embodiment of the open source project external developer identification method above, and will not be repeated here. The various modules in the above-mentioned open source project external developer identification device 100 can be implemented in whole or in part by software, hardware and a combination thereof. The above-mentioned modules can be embedded in or independent of a device with data processing functions in the form of hardware, or can be stored in the memory of the aforementioned device in the form of software, so that the processor can call and execute the operations corresponding to the above modules. The aforementioned device can be but not limited to various types of data calculation and processing devices already available in the art.

[0074] In one embodiment, a computer device is also provided, including a memory and a processor, the memory storing a computer program, and the processor implementing the following processing steps when executing the computer program: obtaining a developer identification request sent by a user end; the developer identification request includes the name of the target software project and the unique identity of the target developer; searching for the latest developer behavior data of the target software project within a set time period in the background server database according to the developer identification request; 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 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 background server database; the target developer behavior event is a behavior event that requires write permission of the repository; when the next privileged event executed by the target developer cannot be found in chronological order, marking the target developer as an external developer in the time period from the creation time of the privileged event to the set time length; and returning the time period when the target developer has the external developer mark in the target software project to the user end.

[0075] It can be understood that in addition to the memory and processor mentioned above, the above-mentioned computer device may also include other software and hardware components not listed in this specification. The specific details can be determined according to the model of the specific data processing device in different application scenarios, and this specification will not list them one by one in detail.

[0076] In one embodiment, when the processor executes the computer program, the processor may also implement the steps or sub-steps added in each embodiment of the above-mentioned open source project external developer identification method.

[0077] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. As an illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus dynamic random access memory (RambusDRAM, referred to as RDRAM) and interface dynamic random access memory (DRDRAM).

[0078] The technical features of the above embodiments can be combined arbitrarily. In order to make the description concise, all possible combinations of the technical features in the above embodiments are not described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification. The above embodiments only express several implementation methods of the present application, and their descriptions are relatively specific and detailed, but they cannot be understood as limiting the scope of the invention patent. It should be pointed out that for ordinary technicians in this field, without departing from the concept of the present application, several variations and improvements can be made, all of which belong to the protection scope of the present application. Therefore, the protection scope of the patent of this application shall be based on the attached claims.

Claims

1. A method for identifying external developers of an open source project, characterized in that: Includes steps: Obtaining a developer identification request sent by a user terminal; the developer identification request includes the name of the target software project and a unique identity of the target developer; Searching the backend server database for the latest developer behavior data of the target software project within a set period of time according to the developer identification request; When the backend server database does not have the latest developer behavior data, searching 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 a backend server database; The target developer behavior event is a behavior event that requires write permission for the repository; When the next privileged event executed by the target developer cannot be found in chronological order, the target developer is marked as an external developer during the time period from the creation time of the privileged event to the set time period; The time period during which the target developer has the mark of an external developer in the target software project is returned to the user terminal.

2. The method for identifying external developers of open source projects according to claim 1, characterized in that: 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 steps of: Marking the target developer as an internal developer during the period from the creation time of the next privileged event to a set time period; the set time period is three months; Start searching in chronological order whether the next privileged event executed by the target developer exists, and perform developer marking processing for the next time period.

3. The method for identifying external developers of open source projects according to claim 1 or 2, characterized in that: When the latest developer behavior data is already in the backend server database, the open source project external developer identification method further includes the steps of: Filtering the developer behavior data corresponding to the target developer from all developer behavior data of the target software project according to the unique identity of the target developer; The time period during which the target developer serves as an external developer in the target software project is calculated according to the developer behavior data corresponding to the target developer and the calculated time period is returned to the user end.

4. A device for identifying external developers of open source projects, characterized in that: include: A request receiving module, used to obtain a developer identification request sent by a user terminal; The developer identification request includes the name of the target software project and the unique identity of the target developer; A database search module, used to search the backend server database for the latest developer behavior data of the target software project within a set period of time according to the developer identification request; A project acquisition module, used for searching and downloading the latest developer behavior data of the target software project from the Internet to the backend server database when the backend server database does not have the latest developer behavior data; An event marking module, 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 a backend server database; The target developer behavior event is a behavior event that requires write permission for the repository; A developer marking module, for marking the target developer as an external developer during a time period from the creation time of the privileged event to a set time period when the next privileged event executed by the target developer cannot be found in chronological order; The identification and return module is used to return the time period during which the target developer has the mark of the external developer in the target software project to the user terminal.

5. The device for identifying external developers of open source projects according to claim 4, characterized in that: When the next privileged event executed by the target developer is found in chronological order, the developer marking module is further used to mark the target developer as an internal developer in the period from the creation time of the next privileged event to the set time length, and jump to execute the developer marking process in the next time period; The set duration is three months.

6. The device for identifying external developers of open source projects according to claim 4 or 5, characterized in that: When the latest developer behavior data is already in the backend server database, the open source project external developer identification device further includes: 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 the unique identity of the target developer; The identification and return module is further used to calculate the time period during which the target developer serves as an external developer in the target software project according to the developer behavior data corresponding to the target developer, and return the calculation to the user end.

7. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that: When the processor executes the computer program, the steps of the method for identifying external developers of open source projects described in any one of claims 1 to 3 are implemented.

Images