System and method for software development

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to U.S. provisional patent application serial No. 60/370,937, filed Apr. 8, 2002.

TECHNICAL FIELD

[0002] This invention relates to computer-based methods and systems for developing and distributing software and, more particularly, to methods and systems facilitating the distributed development of software.

BACKGROUND INFORMATION

[0003] In the United States and elsewhere, computers have become part of people's everyday lives, both in the workplace and in personal endeavors. This is because a general-purpose computer can be programmed to run a variety of software programs each providing different processing and networking functions. Computer programmers develop computer code. Some companies hire large numbers of computer programmers to develop code on the company's behalf.

[0004] One approach is to hire large numbers of programmers and develop software “in house.” While this affords significant control over the programming staff, finding, hiring, and maintaining such a staff can be cost prohibitive. Furthermore, as individual programmers leave the company, much of the technical and industrial knowledge is also lost. Alternatively, many companies “outsource” their programming through consulting firms, or contract employees. This approach relieves the company of the burdens of managing individual employees, however the quality of the work is often suspect, and the challenges of integrating work from numerous outside vendors can be significant.

SUMMARY OF THE INVENTION

[0005] There is a need for ways for organizations to obtain high-quality software without maintaining a large, permanent software development organization. Techniques that have been suggested to improve software development are code re-use and component-based design. But even if organizations adopt such techniques, they still need to obtain high-quality components in an affordable manner.

[0006] In general, the invention relates to motivating a group of distributed software developers, otherwise unrelated to each other, to participate in the distributed development of high-quality software. Generally, the motivation for the developers results from financial and competitive incentives. The independence of the developers allows for enforcement of rigorous design and quality analysis, which in turn results in very high quality (e.g., enterprise quality) software.

[0007] In one aspect, a product manager communicates a specification for a software program to the group of developers, who may be software architects, designers, coders, or the like. The product manager receives one or more submissions in response to the communicated specification. Each submission is scored, at least in part based on the degree to which the submission satisfies the communicated specification. One of the submissions is selected, responsive to the score, for inclusion in a software repository for distribution to the public. Royalties can be allocated to the developers who submitted the designs or code that is included in the repository. It should be understood that the software program can be any sort of program, including for example without limitation, a component, a class, a library, an application, or some combination or collection of one or more of these.

[0008] Various embodiments can include one or more of the following features. The ratings assigned to a developer can be derived from the developer's performances in one or more coding competitions, which in turn can be held online. The ratings assigned to a developer can be derived from the developer's prior submissions of designs for software programs. The ratings assigned to a developer can be derived from the developer's prior submissions of software programs. The specifications sent to the developers can be for the design of a software program. The specifications sent to the developers can be for the development of a software program. The software program can be a software component. The software program can be one of a software application, a combination of one or more software components, or a software module. The ratings derived for a developer can be used to determine the subset of programmers that should receive the specifications. The existence of a rating for a developer can determine if the developer is included in the subset of programmers that should receive the specifications. The developers can submit a design for a software program. The developers can submit computer code for a software program. The developer can be a software designer. The developer can be software programmer. The score for a submission can be derived based on the submission being reviewed by a developer other than the developer who submitted the submission. The submission can be selected for inclusion into the software repository based on receiving a minimum score. The submissions included in the software repository can be certified to operate in computing environments different from the computing environment used for the original submission.

[0009] In general, another aspect of the invention relates to compensating developers for the design or development of software programs. A method includes soliciting multiple developers for submissions of software programs, receiving at least one software program in response to the solicitation, scoring the received responses, selecting a software program for distribution to the public based on the score, distributing the program to the public, and allocating a portion of the revenue received from the distribution of the program to the developer who submitted the selected design or the code for the program.

[0010] Embodiments can include one or more of the following features. Prior to soliciting the developers, rating the developers. The developers can be rated based on their performance in an online coding competition. The developers can be rated based on their prior submissions of a design for a software program. The developers can be rated based on their prior submissions of a software program. The software program can be a software component. The software program can be a software application, a combination of software components, or a software module. Instead, or in addition, the programmers can be solicited at least in part based on their rating, or having a rating. The allocation of proceeds from the distribution of the program can be based at least in part on the rating of the developers. The allocation of proceeds from the distribution of the program can be based at least in part on the number of hours a developer spent developing the software program and/or based on the proportion of work contributed by the developer. The allocation of proceeds from the distribution of the program can be based at least in part on the number of times and/or to whom the software program is distributed.

[0011] In yet another aspect, the invention relates to systems for implementing the methods just described. For example, a system for facilitating the distributed development of software programs includes a rating engine for rating the skills of software developers, and a server for communicating software specifications to developers who have been previously rated by the rating engine. The system further includes a server for receiving software programs as they are submitted from the developers, and a module for scoring the submitted software programs.

[0012] In one embodiment of this aspect of the invention, the system can also include a reviewing module to allow developers to review submissions submitted by other developers and/or scorecards produced by the review board. The system can also include a repository for storing the software programs along with all associated design documents. The repository can include an online showroom to display the programs, and can also include sample applications built using the submitted software programs. The repository can also include a module for demonstrating the functionality of the software programs to the public.

[0013] In another embodiment of the invention, the system can also include a calculation module for allocating revenue among programmers who have previously submitted software programs. The allocation of revenue can be based, at least in part, on the ratings of the programmers. The allocation of revenue can be based, at least in part, on the number of hours the programmers spent designing or developing the software program. The allocation of revenue can be based, for example, at least in part on the number of times and/or to whom the software program is distributed.

[0014] Other aspects and advantages of the invention will become apparent from the following drawings, detailed description, and claims, all of which illustrate the principles of the invention, by way of example only.

BRIEF DESCRIPTION OF THE DRAWINGS

[0015] In the drawings, like reference characters generally refer to the same parts throughout the different views. Also, the drawings are not necessarily to scale, emphasis instead generally being placed upon illustrating the principles of the invention.

[0016]FIG. 1 is a block diagram of an embodiment of a distributed software development system having a server according to the invention.

[0017]FIG. 2 is a block diagram of one embodiment of a distributed software development team according to the invention.

[0018]FIG. 3 is a block diagram of a second embodiment of a distributed software development team according to the invention.

[0019]FIG. 4 is a flow chart of an embodiment of the steps performed by the virtual software development team when developing a software program according to the invention.

[0020]FIG. 5 is a flow chart of an embodiment of the steps performed by the members of the virtual software development team according to the invention.

[0021]FIG. 6 is a more detailed flow chart of an embodiment of the steps of FIG. 5 performed by the virtual members of the software design team.

[0022]FIG. 7 is a more detailed flow chart of an embodiment of the steps of FIG. 5 performed by the virtual members of the software programming team.

[0023]FIG. 8 is a more detailed block diagram of an embodiment of the server of FIG. 1 to facilitate the development and/or distinction of software programs according to the invention.

[0024]FIG. 9 is a more detailed block diagram of an embodiment of the server if FIG. 1 to facilitate the posting of specifications and the receipt and scoring of submissions according to the invention.

[0025]FIG. 10 is a block diagram of an embodiment of a software catalog according to the invention.

[0026]FIG. 11 is a block diagram of an embodiment of a software catalog system communicating with a first company and a second company according to the invention.

[0027]FIG. 12 is a block diagram of an embodiment of a software catalog system illustrating modification of a software component according to the invention.

[0028]FIG. 13 is a block diagram of an embodiment of a compensation data structure according to the invention.

[0029]FIG. 14 is a table illustrating an embodiment of a royalty-based compensation structure for the distributed software development team according to the invention.

[0030]FIG. 15 is a table illustrating another embodiment of a royalty-based compensation structure for the distributed software development team according to the invention.

[0031]FIG. 16 is a linear diagram illustrating an embodiment of a sliding scale royalty compensation structure supported by the server according to the invention.

DETAILED DESCRIPTION

[0032] Referring to FIG. 1, in one embodiment, a distributed software development system <b>101</b> includes at least one server <b>104</b>, and at least one client <b>108</b>, <b>108</b>′, <b>108</b>″, generally <b>108</b>. As shown, the distributed software development system <b>101</b> includes three clients <b>108</b>, <b>108</b>′, <b>108</b>″, but this is only for exemplary purposes, and it is intended that there can be any number of clients <b>108</b>. The client <b>108</b> is preferably implemented as software running on a personal computer (e.g., a PC with an INTEL processor or an APPLE MACINTOSH) capable of running such operating systems as the MICROSOFT WINDOWS family of operating systems from Microsoft Corporation of Redmond, Wash., the MACINTOSH operating system from Apple Computer of Cupertino, Calif., and various varieties of Unix, such as SUN SOLARIS from SUN MICROSYSTEMS, and GNU/Linux from RED HAT, INC. of Durham, N.C. (and others). The client <b>108</b> could also be implemented on such hardware as a smart or dumb terminal, network computer, wireless device, information appliance, workstation, minicomputer, mainframe computer, or other computing device, that is operated as a general purpose computer or a special purpose hardware device solely used for serving as a client <b>108</b> in the distributed software development system <b>101</b>.

[0033] Generally, in some embodiments clients <b>108</b> can be operated by software developers and are used by software developers to participate in software development. Clients <b>108</b> can also be operated by customers of the software developed by the software developers. In various embodiments, the client computer <b>108</b> includes a web browser <b>116</b>, client software <b>120</b>, or both. The web browser <b>116</b> allows the client <b>108</b> to request a web page (e.g. from the server <b>104</b>) with a web page request. An example of a web page is a data file that includes computer executable or interpretable information, graphics, sound, text, and/or video, that can be displayed, executed, played, processed, streamed, and/or stored and that can contain links, or pointers, to other web pages. In one embodiment, a user of the client <b>108</b> manually requests a web page from the server <b>104</b>. Alternatively, the client <b>108</b> automatically makes requests with the web browser <b>116</b>. Examples of commercially available web browser software <b>116</b> are INTERNET EXPLORER, offered by Microsoft Corporation of Redmond, Wash., and NETSCAPE NAVIGATOR, offered by Netscape Communications Corporation of Mountain View, Calif.

[0034] In some embodiments, the client <b>108</b> also includes client software <b>120</b>. The client software <b>120</b> provides functionality to the client <b>108</b> that allows a software developer to participate in a coding competition. The client software <b>120</b> may be implemented in various forms, for example, it may be in the form of a Java applet that is downloaded to the client <b>108</b> and runs in conjunction with the web browser <b>116</b>, or the client software <b>120</b> may be in the form of a standalone application, implemented in a multi-platform language such as Java or in native processor executable code. In one embodiment, if executing on the client <b>108</b>, the client software <b>120</b> opens a network connection to the server <b>104</b> over the communications network <b>112</b> and communicates via that connection to the server <b>104</b>. The client software <b>120</b> and the web browser <b>116</b> may be part of a single client-server interface <b>124</b>; for example, the client software can be implemented as a “plug-in” to the web browser <b>116</b>.

[0035] A communications network <b>112</b> connects the client <b>108</b> with the server <b>104</b>. The communication may take place via any media such as standard telephone lines, LAN or WAN links (e.g., T1, T3, 56 kb, X.25), broadband connections (ISDN, Frame Relay, ATM), wireless links, and so on. Preferably, the network <b>112</b> can carry TCP/IP protocol communications, and HTTP/HTTPS requests made by the web browser <b>116</b> and the connection between the client software <b>120</b> and the server <b>104</b> can be communicated over such TCP/IP networks. The type of network is not a limitation, however, and any suitable network may be used. Typical examples of networks that can serve as the communications network <b>112</b> include a wireless or wired ethernet-based intranet, a local or wide-area network (LAN or WAN), and/or the global communications network known as the Internet, which may accommodate many different communications media and protocols.

[0036] The servers <b>104</b> interact with clients <b>108</b>. The server <b>104</b> is preferably implemented on one or more server class computers that have sufficient memory, data storage, and processing power and that run a server class operating system (e.g. SUN Solaris, GNU/Linux, MICROSOFT WINDOWS NT). Other types of system hardware and software than that described here could also be used, depending on the capacity of the device and the number of users and the size of the user base. For example, the server <b>104</b> may be part of a server farm or server network, which is a logical group of one or more servers. As another example, there could be multiple servers <b>104</b> that may be associated or connected with each other, or multiple servers could operate independently, but with shared data. In a further embodiment and as is typical in large-scale systems, application software could be implemented in components, with different components running on different server computers, on the same server, or some combination.

[0037] The server <b>104</b> can include a contest server, as described in co-pending U.S. patent application Ser. No. 10/041,393, entitled “Systems and Methods for Coding Competitions,” by Lydon et al.

[0038] In one embodiment, the server <b>104</b> enables the distributed software development of a software program by a virtual development team. The software program can be any sort of instructions for a machine, including, for example, without limitation, a component, a class, a library, an application, an applet, a logic table, a data block, or any combination or collection of one or more of any one or more of these. In one embodiment, the software program is a software component. Generally, a software component is a functional software module that may be a reusable building block of an application. Just as a few examples, software components include, but are not limited to, such components as a graphical user interface, a small interest calculator, an interface to a database manager, calculations for actuarial tables, a DNA search function, an interface to a manufacturing numerical control machine for the purpose of machining manufactured parts, a public/private key encryption algorithm, and functions for login and communication with a host application (e.g., insurance adjustment and point of sale (POS) product tracking). In some embodiments, components communicate with each other for needed services (e.g., over the communications network <b>112</b>). A specific example of a component is a JavaBean, which is a component written in the Java programming language. A component can also be written in any other language, including without limitation Visual Basic, C++, Java, and C#.

[0039] In one embodiment, the software program is an application. In some embodiments, he application can is comprised of one or more software components. In one embodiment, the software application is comprised of software components previously developed using the methods described below. In some embodiments, the application comprises entirely new software programs. In some embodiments, the application comprises a combination of new software programs and previously developed software components.

[0040] Referring to FIG. 2, a software development team can be used to develop software components. In one embodiment, the software development team <b>200</b> includes a product manager <b>202</b>. The product manager <b>202</b> is the manager for the development and deployment of a component. The product manager <b>202</b> can perform market research to identify a component that is potentially useful to a market. For example, the product manager <b>202</b> can perform research in an industry to determine if companies would find useful a component that has certain characteristics, and specify the requirements for such a component. The product manager <b>202</b> can also specify (without limitation) items such as the cost of the project, the project schedule, and the project risks. In one embodiment, the product manager <b>202</b> creates a project plan for the project, which may include an estimated project cost and schedule and a requirements document describing the scope and risks of the project.

[0041] An architect (also referred to as a “designer”) <b>208</b> designs the software component. The architect <b>208</b> preferably is a senior developer who acts as a mentor to and collaborates with one or more of the other team members <b>204</b>, <b>212</b>, <b>216</b> to design the architecture of the component. The architect <b>208</b> can also create test cases that meet the requirements for the component as described by the product manager <b>202</b>, for example in a requirements document, or by other communication with the product manager <b>202</b>. The architect <b>208</b> preferably designs the component in a manner that maximizes the potential re-use of the software component. The architect <b>208</b> may therefore base the design of the software component on, for instance but not limited to, the number of interfaces available, the compatibility of the component to other components, and the speed of execution of each design of the component.

[0042] One or more QA developer(s) <b>216</b>, <b>216</b>′ (generally, <b>216</b>) then develops a test plan for the component. The test plan can include normal and extreme input to simulate production and stress. In one embodiment, a QA developer <b>216</b> develops the test plan using the requirements specification written by the product manager <b>202</b>, and the design specification written by the architect <b>208</b>. The QA developer <b>216</b> attempts to identify potential problem areas in the specification and tailor the QA testing towards one or more of those areas. Moreover, the QA developer <b>216</b> may communicate with the other team members to improve or discuss the test plan. Once it is complete, the test plan can be reviewed by the architect <b>208</b> and/or the product manager <b>202</b>, to verify that the test plan will adequately test the component requirements.

[0043] One or more developer(s) <b>222</b>, <b>222</b>′ (generally, <b>222</b>) then develops a component to meet the requirements described by the specification. In one embodiment, the developer <b>222</b> submits an object model to the architect <b>208</b>, such as a model in the Unified Modeling Language (UML). Once the architect <b>208</b> approves the object model, the developer <b>222</b> develops the code to implement the component. The developer uses the test plan to confirm that the code as implemented meets the requirements. When the developer <b>222</b> completes the code, the architect <b>208</b> and/or product manager <b>202</b> review the code. In one embodiment, the architect <b>208</b> reviews the code, for example but not limited to, to confirm functionality, style, adherence to coding standards, performance, and stability.

[0044] Once the component is developed, the QA developer <b>216</b> tests the completed component, and verifies that it is acceptable, according to the test plan.

[0045] Although the software development team <b>200</b> shown in the figure includes one product manager <b>202</b>, one architect <b>208</b>, two QA developers <b>216</b>, <b>216</b>′, and two developers <b>222</b>, <b>222</b>′ it will be understood that this is only for exemplary purposes and the number of developers <b>222</b> and QA developers <b>216</b> will depend on the particular project. It should also be understood that one or more of the members of the software development team <b>200</b> can operate one or more clients <b>108</b> and communicate with the server <b>104</b> via the communications network <b>112</b> as shown in FIG. 1.

[0046] In some embodiments, the software development team <b>200</b> is comprised of developers with no relationship to each other. For example, the developers <b>222</b> may not know (or if they do know each other, be very familiar with), the QA developers <b>216</b>, or the product manager <b>202</b>. One advantage to this particular embodiment is the developers are more willing to participate in unbiased peer review of the software design or component developed by another. Further, in some embodiments, the review process can be kept anonymous, so that the developers do not know whose work they are reviewing. Reviewing work of the development team <b>200</b> in this manner, with adherence to a strict development procedure, greatly enhances the quality of the final product. In one embodiment, the peer review process is implemented with a development environment residing on the server, <b>104</b>. In another embodiment, other sorts of development environments are used, for example, the peer review can done using the individual developer's computer.

[0047] Referring now to FIG. 3, in a variation of the embodiment of FIG. 2, the product manager <b>302</b> moderates a development team <b>300</b>, which is formed from an distributed group of developers (used here to include designers, design reviewers, developers, development reviewers, etc.). For example, the designers and developers can be members of an organization or a community dedicated to collaborative computer programming and distributed software development. In one embodiment, the product manager <b>302</b> facilitates an initial discussion among such a group of developers, which can include potential or actual development team members <b>300</b>. The discussion can be a collaboration to identify requirements for a new or improved software component to be developed. In some embodiments, the discussion takes place in an online forum, which is can be accessed by developers in a development community. In one embodiment, participation in such forums is encouraged by selecting participants for architecture/design <b>304</b> and development <b>310</b> boards from those who meet other criteria and participate in such discussions.

[0048] Developers <b>312</b> can request inclusion on the development team <b>300</b>, the product manager <b>302</b> can invite developers <b>312</b> to join the development team <b>300</b>, or some combination. In some embodiments, the product manager <b>302</b> creates an incentive for developers <b>312</b> to participate in the development team by providing monetary compensation or awards for developers <b>312</b> who provide quality submissions. In some embodiments, the product manager <b>302</b> creates incentive to developers <b>312</b> to participate by fostering competition among the developers <b>312</b>. For example, in some embodiments, the developers <b>312</b> receive increased ratings by participating in certain development teams.

[0049] The development team <b>300</b> includes an architecture review board <b>304</b>. The architecture review board <b>304</b> includes one or more developers <b>312</b> who review design submissions from software designers <b>328</b>. The architecture review board preferably has a small number of (e.g., less than ten) members, for example, three members, but can be any number. Generally, the review board is formed for only one or a small number of related projects. Review boards, in some embodiments, could be formed for an extended time, but it is also possible that changes in staffing could help maintain quality.

[0050] Preferably, one of the architecture review board members is selected, by the product manager <b>302</b>, the architecture review board <b>304</b>, or otherwise, to be a primary review board member <b>308</b>. If the board <b>304</b> is instituted for an extended time, typically, the primary review board member <b>308</b> is assigned for each component or related group of components, but the primary review board member <b>308</b> also can be the same for all components reviewed by that board <b>304</b>, depending on the availability and skills of the members. The primary review board member <b>308</b> is responsible for coordination and management of the activities of the board <b>304</b>.

[0051] In one embodiment, submissions for component designs meeting a particular specification are requested by the product manager <b>302</b>, and the design submissions made by designers <b>328</b> are judged by the architecture review board <b>304</b>. The primary review board member <b>308</b> screens the design submissions before they are reviewed by the other members of the architecture review board <b>304</b>, to allow the rest of the review board to judge only the best of the submissions. In some embodiments, the screening process includes scoring the submissions based on the degree to which they meet the requirements outlined in the specification. In some embodiments, scores are documented using a scorecard, which can be a document, spreadsheet, online form, database, or other electronic document.

[0052] In one embodiment, the primary review board member <b>308</b> informs the architecture review board <b>304</b> that one or more submissions have passed the screening process, and the architecture review board <b>304</b> review the design submissions. In some embodiments, the architecture review board <b>304</b> reviews the submissions based on requirements documented in the specification. In some embodiments, the architecture review board <b>304</b> scores the submissions. In some embodiments, the scores are documented using a scorecard, which can be a document, spreadsheet, online form, database, or other electronic document.

[0053] In some embodiments, the scores and reviews from the primary review board member <b>308</b> and the other members of the architecture review board <b>304</b> are aggregated into a final review and score. In some embodiments, the aggregation can comprise compiling information contained in one or more documents. Such aggregation can be performed by the, the primary review board member <b>308</b>, the other members of the architecture review board <b>304</b> or in one exemplary embodiment, the aggregation is performed using a computer-based system which resides on the server <b>104</b> (FIG. 1). In some embodiments, the product manager <b>302</b> resolves discrepancies or disagreements among the architecture review board <b>304</b>.

[0054] In one embodiment, the design with the highest combined score is selected as the winning design that will be used for implementation. A prize and/or recognition is given to the designer. In one embodiment, a portion of the payment to the designer is withheld until the end of the development review. For example, the designer may receive 75% of the payment and the end of the design review, and 25% is paid after the development review. There can also be prizes and/or recognition for the other submitted designs.

[0055] In some embodiments, in addition to reviewing the submissions, the architecture review board <b>304</b> can identify useful modifications to the specification or the design that should be included into the design. The primary review board member <b>308</b> documents the additional requirements, and communicates this information to the designer <b>328</b> who submitted the design. In one embodiment, the primary review board member <b>308</b> aggregates the comments from the review board <b>304</b>. The designer <b>328</b> can update the design and resubmit it for review by the architecture review board <b>304</b>. This process can repeat until the primary review board member <b>308</b> believes the design has met all the necessary requirements.

[0056] Once the architecture review board <b>304</b> validates that a design has sufficiently addressed the requirements of the specification, the primary review board member <b>308</b> notifies the product manager <b>302</b> that such a design has passed the design review process. The product manager <b>302</b> can then use the design to solicit submissions for software components that meet the specifications of the design. For example, the product manager <b>302</b> can make the design available on a web site or mailing list for implementation. The product manager <b>302</b> requests implemented components according to the design.

[0057] The development team <b>300</b> also includes a development review board <b>310</b> that is analogous to the architecture review board <b>304</b>. The development review board can be formed once the design is complete and selected, or can be selected at a different time, for example, at the time that the architecture review board <b>304</b> is formed. The membership of the development review board <b>310</b> can be the same as, or overlap with, the membership of the design review board <b>304</b>, although this may not be as desirable from a quality maintenance point of view. In some embodiments, the development review board <b>310</b> is not selected until the submissions for the development project are received.

[0058] The development review board <b>310</b> includes one or more developers <b>312</b> who review development submissions from software programmers <b>322</b>. The development review board <b>310</b> preferably has a small number of (e.g., less than ten) members, for example, three members, but can be any number. Generally, the development review board <b>310</b> is formed for only one or a small number of related projects. Review boards, in some embodiments, could be formed for an extended time, but a change in staffing (and continued competition for review board slots) could help maintain quality.

[0059] Preferably, one of the development review board <b>310</b> members is selected, by the product manager <b>302</b>, the development review board <b>310</b>, or otherwise, to be a primary development review board member <b>316</b>. If the board <b>310</b> is instituted for an extended time, typically, one of the development board members <b>310</b> is assigned to be the primary development review board member <b>316</b>, and is assigned for each component or related group of components, but the primary development review board member <b>316</b> also can be the same for all components reviewed by that board <b>310</b>, depending on the availability and skills of the members. The primary development review board member <b>316</b> is responsible for coordination and management of the activities of the board <b>310</b>.

[0060] In one embodiment, the primary development review board member <b>316</b> screens submitted components before the submissions are reviewed by the other members of the development review board <b>310</b>. In some embodiments, the screening process includes scoring the submissions based on the degree to which they meet the requirements outlined in the design specifications. In some embodiments, the scores are documented using a scorecard. The scorecard can be a document, spreadsheet, online form, database, or other electronic document.

[0061] In one embodiment, the primary development review board member <b>316</b> informs the other development review board members <b>310</b> that one or more submissions have passed the screening process. In one embodiment, the members of the development review board <b>310</b> review the submitted components. In some embodiments, the primary development review board member <b>316</b> reviews the submissions based on the detailed requirements documented in the design document described above. In some embodiments, the development review board <b>310</b> scores the submissions. In some embodiments, the scores are documented using a scorecard. The scorecard can be a document, spreadsheet, online form, database, or other electronic document.

[0062] In some embodiments, the score can be based on how the component performs in one or more test cases. In some embodiments, the test cases can include tests to determine the accuracy of the results received when the component is provided with valid input data. In some embodiments, the test cases can include tests to determine if the component behaves correctly when provided with invalid input data. In some embodiments, the test cases can include tests that determine how the component responds to a large quantity of input data.

[0063] In some embodiments, the scores and reviews from the primary development review board member <b>316</b> and the development review board <b>310</b> are aggregated into a final review. In some embodiments, the aggregation can comprise compiling information contained in one or more documents. In one embodiment, the product manager <b>302</b> aggregates the information. In some embodiments, the primary development review board member <b>316</b> aggregates the information. In one exemplary embodiment, the aggregation is done using a computer program, which in turn can reside on the server <b>104</b>. In some embodiments, the product manager <b>302</b> resolves discrepancies or disagreements among the development review board members <b>310</b>.

[0064] Once the development review board <b>310</b> validates that a implemented component meets the requirements of the specification, and is of sufficient quality, the primary development review board member <b>316</b> notifies the product manager <b>302</b> that the component has completed the development review process. In one embodiment, the implementation with the highest aggregate score is selected as the winning component that will be used. A prize and/or other recognition is given to the programmer. There can also be prizes and/or recognition for runners-up. The winning component can then be included in a software repository, for access and use by other programmers. As discussed further below, the participants in the design and implementation of the components can be paid commensurate with their contribution as a percentage of revenue for the use of the developed component.

[0065] In some embodiments, members of the development review board <b>310</b> can identify modifications to the implementation that should be included in the component. The primary development review board member <b>316</b> documents the additional requirements, so that the programmer <b>322</b> can update and resubmit. This process can repeat until the primary development review board member <b>316</b> believes the component is complete.

[0066] Referring also to FIG. 4, in one embodiment, the product manager <b>302</b> determines the scope of a development project (STEP <b>408</b>), as described above. The project manager <b>302</b> (possibly in coordination with the architect <b>308</b>) generates a specification of the component, components, or application to be developed, as well as a development timeline and budget (STEP <b>412</b>).

[0067] In one embodiment, the product manager <b>302</b> moderates a collaborative forum to determine the scope of potential development projects. In some embodiments, the information can be ideas for new software components, and in some embodiments, the information can be additional requirements for existing software components. In some embodiments, the information can be ides for software applications that are comprised of a combination of previously developed software components. The collaborative forum can consist of developers, customers, prospective customers, or others interested in the development of software components. In one embodiment, the collaboration forum is an online forum where participants can post ideas, questions, suggestions, or other information. In some embodiments, only a subset of the forum members can post suggestions to the forum. Once the product manager <b>302</b> determines the necessary requirements for the software component are collected, the product manager <b>302</b> can create the requirements specification for the component. The product manager <b>302</b> optionally can terminate the collaboration forum at that time.

[0068] In one embodiment, the specification defines the business plan and a stable hardware and/or software platform, or other architectural constraints. For example, the specification can define the network devices, servers, and general infrastructure to support the development and production of the project and product. The specification can also identify the language that the component must be programmed in, a functional overview of the software component, boundary conditions, efficiency requirements, computer platform requirements, interface requirements, performance criteria, test-case requirements, and/or documentation requirements of the component. In some embodiments, the specification can include an amount of money that will be paid to the designer who submits the best design.

[0069] Once the specification is completed, the product manager <b>302</b> communicates the specification to the other team members (STEP <b>416</b>). This communication can occur over the communications network <b>112</b> (FIG. 1), such as via an email message, a posting on a web page accessible by the web browser <b>116</b>, through a news group, facsimile, or other communication. The product manager <b>302</b> can communicate with the architect <b>208</b> and/or any other team members <b>212</b>, <b>216</b> to obtain comments and/or suggestions to the specification. In one embodiment, the product manager <b>302</b> communicates the specification to one or more members of the development review board <b>310</b>. In one embodiment, the development review board <b>310</b> selects the primary development review board member <b>316</b> according to the methods described above. The development review board can also review (and in some embodiments, select) the work of the primary development review board member <b>316</b>. The primary development review board member <b>316</b> then develops a test plan for the component (STEP <b>420</b>), as described above. The programmer <b>322</b> then develops a component that meets all requirements described by the specification (STEP <b>424</b>). Once the component is developed, the primary development review board member <b>316</b> tests the completed component (STEP <b>428</b>). If the software component passes the testing by the primary development review board member <b>316</b> (and in some embodiments the primary architect review board member <b>308</b> and/or the product manager <b>302</b>), the component is added to a component catalog (STEP <b>432</b>).

[0070] In one embodiment, the product manager <b>302</b> can have a component certified to operate in multiple computing environments (STEP <b>436</b>), where the computing environment might include variations or combinations of hardware platforms, operating systems, application servers, networking protocols, database management systems, and so on. For example, it might be beneficial to have a software component developed to operate on a Intel-based PC running WINDOWS 2000 Server and a SQLServer database certified to operate on a SUN Solaris server with an Oracle database. The certification can be done by a rated development member that is part of a certification pool. The certification pool has access to the server <b>104</b> in order to test components on multiple platform combinations. In some embodiments, the certification pool comprises developers that are selected to certify components, and they are compensated a nominal amount for each certification completed. The developers selected can be the developers used for development or other developers.

[0071] In one embodiment the primary architecture review board member <b>308</b> tests the functionality of the component and reviews the deliverables produced by the development team <b>200</b>, such as the source code and documentation. Furthermore, the primary architecture review board member <b>308</b> can communicate a final approval to the product manager <b>302</b> if the component sufficiently passes the architect's tests. The product manager <b>302</b> can also verify the deliverables for herself before approving them for the component catalog. In some embodiments, the component can be reviewed by a developer other than the developer who submitted the component.

[0072] Moreover, in some embodiments, the component is scored based on how well the component performed in the various tests that the development team <b>300</b> applied to the component. For instance, the product manager <b>302</b> can use the server <b>104</b> (FIG. 1) to subject the component to one or more tests that target the contribution of each member of the development team <b>300</b>. Using the results of these targeted tests, the product manager <b>302</b> (e.g., using the server <b>104</b>) can obtain a component development score for each team member, which can then be used to determine whether such team member will be used for a subsequent component development project. The rating of a team member is an ongoing process that includes, but is not limited to, performance of components, on time delivery, task fulfillment, and validity of deliverables.

[0073] The development team <b>300</b> may then determine that if the component has not scored above a predetermined amount, the component is not added to the component catalog. In one embodiment, if the component is not added, members of the development team <b>300</b> (e.g., developers <b>322</b>) are not compensated as highly for their work on the component as if the component obtained a higher score. Compensation may be in the form of, for instance, monetary compensation, vacations, tangible objects, intangible objects, or any combination thereof.

[0074] Referring to FIG. 5, developers optionally are rated (STEP <b>508</b>) according to their performance in coding competitions, their performance in designing, testing, or coding components, and possibly also other factors. The product manager <b>302</b> communicates the specification to developers (STEP <b>512</b>). In some embodiments, the product manager <b>302</b> only communicates the specification to developers who have a rating, or who have a rating value above a predetermined minimum.

[0075] Developers create designs or components in response to the specification, and submit those designs or components for review to the product manager <b>302</b>, primary architecture review board member <b>308</b>, or primary development review board member <b>316</b> (STEP <b>516</b>).

[0076] Each submission can then be scored, based on quality criteria, for example but not limited to, functionality, style, adherence to coding standards, performance, and stability (STEP <b>520</b>). Once each submission is evaluated, and one submission is selected as the winning submission (STEP <b>524</b>). The product manager <b>302</b> then allocates a portion of the proceeds to the developer who authored the winning submission using any of the methods described below (STEP <b>528</b>).

[0077] Referring to FIG. 6, in one specific embodiment, a product manager <b>302</b> conducts market research (STEP <b>602</b>) to determine the need for a particular software component. Based on the results of the research, the product manager <b>302</b> specifies the design requirements of the software component (STEP <b>604</b>).

[0078] The product manager <b>302</b> identifies (which can include selecting) the members of the architecture review board <b>304</b> (STEP <b>606</b>) and provides the specification to the architecture review board <b>304</b> (STEP <b>608</b>). In one embodiment, the product manager <b>302</b> places the specification on a web server for access by the architecture review board <b>304</b>.

[0079] The architecture review board <b>304</b> can be already determined, as a standing architecture review board <b>304</b>, or the architecture review board <b>304</b> members can be identified as members of the architecture review board <b>304</b> for this particular component. In one embodiment, the architecture review board <b>304</b> members are selected by the product manager <b>302</b> as a result of one or more of the their expertise, their ratings, and their expressed willingness to participate in this capacity. In one embodiment, the architecture review board <b>304</b> members are compensated for their participation in the review board <b>304</b>.

[0080] In one embodiment, the architecture review board <b>304</b> is open to members of the general public. In another embodiment, the architecture review board <b>304</b> is limited to software designers who have participated in at least one design or coding competition and are optionally pre-qualified based on their competition performance (STEP <b>610</b>). In another embodiment, only the excellent designers of one or more competitions are eligible for participation in the architecture review board <b>304</b>.

[0081] For instance, a series of competitions can be used to identify excellent developers from a large number of contestants. Alternatively, an architecture review board <b>304</b> member can be required to periodically have a component selected in this process. Once the product manager <b>302</b> provides the architecture review board members access to the specification, the board members <b>304</b> review the specification to understand the design requirements (STEP <b>612</b>). The board members <b>304</b> can ask for clarification or revision of the specifications, and the product manager <b>302</b> can respond. In this way, the review board members <b>304</b> make sure that they understand the requirements for the components that they will evaluate.

[0082] When the architecture review board <b>304</b> has reviewed the design requirements specification, the requirements are provided to designers. In some embodiments, prior to being granted access to the design specification, software designers <b>308</b>, <b>308</b>′ and <b>308</b>″, generally <b>308</b>, are pre-qualified (STEPS <b>614</b>, <b>614</b>′ and <b>614</b>″) as described above based on ratings, skills, or other criteria. The product manager <b>302</b>, or a member of the architecture review board <b>304</b> gives designers that meet pre-qualification requirements access to the specification. In some embodiments, access can be granted by a web page (which can require authentication for access), by email, or other technique. The designers <b>308</b> can review the specification (STEPS <b>616</b>, <b>616</b>′ and <b>616</b>″) and develop designs (STEPS <b>618</b>, <b>618</b>′ and <b>618</b>″). When a designer <b>308</b> has completed his or her design, the designer <b>308</b> submits the design to the architecture review board <b>304</b> (STEPS <b>620</b>, <b>620</b>′ and <b>620</b>″).

[0083] The designs can take a number of forms, depending on the component specified. Typically, the specifications for the component will include the requirements for the design. In one embodiment, the design includes class diagrams, which can be developed in the Unified Modeling Language (UML), for example using the Poseideon Computer Aided Software Engineering (CASE) tool, available from Gentleware AG of Hamburg, Germany. The design also includes use-case diagrams and sequence diagrams. The design also includes a written component design specification describing the design, a list of required algorithms, and class stubs for the classes in the design. The design also includes functional tests that can be used to test the program. In one such embodiment, the functional tests are tests compatible with the JUnit testing infrastructure. JUnit is open source software for testing Java software, which is available from www.sourceforge.net.

[0084] The architecture review board <b>304</b> reviews received designs (STEP <b>622</b>). In one embodiment, this review includes a first screening review by a primary reviewer, and then further review by other members of the review board. The first screening review determines that the required elements of the design are included (e.g., class, use-case, and sequence diagrams, component specification, required algorithms, class stubs, and functional tests).

[0085] The screening review can also determine that these elements appear complete. With regard to the class diagram, for example, and in particular the class definition, the screening review can determine any or all of that: (1) the class definition provides a descriptive overview of the class usage, (2) sub-packages have been created to separate functionality, (3) class scope matches class usage, (4) there is proper and effective use of programming techniques such as inheritance and abstraction, (5) interfaces are used properly, (6) suitable constructors are defined for the component, and that (7) class modifiers such as final, static, are appropriately used. The screening review can also determine, for example, with regard to the variable definition, that: (1) variable scope is correctly defined, (2) type assignments are defined appropriately for balance between efficiency and flexibility, and (3) that all variables are defined with an initial value. Further, with regard to method definition, for example, the screening review can determine that: (1) scope is correctly defined, exceptions are handled and used appropriately, modifiers are properly used, return types are used, method arguments are properly defined, and that the application programming interface (API) as stated in the requirements specification is available.

[0086] The screening review can also, for example, verify that use-case diagrams exist for all public methods in the design, and that sequence diagrams exist for each use case. The screening review can also, for example, with regard to test cases, verify that functional test cases are provided for each sequence diagram, and that they appear to be appropriate for those diagrams.

[0087] In one embodiment the initial screen reduces the number of entries to a manageable number for the review board to review, such as 5 entries.

[0088] The architecture review board evaluates the designs to determine whether they comply with the specifications (STEP <b>624</b>). In embodiments in which there is an initial screening, the members of the review board each perform a review to evaluate the submission.

[0089] In some embodiments, the architecture review board <b>304</b> calculates a score for the submission, based for example on the quality of the design and how well it complies with requirements stated in the specification. For example, a review board member will determine whether and to what degree: (1) the design addresses the requirements detailed in the functional specification, (2) the design effectively uses all required technologies (e.g., language, required components, etc.), (3) the design incorporates standard design patterns and methodologies where applicable, (4) the design balances the use of design patterns and principles with the expected component usage, (5) the design accounts for incorporating additional functionality and features beyond the initial intended usage.

[0090] In some embodiments, each architecture review board member also closely evaluates the degree to which the design elements. For example, with regard to the class diagram, and in particular, for example, the class definition, the architecture review board member evaluates whether the class diagram accurately and thoroughly depicts the required elements of the component. The board member also evaluates whether the design is suitable given the expected component usage and throughput requirements. With regard to variable definition, the board member evaluates whether variable types are suitable for the expected component usage, and confirms that the variables used meet the minimum and maximum value parameters. With regard to method definition, the board member evaluates the degree to which (1) the defined methods properly expose the API requirements defined in the requirements specification, (2) the methods provide access to and properly encapsulate the defined variables, and (3) the exceptions defined is an inclusive list of the anticipated exceptions. The board member can also evaluate whether (1) class relationships are well defined, (2) the use-case diagram thoroughly depicts class usage, (3) the sequence diagram thoroughly depicts the ordered interaction between classes, (4) the component specification provides sufficient information for this design to be implemented, details how invalid arguments should be handled for the defined methods, and details the exceptions thrown by the defined methods, and (5) that the test cases thoroughly and accurately address component functionality. The board member can then assign an overall score to each entry.

[0091] For example, the architecture review board <b>304</b> members can use the server <b>104</b> of FIG. 1 to record and communicate their evaluations of the component designs to the other board members. In one embodiment, the board member uses an on-line evaluation form to evaluate each component. The evaluations of the board members can then be identified, and the components ranked by board member scores received.

[0092] In one embodiment, the architecture review board <b>304</b> members can also use the server <b>104</b> of FIG. 1 to subject the design to one or more tests that target individual requirements as defined in the specification. Using the results of these targeted tests, members of the architecture review board <b>304</b> (e.g., using the server <b>104</b>) can obtain a design score for each submission. Based on the evaluation of the submission(s) the architecture review board <b>304</b> selects a design as the winning submission (STEP <b>626</b>).

[0093] In some cases, modifications may need to be made to a design, even a design that is the high scorer, based on additional ideas or problems identified by the reviewers. In one embodiment, the architecture review board <b>304</b> sends the design back to the designer <b>308</b> who submitted the winning design, along with suggestions for modifications, explicit directions to make certain modifications, or other instructions, and so on. In some embodiments, the primary architecture review board member makes the modifications. The designer <b>308</b> incorporates the changes into the design (STEP <b>628</b>) and resubmits the design to the architecture review board <b>304</b> (STEP <b>630</b>). The architecture review board <b>304</b> then performs a final quality control review of the design (STEP <b>632</b>), and sends the design to the product manager <b>302</b>. The product manager <b>302</b> can then use the design to solicit developed software components based on the winning design (STEP <b>634</b>), for example as further illustrated with reference to FIG. 7. The product manager <b>302</b> can also pay the winning designer <b>308</b>, either a flat fee, or using methods described below.

[0094] Referring to FIG. 7, once a software design is available, for example by using the method of FIG. 6 or otherwise, the design can be used to facilitate the development of a software component.

[0095] The product manager <b>302</b> identifies the members of a development review board <b>310</b> (STEP <b>702</b>). This could, optionally, include prior or concurrent selection of a development review board for the component. The product manager <b>302</b> provides the design to the development review board <b>310</b> (STEP <b>704</b>). In one embodiment, the product manager <b>302</b> places the design on a web server for access by the development review board.

[0096] The development review board <b>310</b> can already be determined, as a standing development review board <b>310</b>, or the development review board <b>310</b> members can be identified as members of the development review board for a particular component or group of components. In one embodiment, the development review board <b>10</b> members are selected by the product manager <b>302</b> as a result of their expertise, their ratings, and their expressed willingness to participate in this capacity. In one embodiment, the development review board members are selected after the software components are submitted to allow all developers an opportunity to submit components. In one embodiment, the development review board <b>310</b> members are compensated for their participation in the review board <b>310</b>. This compensation can be in the form of recognition, a flat or hourly fee, or a percentage of revenue generated by the component.

[0097] In one embodiment, the development review board <b>310</b> is open to members of the general public. In another embodiment, the development review board <b>310</b> is limited to software developers who have participated in at least one design or coding competition and are optionally pre-qualified based on their competition performance (STEP <b>710</b>). In another embodiment, only the excellent developers of one or more competitions are eligible for participation in the development review board <b>310</b>.

[0098] For instance, a series of competitions can be used to identify excellent developers from a large number of contestants. Alternatively, a development review board <b>310</b> member can be required to have recently submitted one or more winning component(s) or designs. Once the product manager <b>302</b> grants the development review board <b>310</b> access to the specification, the board members review the specification to understand the development requirements, as described above (STEP <b>708</b>). The development review board members <b>310</b> can ask for clarification or revision of the specifications, and the product manager <b>302</b> can respond. In this way, the development review board <b>310</b> can be sure to understand the requirements for the components that they will evaluate.

[0099] In some embodiments, prior to being granted access to the design, the software developers (also called programmers) <b>314</b>, <b>314</b>′ and <b>314</b>″, generally <b>314</b>, are also pre-qualified (STEPS <b>710</b>, <b>710</b>′ and <b>710</b>″), which may be similar to that described above for the board members (e.g., ratings, etc.) or otherwise. The product manager <b>302</b>, or a member of the development review board <b>310</b> then grants those developers that meet the pre-qualification requirements access to the design. In some embodiments, access can be granted by a developer <b>314</b> entering a password, by a developer <b>314</b> navigating to a particular web page which checks the developer's qualifications, by the product manager <b>302</b> emailing the specification to the developers <b>314</b>, or other similar means. Once granted access to the specification, the developers <b>314</b> can then review the specification (STEPS <b>712</b>, <b>712</b>′ and <b>712</b>″) and begin developing software components consistent with the posted design (STEPS <b>714</b>, <b>714</b>′ and <b>714</b>″). Once a developer <b>314</b> has completed developing their software component, the developer <b>314</b> submits the component to the development review board <b>310</b> (STEPS <b>716</b>, <b>716</b>′ and <b>716</b>″).

[0100] In some embodiments, the components are subjected to a peer review process. The peer review process allows developers to test and review the components developed by other developers. For example, developer <b>314</b> may create a software component and, prior to submission, developer <b>314</b>′ may subject the component to one or more tests to determine the quality of the component. As described above, the developers <b>314</b>, <b>314</b>′ and <b>314</b>″ typically have minimal or no prior relationship to each other. In one exemplary embodiment, the developers on-line nicknames are used instead of the their actual identities. Because the components are subjected to this independent and anonymous peer review process, the quality of the submitted components will be very good.

[0101] The submitted components can take a number of forms depending on the component specified. Typically, the specifications for the component will include the requirements for the developed component. In one embodiment, the developed component includes source code, which can be written in the Java programming language, for example, using the Java 2 Micro Edition (J2ME) development platform from Sun Microsystems of Santa Clara, Calif. The component also includes unit test cases and log documenting successful execution against the test cases. The component also includes documentation. In one such embodiment, the documentation is consistent with Javadoc style documentation. The component also includes a deployment guide.

[0102] The development review board <b>310</b> reviews received components (STEP <b>718</b>). In one embodiment, this review includes a first screening review by a primary reviewer, and then further review by other members of the development review board <b>310</b>. The first screening review determines that the required elements of the design are included and are functional (e.g., source code, unit test cases, documentation, log files, and deployment guide).

[0103] The screening review can also determine that these elements appear complete. With regard to the source code, for example, the screening review can determine any or all of that: (1) all public methods are clearly commented; (2) required tags such as “@author,” “@param,” “@return,” “@throws,” and “@version” are included; (3) the copyright tag is populated; (4) the source code follows standard coding conventions for the Java language such as those published by Sun Microsystems; (5) a 4 space indentation is used in lieu of a tab indentation; and (6) all class, method and variable definitions found in the class diagram are accurately represented in the source code. The development screening review can also, for example, verify that unit test cases exist for all public methods in the design, and each unit test is properly identified by a testing program.

[0104] In one embodiment, the initial development screening process reduces the number of entries to a manageable number for the development review board <b>310</b> to review, such as five entries.

[0105] The development review board <b>310</b> evaluates the components to determine whether they comply with the design (STEP <b>720</b>). In embodiments where there is an initial screening, the members of the review board each perform a review to evaluate the submitted component.

[0106] The development reviewer evaluates the component code against the design. In one embodiment, for example, with regard to the component, the reviewer evaluates the extent to which: (1) the implementation addresses the functionality as detailed in component design documents; (2) the implementation correctly uses all required technologies (e.g. language, required components, etc.) and packages; (3) the implementation properly implements required algorithms; (4) the implementation has correctly implemented (and not modified) the public application programming interface (API) as defined in the design, with no additional public classes, methods, or variables.

[0107] With regard to class definitions, for example, the reviewer evaluates the extent to which classes are implemented as defined in the design documents (including, for example, modifiers, types, and naming conventions), and whether defined classes are implemented. With regard to variable definitions and method definitions, for example, the reviewer evaluates the extent to which all variables and methods are implemented as defined in the design documents (including, for example, modifiers, types, and naming conventions). With regard to relationships, for example, the reviewer evaluates the extent to which the implementation properly maps class relationships.

[0108] The reviewer can further evaluate the code by performing a code inspection. For example, the reviewer can determine the extent to which the object types defined in the implementation are the best choices for the intended usage—for example whether a Vector type should have been used instead of an Array type. The reviewer can determine the extent to which there are any needless loops, or careless object instantiation or variable assignment. With regard to test cases, for example, the reviewer can determine the extent to which (1) the unit test cases thoroughly test all methods and constructors; (2) the unit test cases properly make use of setup and teardown methods to configure the test environment; (3) files used in unit test cases exist in the designated directory; (4) unit test cases do not leave temporary files on the file system after testing is complete.

[0109] The reviewer can even further evaluate the code by conducting accuracy, failure, and stress tests. Accuracy tests test the accuracy of the results output when provided valid input. Accuracy tests can also validate configuration data. Failure tests test for correct failure behavior when the component is provided with invalid input, such as bad data and incorrect usage. Stress tests test the component capacity for high-volume operation, but testing such characteristics as performance as throughput. The tests that fail are included in the evaluation of the component, for example as a score reduction. Each reviewer can then assign an overall score to the component based on this evaluation.

[0110] In one embodiment, the development review board members <b>310</b> can use the server <b>104</b> of FIG. 1 to subject the design to one or more tests that target individual requirements, for example as set out in the design. Using the results of these targeted tests, members of the development review board (e.g., using the server <b>104</b>) can obtain a total score for each submission.

[0111] For example, the development review board members <b>310</b> can use the server <b>104</b> of FIG. 1 to record and communicate their evaluations of the component designs to the other board members. In one embodiment, the board member uses an on-line evaluation form to evaluate each component. The evaluations of the board members can then be identified, and the components automatically ranked by board member scores received. Based on the evaluation of the submission(s) the development review board <b>310</b> selects a design as the winning submission (STEP <b>722</b>).

[0112] In some cases, modifications may need to be made to the winning component. In these cases, the development review board <b>310</b> sends the component back to the developer <b>314</b> who submitted the winning component, along with suggestions for modifications, explicit directions to make certain modifications, or other instructions and so on. The developer <b>314</b> incorporates some or all of the changes into the component (STEP <b>724</b>) and resubmits the component to the development review board <b>310</b> (STEP <b>726</b>). The development review board <b>310</b> can then perform a final quality control review of the component (STEP <b>728</b>), and sends the component to the product manager <b>302</b>. The product manager <b>302</b> can then include the component in a component catalog, as described below, and make the component available for distribution (STEP <b>730</b>). The product manager <b>302</b> can also pay the winning developer <b>314</b>, using any one of the methods described below (STEP <b>732</b>).

[0113] Referring to FIG. 8, the server <b>104</b> can include a number of modules to facilitate the development and/or distinction of components. For example, a component development subsystem <b>800</b> can facilitate the development process described above. The component development subsystem <b>800</b> facilitates the development of a component with the development team <b>200</b> and communicates with many different modules to achieve the distributed team development process.

[0114] In one embodiment and as described in more detail below, the server <b>104</b> can include a component catalog <b>804</b>. The component catalog <b>804</b> stores components developed by the development team <b>200</b>. In one embodiment, the component catalog <b>804</b> provides a catalog or directory of information about components available to potential purchasers. For instance, a customer of the server <b>104</b> can view a directory of the component catalog <b>804</b> and information about each component in the component catalog <b>804</b> before selecting a particular component. Once the server <b>104</b> (or administrator of the component catalog <b>804</b>) receives the required fee payment or authorization information for the component, the server <b>104</b> downloads the component to the client <b>108</b> over the communications network <b>112</b>. The component catalog is described further with reference to FIG. 10 below.

[0115] The server <b>104</b> also includes communication tools <b>808</b>. In one embodiment, the communication tools <b>808</b> are tools that facilitate communication between the team members <b>204</b>, <b>208</b>, <b>212</b>, <b>216</b> of the development team <b>200</b>. Examples of the communication tools <b>808</b> include, but are not limited to, a module enabling the real-time communication between team members <b>204</b>, <b>208</b>, <b>212</b>, <b>216</b> (e.g., chat), news groups, on-line meetings, and document collaboration tools.

[0116] Moreover, the server <b>104</b> can also include a component incubator <b>812</b>. The component incubator <b>812</b> is a module enabling users to submit suggestions for components or modifications to components which can then be used as the basis for market research.

[0117] The server <b>104</b> can include a requirements design subsystem <b>816</b>. The requirements design subsystem <b>816</b> enables the product manager <b>204</b> and architect <b>208</b> to view and comment on the requirements specification. In further embodiments, the requirements design subsystem <b>816</b> enables the product manager <b>204</b> and the architect <b>208</b> to create, edit, download, upload, and/or approve requirements in the specification (e.g., over the communications network <b>112</b>). In one embodiment, the requirements design system can share and manipulate models in UML.

[0118] The server <b>104</b> additionally includes a development posting subsystem <b>820</b>. The development posting subsystem <b>820</b> enables the server <b>104</b> or product manager <b>204</b> to communicate with potential development team members to promote development projects and grow a community of contributors that contribute to the component catalog. In one embodiment, the development posting subsystem <b>820</b> displays an advertisement to potential development team members. In one embodiment, the advertisement describes the project using text, graphics, video, and/or sounds. The advertisement may also describe positions available in the development team <b>200</b>. Examples of communication techniques include, without limitation, posting these ads on the server's web site, displaying statistics about the project (e.g., planned royalties paid to development team members, development team members who are participating in this project, development hours available per week). Moreover, in one embodiment the development posting subsystem <b>820</b> accepts inquiries associated with development projects. In further embodiments, the development posting subsystem <b>820</b> suggests members of the competition member base to form a development team to handle an inquiry. The development posting subsystem <b>820</b> may analyze, for example, the rating of each member of the coding competition member base, previous contributions to previous development projects, the quality of contributions to previous component development projects (e.g., based on a score given to each development team member <b>204</b>, <b>208</b>, <b>212</b>, <b>216</b> at the completion of the component, as discussed above), and current availability of the potential team member when recommending a member of the competition member base to be part of the development team <b>200</b>. The product manager <b>204</b> may or may not be an advertised position as just described.

[0119] The server <b>104</b> also includes a management subsystem <b>824</b>. The management subsystem <b>824</b> is a module that allocates revenue to a development team member (e.g., developer <b>212</b>, QA developer <b>216</b>). In one embodiment, a development team member earns an ongoing royalty on component licenses or sales of copies of the component. In further embodiments, the management subsystem <b>824</b> enables the product manager <b>204</b> and architect <b>208</b> to view inquiries for projects and select project teams based on a recommendation from the server <b>104</b> (i.e., the development posting subsystem <b>820</b>). The management subsystem <b>824</b> can also track deliverables produced by the development team <b>200</b> (e.g., source code, documentation, and schema) and/or enable the review of development team members <b>204</b>, <b>208</b>, <b>212</b>, <b>216</b> after the development of the component. The management subsystem <b>824</b> can also scan development team member information, such as, but not limited to, history, coding competition ranking, and prior work experience. In some embodiments, the management subsystem <b>824</b> can display the development team member information to the product manager <b>204</b> and/or architect <b>208</b> via, for instance, a graphical user interface.

[0120] The server <b>104</b> also includes a software design subsystem <b>828</b>. The software design subsystem <b>828</b> enables collaboration between the team members <b>204</b>, <b>208</b>, <b>212</b>, <b>216</b>. More specifically and in one embodiment, the software design subsystem <b>828</b> enables team members <b>204</b>, <b>208</b>, <b>212</b>, <b>216</b> to view and/or comment on the design documents, such as object diagrams (e.g., class diagrams and use-case diagrams, and so on.). In another embodiment, the software design subsystem <b>828</b> enables development team members <b>204</b>, <b>208</b>, <b>212</b>, <b>216</b> to create, download, upload, and/or edit the design documents and/or the architecture documents over the communications network <b>112</b>.

[0121] Moreover, the server also includes a component development environment (CDE) <b>832</b>. The CDE <b>832</b> enables team members <b>204</b>, <b>208</b>, <b>212</b>, <b>216</b> and potential purchasers of the components to create applications by linking components together. In one embodiment, the CDE <b>832</b> is a web-based application (e.g., applet or plug-in application). In additional embodiments, the CDE <b>832</b> is included in the client software <b>120</b>. The CDE <b>832</b> also enables the transition of a component from a QA application which tests the component, as described below, into the integration module, also described below, to create larger components or applications. The CDE <b>832</b> also enables the migration of standalone components from QA to production and/or the migration of an application or larger component to production. The CDE <b>832</b> may additionally incorporate commercially available Integrated Development Environment (IDE) software.

[0122] The server <b>104</b> additionally includes a quality assurance (QA) application <b>836</b>. The QA application <b>836</b> enables the testing of all applications and/or components. In one embodiment, the QA application <b>836</b> executes test cases developed by the QA developer <b>216</b>. Moreover, the QA application <b>836</b> may execute an automated test on the component or application, such as to verify and/or measure memory usage, thread usage, machine statistics such as I/O usage and processor load. Additionally, the QA application <b>836</b> can score the component by performance, design, and/or functionality. Moreover, the QA application <b>836</b> can be a test harness for testing multiple components simultaneously.

[0123] In one embodiment, the server <b>104</b> can include a packaging application <b>840</b>. The packaging application <b>840</b> packages deliverables (e.g., source files, executables, documentation, and/or supporting material (e.g., XML, DDL)) in a downloadable file (e.g., .ZIP file, Java Archive (.JAR file), or dynamic link library (.DLL) file). In one embodiment, the packaging application <b>840</b> packages these deliverables into a downloadable file when a customer purchases a component from the component catalog. The packaging application <b>840</b> then downloads the file to the client <b>108</b>.

[0124] The server <b>104</b> also includes a component showroom <b>844</b>. The component showroom <b>844</b> promotes the license (and/or sales of copies) and usage of the components by providing information about the component. The component showroom <b>844</b> can also provide the ability to, for instance but not limited to, demonstrate component usage, demonstrate a case study, provide a list of related components and applications, and provide information about pricing and/or licensing.

[0125] Although described above as independent subsystems and modules, this is for exemplary purposes only and these subsystems and modules may alternatively be combined into one or more modules or subsystems. For example, in another embodiment, the component development module <b>800</b> can perform any number of the functions described above. Moreover, one or more of the subsystems described above may be remotely located from other modules (e.g., executing on another server <b>104</b> in a server farm).

[0126] Referring to FIG. 9, the development posting subsystem <b>820</b> includes a web server <b>902</b>. The product manager <b>204</b> can use the web server <b>902</b> to post design or specifications for distribution to the software team <b>200</b>. The server <b>104</b> also includes a rating engine <b>904</b>. In one embodiment, the rating engine <b>904</b> calculates ratings for each participant in one or more coding competitions. In other embodiments, the rating engine can calculate ratings for members of project teams <b>200</b> based on the individual members' contributions to the project. The server <b>104</b> also includes a receiving module <b>906</b>. In one embodiment, the receiving module <b>906</b> receives computer software designs submitted to the development posting subsystem <b>820</b> by members of the project team <b>200</b>. Alternatively, the receiving module <b>906</b> facilitates the receipt of submissions from developers <b>212</b> competing for spots on the development team <b>200</b>. The server <b>104</b> also includes a scoring module <b>908</b>. In one embodiment, the architecture review board <b>304</b> uses the scoring module <b>908</b> to evaluate multiple software designs submitted by the software designers <b>308</b>. Additionally, the development review board <b>310</b> can use the scoring module <b>908</b> to evaluate multiple software components submitted by the programmers <b>314</b>. The server also includes a reviewing module <b>910</b>. Additionally, developers can use the reviewing module <b>910</b> to review submissions from other developers. In one embodiment, the web server <b>902</b>, rating engine <b>904</b>, receiving module <b>906</b>, scoring module <b>908</b>, and reviewing module reside on the server <b>104</b>. Alternatively, the web server <b>902</b>, rating engine <b>904</b>, receiving module <b>906</b>, scoring module <b>908</b>, and reviewing module <b>910</b> can reside on other servers or remote devices.

[0127] Referring to FIG. 10, the component catalog <b>804</b> includes a component repository <b>1004</b>. The component repository <b>1004</b> is a central store for components that the server <b>104</b> can publicize and sell to purchasers. In one embodiment, the component catalog <b>804</b> is stored on the server <b>104</b>. Alternatively, the component catalog <b>804</b> can be stored on another server or remote storage device (e.g., database server). In some embodiments, the component repository <b>1004</b> provides the user interface to potential purchasers wishing to purchase a component or its information. Typically, the user interface generates code for the client software <b>120</b> or web browser <b>116</b> used by purchasers to communicate with the server <b>104</b>.

[0128] The component catalog <b>804</b> additionally includes an information module <b>1008</b>. The information module <b>1008</b> provides information about the components to the component repository <b>1004</b>. For instance, the information module <b>1008</b> can provide or include a table listing supported components of the server <b>104</b> that are stored in the component repository <b>1004</b>. Moreover, the information module <b>1008</b> can also provide documentation for each component to the component repository <b>1004</b>, such as, but not limited to, the component's memory requirements, efficiency, score received in QA testing, and members of the development team <b>200</b>. In one embodiment, the information module <b>1008</b> is in communication with the component repository <b>1004</b> to provide the component information to the component repository <b>1004</b> so that, for example, a potential purchaser can view a component's information (e.g., performance) during selection.

[0129] The component catalog <b>804</b> also includes an update tracking module <b>1012</b>. The update tracking module <b>1012</b> ensures that the component repository contains the most recent version of a component. In one embodiment, upon the determination of a modification to a component previously purchased by a customer, the component catalog <b>804</b> receives the change. The update tracking module <b>1012</b> ensures that the modified component is stored in the component repository <b>1004</b>. In some embodiments, the update tracking module <b>1012</b> alerts the product manager <b>204</b> or architect <b>208</b> of the modification. In yet other embodiments, the update tracking module <b>1012</b> transmits only the modified portion of the component to the component repository <b>1004</b> for more efficient updates. In further embodiments, if a component is modified, the update tracking module <b>1012</b> transmits a message to all customers who had previously purchased the previous version of the component to notify the customers that a newer version is available and the differences between this version and the previous version.

[0130] The component catalog <b>804</b> additionally includes a dependency tracking module <b>1016</b>. The dependency tracking module <b>1016</b> tracks the dependencies between components that are linked together in an application. For example, a component purchaser purchases a component A from the server <b>104</b>. Component A is a larger component made up of components B, C, and D. If component C is subsequently modified, in one embodiment the server <b>104</b> notifies the purchaser that component C has been modified and component C depends off of component A. The purchaser, however, is interested in component A. If the purchaser only updates component C, then the purchaser's component A may not operate unless the purchaser downloads the updated component B and D. The dependency tracking module <b>1016</b> is the module that tracks such dependencies. In some embodiments, the dependency tracking module <b>1016</b> notifies customers about dependencies.

[0131] The component catalog <b>804</b> also includes an integration module <b>1020</b>. In one embodiment, the integration module <b>1020</b> integrates components in the component catalog <b>804</b> to form larger components or applications. For instance, the product manager <b>204</b> can determine that a need exists for a particular component A. If the product manager <b>204</b> realizes that no component A exists in the component catalog <b>204</b> but does realize that other components exist that may be able to create component A using other components, the product manager <b>204</b> can plan a project for the creation of the component A. In one embodiment, the integration module <b>1020</b> facilitates the integration of many components into one larger component.

[0132] For example and referring to FIG. 11, a component catalog system <b>1100</b> includes a first company <b>1104</b> operating the first client <b>108</b> and a second company <b>1108</b> operating the second client <b>108</b>′. The companies <b>1104</b>, <b>1108</b> communicate with the server <b>104</b> over the communications network <b>112</b>. The server <b>104</b> includes the component catalog <b>804</b> and the component catalog <b>804</b> includes the update tracking module <b>1012</b>. Although not illustrated, each client <b>108</b>, <b>108</b>′ includes the respective web browser <b>116</b>, <b>116</b>′, the server <b>104</b> includes the modules (e.g., component showroom <b>844</b>) described above in FIG. 8, and the component catalog <b>804</b> includes the modules (e.g., the information module <b>1008</b>) described above in FIG. 10.

[0133] In one embodiment, the server <b>104</b> transmits a remote upload tracking module <b>1112</b>, <b>1112</b>′, generally <b>1112</b>, to the first and second companies <b>1104</b>, <b>1108</b>, respectively. Each remote upload tracking module <b>1112</b> communicates with the upload tracking module <b>1012</b> when a company <b>1104</b>, <b>1108</b> modifies a component that is stored in the component catalog <b>804</b>. Additionally, the remote upload tracking module <b>1112</b> also enables a company (e.g., <b>1104</b>, <b>1108</b>) to add their components to the component catalog <b>804</b>, thereby making the component available to other companies. In some embodiments, the remote upload tracking module <b>1112</b> may be implemented in various forms, for example, it may be in the form of a Java applet that is downloaded to the client <b>108</b> and runs in conjunction with the web browser <b>116</b> and/or client software <b>120</b>, or the remote upload tracking module <b>1112</b> may be in the form of a standalone application, implemented in a multi-platform language such as Java or in native processor executable code. Further, the remote upload tracking module <b>1112</b> may be implemented as the client software <b>120</b>.

[0134] In one embodiment, the first company <b>1104</b> produces a first version of a component <b>1116</b>. In one embodiment, the remote upload tracking module <b>1112</b> then automatically transmits the component <b>1116</b> to the server <b>104</b> (e.g., the upload tracking module <b>1012</b>) over the communications network <b>112</b> for addition into the component catalog <b>804</b>. Alternatively, the remote upload tracking module <b>1112</b> queries the first company <b>1108</b> (e.g., an employee of the first company <b>1104</b>) if the first company <b>1108</b> wants to submit the component to the component catalog <b>804</b> and consequently make the component available to other companies (e.g., the second company <b>1108</b>). For instance, the remote upload tracking module <b>1112</b> queries the first company <b>1104</b> via a dialog box (e.g., displayed on the web browser <b>116</b> or client software <b>120</b>). If the first company <b>1104</b> agrees to the query (e.g., selects YES from a dialog of adding the component <b>1116</b> to the component catalog <b>804</b>), the remote update tracking module <b>1112</b> transmits the component <b>1116</b> to the server <b>104</b>, as illustrated with arrow <b>1120</b>. In one embodiment, the remote upload tracking module <b>1112</b> has an option (e.g., checkbox) to transmit completed components to the server <b>104</b>. Once the option is selected, the remote upload tracking module <b>1112</b> does not query the first company <b>1104</b> but rather automatically transmits the completed component to the server <b>104</b> and does so until the option is unselected. Additionally, although tailored towards the first company <b>1104</b>, the description also applies to the second company <b>1108</b>. In another embodiment, other functions, such as royalty negotiation, effort determination, and so on, may take place before a third party component is added to the component catalog <b>804</b>.

[0135] In one embodiment, the uploaded components undergo a QA process as described herein before addition to the component catalog <b>804</b>. In one embodiment, upon receiving the first version of the component <b>1116</b>, the server <b>104</b> subjects the component <b>1116</b> to one or more of the steps described above in FIG. 4. For example, the server <b>104</b> does not add the component <b>1116</b> into the component catalog <b>804</b> without performing the QA testing on the component (STEP <b>428</b>). In additional embodiments, the server <b>104</b> does not add the component <b>1116</b> to the component catalog <b>804</b> until the architect <b>208</b> provides the final approval to the product manager <b>204</b>. Thus, if version 1 of the component <b>1116</b> does not meet the stringent coding standard requirements of the architect <b>208</b> (and/or product manager <b>204</b>), the component <b>1116</b> is not added to the component catalog <b>408</b>. In further embodiments, the server <b>104</b> notifies the first company <b>1104</b> that the component <b>1116</b> did not meet the required standards for entry into the component catalog <b>804</b>. The server <b>104</b> can additionally provide the first company <b>1104</b> with the problems found in the component <b>1116</b>.

[0136] If the component <b>1116</b> does meet the server's requirements and is consequently added to the component catalog <b>804</b>, the server <b>104</b> can then display the component <b>1116</b> in the component catalog <b>804</b> for potential purchase. Thus, if a second company <b>1108</b> views the component catalog <b>804</b> (e.g., via the component showroom <b>844</b>), the second company <b>1108</b> can purchase version 1 of the component <b>1116</b>. After the sale, the server <b>104</b> subsequently transmits the component <b>1116</b> to the second company <b>1108</b>, illustrated with arrow <b>1124</b>. In one embodiment, the first company <b>1104</b> may be compensated for any sale of version 1 of the component.

[0137] Referring to FIG. 12, in one embodiment the second company <b>1108</b> purchases version 1 of the component and subsequently modifies the component <b>1116</b>, shown with modification arrow <b>1128</b>. A modification is, for example, an improvement (e.g., efficiency increase, smaller memory requirements), deletion (e.g., of an unneeded step or feature), and an addition (e.g., of a complimentary feature or function) to the component <b>1116</b>. Another example of a modification is the integration of the component <b>1116</b> into another component (e.g., a larger component). In response to the modification, version 1 of the component <b>1116</b> becomes, for example, version 1.1 of the component <b>1116</b>′. In one embodiment, the remote update tracking module <b>1112</b> transmits a message to the server <b>104</b> stating that the second company <b>1108</b> has modified the component <b>1116</b>. In further embodiments, the remote update tracking module <b>1112</b> then transmits (or, e.g., queries and transmits) the modified version 1.1 to the server <b>104</b>, as shown with arrow <b>1132</b>. Upon receipt of version 1.1 of the component <b>1116</b>′, the server <b>104</b> and/or development team members determine whether the modified component <b>1116</b>′ can be added to the component catalog <b>804</b> by performing the steps illustrated in FIG. 4. In one embodiment, when version 1.1 of the component <b>1116</b>′ is added to the component catalog <b>804</b>, version 1.1 replaces version 1 of the component <b>1116</b>. Alternatively, version 1.1 of the component <b>1116</b>′ is added as another component in the component catalog <b>804</b>. The replacement or addition of version 1.1 of the component <b>1116</b>′ may depend on the amount of changes relative to version 1 of the component. Furthermore, the update tracking module <b>1012</b> may notify each customer who previously purchased version 1 of the component <b>1116</b> that an updated version 1.1 has been added to the component catalog <b>804</b>. The other modules <b>1008</b>, <b>1016</b>, <b>1020</b> may also notify customers about, for example, additional dependencies and available information. Additionally, in some embodiments the second company <b>1108</b> is compensated for licenses/sales of copies of the second version of the component <b>1116</b>′.

[0138] In one embodiment, members of a development team (e.g. <b>208</b>, <b>212</b>, <b>216</b>) working on a software product (e.g. a component or a software application) are paid a fee for their work on the product. Although preferably a software component, the product that is developed by the distributed software development system <b>101</b> can be any software application or type of intellectual property. In one embodiment and as described above with respect to FIG. 8, the development posting subsystem <b>820</b> of the server <b>104</b> posts project listings and descriptions of the projects in the project listings, such as in an advertisement. The advertisement or posting can include, for instance, the contribution of each development team member, the fee that a development team member receives for work on the project, and the total contribution of the entire development team.

[0139] In one embodiment, the members of a development team receive a royalty based on their contribution to the product and the revenue earned from licenses or sales of copies of the product. The management subsystem <b>824</b> (also described above with respect to FIG. 8) of the server <b>104</b> tracks particular characteristics for determining the royalty amounts to be paid to the members of the development team. In one such embodiment, the fee is an advance payment on royalties, meaning that royalties are not paid until the advance is covered.

[0140] In one embodiment and also referring to FIG. 13, the server <b>104</b> (e.g., the management subsystem <b>824</b>) tracks the total revenue <b>1304</b>, development team member contribution <b>1308</b>, development team member royalty percentage <b>1310</b>, royalty pool percentage <b>1311</b>, royalty pool <b>1312</b>, and royalty <b>1316</b> for the project and/or for each development team member.

[0141] In one embodiment, the contribution <b>1308</b> is a predetermined amount that is specified in advance of the development work. In another embodiment, the contribution <b>1308</b> of each member is determined by the amount of time, level of skill (determined by previous scores, contest rating, experience or a combination), or degree of effort made by the development team member. In another embodiment, the contribution <b>1308</b> is determined by the usefulness of the development team member's contribution. The expected proportional contribution of a development team member (e.g., <b>208</b>, <b>212</b>, <b>216</b>) is the development team member's royalty percentage <b>1310</b>. In one embodiment, the development team member's royalty percentage <b>1310</b> is determined by dividing the total work contribution <b>1308</b> that is expected to be required by the development team member to accomplish her task by the total work contribution that is expected to be required by all of the development team members to develop the deliverables (e.g., the component and related documentation). In the event that the component is changed, upgraded or otherwise modified, an adjustment may be made to the development team member's royalty percentage <b>1310</b> for that modified version, to reflect the new contribution division.

[0142] In one embodiment, a royalty pool percentage <b>1311</b> is selected for a product. The royalty pool percentage <b>1311</b> is a percentage of total revenues <b>1304</b> (e.g. yearly, quarterly, or monthly revenue) to be reserved for royalty payments <b>1316</b> to be made to the development team who worked on the product. In one embodiment, the anticipated royalty pool percentage <b>1311</b> for each product is set forth in the applicable specification document. In some embodiments, the royalty pool percentage <b>1311</b> may depend on other business factors, such as time or popularity of a product. The royalty pool <b>1312</b> is then the portion of revenues <b>1304</b> from a product that is to be distributed as royalty payments <b>1316</b> to the members of the development team who developed the product. In one embodiment, the royalty pool <b>1312</b> is determined by multiplying the royalty pool percentage <b>1311</b> by the total revenues <b>1304</b> received from sales or licenses of the product during a predetermined time period.

[0143] The management subsystem <b>824</b> tracks the information in the data structure <b>1324</b>. In one embodiment, there are a plethora of products that are stored in the component catalog <b>804</b>. Moreover, the number of people who have contributed or are contributing to one or more projects can be substantial. To track the information used to accurately determine compensation for each development team member's contribution <b>1308</b> to products, the management subsystem <b>824</b> of the server <b>104</b> is employed.

[0144] In some embodiments, the server <b>104</b> tracks and stores a sliding scale royalty <b>1320</b>, which is based on a selection that a development team member can make that determines the amount of initial compensation paid to the team member (e.g., set fee) upon their agreeing to work on the project. The sliding scale royalty <b>1320</b> is described in more detail below with respect to FIG. 16. In one embodiment, the management subsystem <b>824</b> stores this information <b>1304</b>, <b>1308</b>, <b>1312</b>, <b>1316</b>, <b>1320</b> in a compensation data structure <b>1324</b>. The data structure <b>1324</b> may be stored, for instance, in the server's memory, in an external memory, and/or in a persistent storage.

[0145] For example and referring to FIG. 14, a royalty compensation table <b>1400</b> includes three development team members <b>1404</b>, Member1, Member2, and Member3 that are contributors on a development team. For example, Member1 could be an architect <b>208</b>, Member2 could be a developer <b>212</b>, and Member3 could be a quality assurance (QA) developer <b>216</b>. In this embodiment, the contribution <b>1308</b> of Member1 is 100 hours, the contribution <b>1308</b> of Member2 is 200 hours, and the contribution <b>1308</b> of Member3 is 300 hours. In this example, the contribution <b>1308</b> for each member (e.g., Member1, Member 2, Member3) can be determined by the expected number of hours required for each member (as determined by the product manager <b>204</b>). In other embodiments, the contribution <b>1308</b> can be determined by, for instance, the actual number of hours spent, the actual amount of model or code designed written, or tested, and so on.

[0146] In this example, the total amount <b>1410</b> of contribution <b>1308</b> by the development team is 600 hours. The development team member royalty percentage <b>1310</b> is the contribution <b>1308</b> of each member divided by the total contribution. In this example, the total contribution is (100+200+300)=600 hours. The development team member royalty percentage <b>1310</b> is, then, for Member1 (100/600)=17%; for Member2 (200/600)=33%; and for Member3 (300/600)=50%.

[0147] In this example, the total revenue <b>1304</b> is $20,000. The royalty pool percentage <b>1311</b> for this product is 5%. The royalty pool <b>1312</b> is therefore ($20,000×5%=) $1,000. Thus, the royalty <b>1316</b> earned by each development team member <b>1404</b> is their royalty percentage <b>1310</b> of the royalty pool <b>1312</b>. Specifically, Member1 receives ($1,000×17%=) $170, Member2 receives ($1,000×33%=) $330, and Member3 receives ($1000×50%=) $500. In some embodiments, these royalty payments <b>1324</b> would be made in a similar manner as additional revenue for the product is received.

[0148] Referring to FIG. 15, in a continuing example, the product produced by the three team members <b>1404</b> is modified and updated into another version. The new version could be version 1.1 of the component <b>1116</b> described in FIG. 11 or integrated into another product. The additional work is performed by team members <b>1504</b> (e.g., Member4 and Member5) and also by Member3, but not Member2 and Member1. The royalties are adjusted to include the new development team members' contributions into the determination of the royalty <b>1316</b>. In this example, the contribution of Member4 is 50 hours and the contribution of Member5 is also 50 hours. Thus, with the contribution of the two additional members <b>1504</b>, the total <b>1410</b> of the amount of contribution increases to 750 hours. The development team member royalty percentage <b>1310</b> is the contribution of each member (e.g., Member1, Member2, Member3, Member4, Member5) divided by the total contribution.

[0149] The development team member royalty percentage <b>1310</b> is, then, for Member1 (100/750)=13.33%; for Member2 (200/750)=26.66%; for Member3 (350/750)=46.66%; for Member4 (50/750)=6.66%, and for Member5 (50/750)=6.66%.

[0150] Further, in this example, the total revenue <b>1304</b> generated for the modified product is $30,000. The royalty pool percentage <b>1311</b> for this product is 5%. The royalty pool <b>1312</b> is therefore ($30,000×5%=) $1500. Each of the development team members <b>1508</b> receives their royalty percentage <b>1310</b> of the royalty pool <b>1312</b>: Member1 receives ($1500×13.33%=) $200. Member2 receives ($1500×26.66%=) $400. Member3 receives ($1500×46.66%=) $700, which is higher than the previous royalty <b>1316</b> that Member3 had previously received before Member3's additional contribution <b>1308</b>. In some embodiments, these royalty payments <b>1316</b> would be made in a similar manner as additional revenue for the product is received.

[0151] Also referring to FIG. 16, in some embodiments the development team members can adjust the amount of revenue that they receive (as royalties <b>1316</b>) by adjusting their sliding scale royalty <b>1320</b>. Specifically, the server <b>104</b> (e.g., the product manager <b>204</b>) can implement a sliding scale <b>1606</b> that enables a team member to choose the amount of a set fee <b>1608</b> and development team member royalty percentage <b>1310</b> such that the development team member can accept more or less risk of the success of the product. An increased fee <b>1608</b> will result in a decreased royalty and vice-versa, and, therefore, reduces the received royalties <b>1316</b>. Thus, the amount of the fee <b>1608</b> that the team member chooses corresponds with a royalty selection <b>1612</b>. The endpoints of the sliding scale <b>1606</b> are the maximum values of the set fee <b>1608</b> and the development team member royalty percentage <b>1310</b> that the team member can receive for their contribution <b>1308</b> to the project. In the sliding scale <b>1606</b> shown, the values of the set fee <b>1608</b> are represented on the top half of the sliding scale <b>1606</b> and the development team member royalty percentages <b>1310</b> are represented on the bottom half of the sliding scale <b>1606</b>. In one embodiment, when a fee is requested, the royalty potential of the team member is adjusted due to the choice of the set fee. To determine the sliding scale royalty <b>1320</b>, which would replace the royalty <b>1316</b> received by the team member, the server <b>104</b> multiples the development team member royalty percentage <b>1310</b> of the team member with the royalty pool <b>1312</b> and with the royalty selection <b>1612</b> made by the team member. Thus, the sliding scale royalty <b>1320</b> would be the total revenue <b>1304</b> multiplied by the royalty pool percentage <b>1311</b> multiplied by the development team member royalty percentage <b>1310</b> multiplied by the royalty selection percentage <b>1612</b>.

[0152] Using the example illustrated in FIG. 16 with respect to Member2, Member3, and Member 5 of FIG. 15, if Member2 chooses to receive 100% of his compensation in a set fee <b>1608</b>, then Member2 will receive 0% of the royalties otherwise applicable. Thus, Member2 has a new sliding scale royalty <b>1320</b>, which replaces the royalty <b>1316</b> shown in FIG. 15, of (26.66%*1500*0%=) zero, as Member2 chose all of his royalties as a set fee <b>1608</b>.

[0153] In this example, Member3 chooses a maximum royalty selection <b>1612</b> (e.g., 100%). Consequently, Member3's sliding scale royalty <b>1320</b> is (46.66%*1500*00%=) $700. In another embodiment, Member5 chooses to receive 50% of the possible fee <b>1608</b> and 50% royalty <b>1316</b>. Thus, Member5's sliding scale royalty <b>1320</b> is (6.66%*1500*50%=) $50.

[0154] In one embodiment, the amount of the set fee <b>1608</b> directly relates to the reduction in the development team member royalty percentage <b>1310</b>. Thus, a 20% increase in the set fee <b>1608</b> consequently reduces the development team member royalty percentage <b>1310</b> by 20%. In other embodiments, the change in set fee <b>1608</b> is not directly related to the change in the development team member royalty percentage <b>1310</b>. For example, the server <b>104</b> may multiply a constant times the increase in the fee <b>1608</b> to make even a slight increase in the fee <b>1608</b> correspond to a large increase in the development team member royalty percentage <b>1310</b> adjusted for the expected risk. Alternatively, the server <b>104</b> may assign a constant which applies an inverse relationship to the change in the development team member royalty percentage <b>1310</b> from a change in the set fee <b>1608</b>. Moreover, any relationship can exist between the set fee <b>1608</b> and the development team member royalty percentage <b>1310</b>. Thus, the server <b>104</b> can apply one or more mathematical functions to determine the change in one variable with respect to a change in the other variable.

[0155] In one embodiment, the development team member royalty percentage <b>1310</b> and royalty pool percentage <b>1311</b> (e.g., 5% in previous two examples) may differ for each applicable product and each are subject to upward or downward adjustment by the server <b>104</b> at any time. In further embodiments, the product manager <b>204</b> and/or the architect <b>208</b> can vary these percentages <b>1310</b>, <b>1311</b>.

[0156] Furthermore, in one embodiment, revenue can be measured before expenses (e.g., gross revenue). In another embodiment, revenue can be determined after expenses (e.g., net revenue, commissions, etc.).

[0157] In one exemplary embodiment, the distributed software development system <b>101</b> is employed in the bio-technology industry. A first bio-tech company develops a new set of molecules, referred to below as set A, B, and C, and believes that one or more of the molecules can be effective against a particular disease, referred to below as disease X. However, the bio-tech company does not have the protein data that is used to determine if molecule A, B, and/or C are effective against disease X. In one embodiment, the product manager <b>204</b> researches the industry and, subsequently, a development team adds a software component that models the characteristics of each molecule into the component catalog <b>804</b>. In some embodiments, the development team also creates one or more components that model diseases, such as disease X. The bio-tech company may view the components in the component catalog <b>804</b> and determine to use one or more of the components to, for example, model molecular interactions and determine the effectiveness of a molecule on a particular disease. In some embodiments, the server <b>104</b> produces components that provide a data warehouse for data about a particular gene or molecule. In one embodiment, the bio-tech company uses a component to read data out of a bio-tech machine that reads data of cells and/or genes. The component can also store the data read out of a bio-tech machine.

[0158] In general, in one aspect, the invention relates to a method for determining a royalty for a first contributor to a cooperatively developed product that is developed by the first contributor and at least one other contributor. The Method includes receiving a value indicative of the contribution made by each of the first contributor and each of the at least one other contributor to the cooperatively developed product. The method includes calculating the total contribution made by the contributor and the at least one other contributor by summing the received values. The method includes determining a developer royalty percentage for the first developer based on the ratio of the determined first contributor's contribution value to the calculated total contribution. The method includes allocating a royalty pool for the cooperatively developed product out of revenue received for the cooperatively developed product; and determining a royalty amount for the first contributor by multiplying the royalty pool by the developer royalty percentage.

[0159] In one embodiment, allocating a royalty pool includes specifying a royalty pool percentage for the cooperatively developed product, and multiplying revenue received for the cooperatively developed product by the royalty pool percentage. In various embodiments, the revenue received can be the revenue before or the revenue after deducting expenses.

[0160] Although described here with reference to software, and useful when implemented with regard to software components, the cooperatively developed product can be any sort of tangible or intangible object that embodies intellectual property. In one embodiment, the product includes at least one computer software component. In one such embodiment, the product includes a computer application program made up of at least one computer software component. In other embodiments, the product includes at least one of an integrated circuit design and a computer hardware device. In one embodiment, the contribution is at least one of product management, design, architecture, coding, and quality assurance testing.

[0161] In one embodiment, the receiving step comprises receiving from at least one of a system administrator, keyboard input, or a data store (e.g. hard disk, memory), and a software object. In one embodiment, the method is performed by a computer in response at least in part to input of contributor contribution values for the cooperatively developed work. In one embodiment, the value indicative of contribution is a predetermined value based on estimates of work required for a specified contribution. In another embodiment, the value indicative of contribution is based on measuring actual contribution. (e.g. lines of code, hours spent). In various embodiments, the steps of the method can be used for follow-on or modified products that include the contribution of additional contributors. In such a case, the value indicative of contribution can be either the contribution to the original product or the contribution to the follow-on or modified product.

[0162] In general, in another aspect, the invention relates to a system that can perform the method steps for many contributors and many products. The system is able, using the information and techniques and described herein, to track the information associated with these products and developers to allocate revenue as royalties for the contributors. In general, in another aspect, the invention relates to a system for facilitating distributed component development, including a component catalog, a distributed development environment, and a royalty calculation system.

[0163] In general, in another aspect the invention relates to a component catalog system that includes local component storage for storing components and information about the components, an user interface module for providing information about components, an update tracking module for tracking updates made to the components, a dependency tracking module for tracking component dependencies, and an integration module for identifying components that can be integrated. In one embodiment, the system further comprises a remote module for providing information about components stored on a remote system, and making the components available to users of the component catalog as if they were contained in the local component storage.