Figure 1
Open community software supports scientific applications, cyberinfrastructure research, and operations.
Table 1
Possible outcomes from patch submissions and pull requests that reflect the health of project governance.
| Scenario | Outcome |
|---|---|
| A willing volunteer dives into the project but cannot see how to get started submitting a patch for anything. | The project is not well documented, is not modularly designed, has a broken build and test system, is not using issue tracking systems, has no easy way to communicate with developers directly, etc. |
| The volunteer creates a patch but then does not know what to do with it. | The project does not have a way to accept patches (by Jira issue, through a developer mailing list, etc). |
| A volunteer submits a patch, but it is ignored. | The project does not actually want contributions; the project members are unaccustomed to receiving a patch and do not know what they should do with it; the developers decide to appropriate the patch ideas for themselves and not share credit (hopefully a rare outcome); the project is no longer active, so no one receives the patch. |
| The patch is discussed but never applied. | The patch may be deemed unacceptable after public discussion and iterations with the contributor; the project may not have (or think they have) resources to apply the patch; the project may not want the patch. |
| The patch is applied but the volunteer later doesn’t feel properly credited. | The project may not have thought through intellectual property and copyright issues. |
| The patch is applied (typically after some iterations) and incorporated into the release. | The project is a mature open source project with open governance. |
| The contributor submits several more patches and is eventually given write access to the main code base and the ability to participate in major project decisions. | The project has a governance model that it uses to make these decisions. |