Using Peer-to-Peer Technology to Support Global Software Development – Some Initial Thoughts
Bibliographic record
Abstract
Distributed software development typically uses a centralized architecture, which has some drawbacks such as, the participants may experience lengthy delays if they are located far from the central server, and the organization that runs the server must deal with the security and privacy issues that come with being in charge of a central repository of information. We are investigating whether this centralized control can be relaxed by using peer-topeer (P2P) technology. Adopting a P2P architecture includes some of the following benefits for software development: (1) the peer (or group) is able to have complete control of its information, (2) groups can share and duplicate information to help users with slow network connections, and (3) users can easily contribute their own resources to the project, such as hard drive space. The P2P architecture also has potential drawbacks, including the need for complex search and retrieval algorithms, and having to coordinate the synchronization of duplicated stores of data. The objectives of our research are threefold: (1) to examine the design issues related to the development of a P2P software development application, (2) to alter an existing virtual software development application (MILOS) from a client-server to a P2P application using the Sun JXTA framework, and (3) to present empirical evidence on the value of the P2P implementation based on data gathered during the development process, and during application use (i.e., delays when searching and retrieving information).
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
How this classification was reachedexpand
Full frame machine prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. The Gemma side is a direct model label for every work in the frame, read from the title-only record. The Codex side is a classifier learned from the 10,348 direct Codex labels and calibrated to design-weighted sample rates; fields without enough sample support carry no Codex call. Candidate is the union of the two sides; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels.
Distilled classifier scores by category (both heads)
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.010 | 0.010 |
| Meta-epidemiology (narrow) | 0.001 | 0.001 |
| Meta-epidemiology (broad) | 0.000 | 0.000 |
| Bibliometrics | 0.001 | 0.002 |
| Science and technology studies | 0.002 | 0.004 |
| Scholarly communication | 0.006 | 0.015 |
| Open science | 0.002 | 0.002 |
| Research integrity | 0.003 | 0.003 |
| Insufficient payload (model declined to judge) | 0.005 | 0.002 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from itClassification
machine, unvalidatedMachine predicted; a candidate call from one source (direct Gemma or distilled Codex), not a consensus.
How this classification was reached, model by model and score by score, is at the end of the page under "How this classification was reached".