-->PONE-D-25-68889-->-->A system-wide snapshot: A multi-campus survey of open source contributors at the University of California-->-->PLOS One

Dear Dr. Scarlett,

Thank you for submitting your manuscript to PLOS ONE. After careful consideration, we feel that it has merit but does not fully meet PLOS ONE’s publication criteria as it currently stands. Therefore, we invite you to submit a revised version of the manuscript that addresses the points raised during the review process.

-->-->The three reviewers provide excellent feedback for your analysis. In particular, it would be good to position your study in the broader literature on the subject, to clarify or improve some of your statistical analysis and finally consider limitations of your study that result from the sampling procedure.-->-->

Please submit your revised manuscript by Apr 04 2026 11:59PM. If you will need more time than this to complete your revisions, please reply to this message or contact the journal office at plosone@plos.org. When you're ready to submit your revision, log on to https://www.editorialmanager.com/pone/ and select the 'Submissions Needing Revision' folder to locate your manuscript file.

Please include the following items when submitting your revised manuscript:-->

• A letter that responds to each point raised by the academic editor and reviewer(s). You should upload this letter as a separate file labeled 'Response to Reviewers'.
• A marked-up copy of your manuscript that highlights changes made to the original version. You should upload this as a separate file labeled 'Revised Manuscript with Track Changes'.
• An unmarked version of your revised paper without tracked changes. You should upload this as a separate file labeled 'Manuscript'.

-->If you would like to make changes to your financial disclosure, please include your updated statement in your cover letter. Guidelines for resubmitting your figure files are available below the reviewer comments at the end of this letter.

If applicable, we recommend that you deposit your laboratory protocols in protocols.io to enhance the reproducibility of your results. Protocols.io assigns your protocol its own identifier (DOI) so that it can be cited independently in the future. For instructions see: https://journals.plos.org/plosone/s/submission-guidelines#loc-laboratory-protocols. Additionally, PLOS ONE offers an option for publishing peer-reviewed Lab Protocol articles, which describe protocols hosted on protocols.io. Read more information on sharing protocols at https://plos.org/protocols?utm_medium=editorial-email&utm_source=authorletters&utm_campaign=protocols.

We look forward to receiving your revised manuscript.

Kind regards,

Vincent Antonio Traag, Ph.D.

Academic Editor

PLOS One

Journal Requirements:

When submitting your revision, we need you to address these additional requirements.

1. Please ensure that your manuscript meets PLOS ONE's style requirements, including those for file naming. The PLOS ONE style templates can be found at

https://journals.plos.org/plosone/s/file?id=wjVg/PLOSOne_formatting_sample_main_body.pdf and

https://journals.plos.org/plosone/s/file?id=ba62/PLOSOne_formatting_sample_title_authors_affiliations.pdf

2.  We notice that your supplementary figures are uploaded with the file type 'Figure'. Please amend the file type to 'Supporting Information'. Please ensure that each Supporting Information file has a legend listed in the manuscript after the references list.

3. If the reviewer comments include a recommendation to cite specific previously published works, please review and evaluate these publications to determine whether they are relevant and should be cited. There is no requirement to cite these works unless the editor has indicated otherwise.

4. Please review your reference list to ensure that it is complete and correct. If you have cited papers that have been retracted, please include the rationale for doing so in the manuscript text, or remove these references and replace them with relevant current references. Any changes to the reference list should be mentioned in the rebuttal letter that accompanies your revised manuscript. If you need to cite a retracted article, indicate the article’s retracted status in the References list and also include a citation and full reference for the retraction notice.

[Note: HTML markup is below. Please do not edit.]

Reviewers' comments:

Reviewer's Responses to Questions

-->Comments to the Author

1. Is the manuscript technically sound, and do the data support the conclusions?

The manuscript must describe a technically sound piece of scientific research with data that supports the conclusions. Experiments must have been conducted rigorously, with appropriate controls, replication, and sample sizes. The conclusions must be drawn appropriately based on the data presented. -->

Reviewer #1: Partly

Reviewer #2: Yes

Reviewer #3: Yes

**********

-->2. Has the statistical analysis been performed appropriately and rigorously? -->

Reviewer #1: I Don't Know

Reviewer #2: Yes

Reviewer #3: Yes

**********

-->3. Have the authors made all data underlying the findings in their manuscript fully available?

The PLOS Data policy requires authors to make all data underlying the findings described in their manuscript fully available without restriction, with rare exception (please refer to the Data Availability Statement in the manuscript PDF file). The data should be provided as part of the manuscript or its supporting information, or deposited to a public repository. For example, in addition to summary statistics, the data points behind means, medians and variance measures should be available. If there are restrictions on publicly sharing data—e.g. participant privacy or use of data from a third party—those must be specified.-->

Reviewer #1: No

Reviewer #2: Yes

Reviewer #3: Yes

**********

-->4. Is the manuscript presented in an intelligible fashion and written in standard English?

PLOS ONE does not copyedit accepted manuscripts, so the language in submitted articles must be clear, correct, and unambiguous. Any typographical or grammatical errors should be corrected at revision, so please note any specific errors here.-->

Reviewer #1: Yes

Reviewer #2: Yes

Reviewer #3: Yes

**********

-->5. Review Comments to the Author

Please use the space provided to explain your answers to the questions above. You may also include additional comments for the author, including concerns about dual publication, research ethics, or publication ethics. (Please upload your review as an attachment if it exceeds 20,000 characters)-->

Reviewer #1: Overall, I am interested in this work, as I work in this field and have also performed some similar work (which is in the process of being written up.) I would like to see a revised version of this paper published. My comments on it are:

1. While the survey was performed for the reasons discussed by the authors in the abstract, the results are also useful to those who study the open source and research software more widely, and can be used to compare with the results of other surveys.

Some examples:

[1] Brown A., Crouch S., Graham J., Grylls P.J., Hettrick S.J., Mangham S.W., Robinson J. & Wyatt C.”Research software at the University of Southampton”. 10 December 2019. http://eprints.soton.ac.uk/id/eprint/504695

[2] Mourão, E., Trevisan, D., & Viterbo, J. ”Understanding the success factors of

research software: interviews with Brazilian computer science academic

researchers.” In International Conference on Information Technology & Systems

(pp. 275-286). Cham: Springer International Publishing. 2023, February

[3] Besser, S. A., Jensen, E. A., & Katz, D. S. (2025). Research Software at the University of Illinois Urbana-Champaign: A Mixed Methods Survey Dataset (1.0) [Data set]. Zenodo. https://doi.org/10.5281/zenodo.15161372 (though no paper about this has yet been published)

I think it would be useful to frame the work, at least partially, in this larger scholarly context.

2. I think some discussion of the distinction between open source software and research software would be useful to add to the introduction. While it's clear that open source is the focus, it's unclear how much of this is research software vs more general open source, whether used for research or education or administration. Some of this is discussed in the figures and the discussion, but it would be useful to introduce this earlier in the paper.

3. Other sources of data exist that can be used to find open source information for a campus or system, such as GitHub and Software Heritage. It might be useful to mention these as well, even if collecting data from them and using this to enhance the understanding of the OS work at UC is beyond the scope of a revision.

4. The number of responses is extremely low, given the size of the community being surveyed. As a comparison, there were about 250 responses in [1] from a single university. This leads to a large question about selection bias. This is discussed in Limitations, but probably should be highlighted as a possible issue much earlier in the paper.

5. As a comment for PLOS more than for the authors, reading a draft that discusses figures and includes their captions but puts the figures themselves at the end (rather than in-line) is extremely frustrating and make the review harder and worse.

6. The DOIs listed for data and code availability don't resolve, so that the data and code are not currently available, and I was unable to check their completeness and quality.

7. I do not have appropriate expertise to judge the statistical analysis aspect of the work.

Reviewer #2: In this manuscript, Scarlett et al. report and discuss the results of a survey on UC campuses on Open Source contributions. The paper is timely given how much of modern society's infrastructure relies on software and how little is known about Open Source contributors dynamics in leading thought institutions globally.

Overall, the study is interesting, the methodology is mostly sound, and the manuscript is well written. I found minor statistical details that might need some clarification. In terms of data interpretation and discussion, I think the authors are a little too cautious. I do appreciate that they want their conclusions supported by data as much as possible, but I think that in a paper like this, part of the "Discussion" can include slightly more speculative angles that might give perspective to the individual findings. For instance, the fact that many contributors report lacking time rather then resources but then request resources (grants) to close that gap signals a clear inconsistency in my mind, however this is not directly discussed in the current manuscript.

Another point I'd like to raise is the current lack of focus on gender issues, a known strong bias in many open source communities. I wonder whether the authors might want to comment about this specific issue.

In conclusion, I think that this work is useful and well thought through. I add individual comments below that hopefully will help clarify specific items throughout the draft. They should be taken as nonbinding suggestions rather than hard requirements.

- Line 100: Unclear whether that first survey is this paper?

- Line 195: Complete list of packages not in references: this is part of the issue isn't it. This paper is not expected to fix this but at least acknowledge it.

- Line 199: Why is the job a fixed effect for all analyses? I get it that it's most likely the right thing to do, but it would be useful to have a couple passes without just to get a sense of the data with no filters.

- Line 235: I'm not sure I follow. The job categories are made somewhat arbitrarily (and further coarse grained occasionally), therefore the most obvious thing to do would be to not touch the data instead of rebalancing according to said arbitrary categories. The impression that this is "equal weighting" seems misguided to me. The real issue, of course, is that noise from rarely populated categories is going to pollute everything else.

- 251: Not sure what the power analysis is supposed to tell me since the 80% and 0.05 are arbitrary thresholds, but I guess it does not hurt to have this?

Results:

- 314: How does that compare to roughly estimated demographics in those campuses? To other surveys?

- 317: Part of the appeal/success of OSS technology is that it cuts through traditional disciplinary boundaries. I wonder how people with activities across multiple "fields" would feed about this categorisation.

- 322 and surrounding: Following up on the previous points, I wonder how a bioinformatician or chemical physicist / physical chemist would feel about this breakdowns.

- I also wonder how these percentages relate to total population numbers in those fields on campus. Medicine employs a lot of people in some campuses and therefore might have an outsized effect on the percentages. Without these baseline references, the percentages alone are a little confusing to me.

- 327 etc: Same as above, how do these percentages relate to total campus / staff numbers? I wonder whether UCs employ a lot of librarians (including part-time?) or whether librarians are more invested in Open Source.

- 343: How many actually said "not applicable"? It sounds like a small percentage, but it might be good to just write it out.

- 365: Phrasing is a little odd here.

- 390: Some comment on whether any of this was expected a priori would be useful I think.

- 452: I guess no multiple hypothesis correction here?

- 468: Same.

- 518: I think many OS contributors would assume - given the current funding landscape for OS projects - that "Resourcing" is out of the picture to start with, i.e. that OS development is intrinsically an unpaid, volunteer activity. So I don't know that I agree with the authors' interpretation that "Resourcing is not perceived as widespread", or at least I find it a little simplistic and misleading as currently phrased. I would add a comment of sorts somewhere in the paper (Discussion?).

- 527 and following: Indeed, this confirms my last comment. Faculty at least seems to know there is the *possibility* of funding - I imagine because they are used to applying for grants all the time anyway - and therefore has an easier time identifying Resourcing as even an issue, whereas many other categories might find lack of resources an "immutable" state of affairs and therefore, as a natural phenomenon, not a "challenge". I think adding a comment in this direction would help the readers reason on what might be going on, even though it is a little speculative.

- 541: This is a little awkward I think. Most people seem to say they lack primarily time, but when asked for solution they do not request time but resources instead. Of course, money can buy a developer's time to some degree, but I think this might speak to the fact that if OS contributions were considered a prestigious / legitimate activity in academia, then people might actually request for time instead of funding. In other words, I suspect that if UC campuses adopted the Google policy of yore "one day a week do whatever you are passionate about", then the answer to this question might change drastically. I am digressing, but I think a mention of this inconsistency somewhere in the paper would be useful.

- 587: I wonder how much of this is due to the AI bubble, which requires very special computing environments. New contributors might be most excited about this fashionable field and therefore be feeling this need more acutely. Perhaps adding a comment somewhere?

Other questions:

- Was there no question about age or age brackets? It would be interesting to see when in life people tend to get involved for what roles (mainteiner, bug reporter, etc.).

- Also, it would be interesting for future work to find a way to ask how people deeply enmeshed in open source finally stop their contributions. OS burnout is a serious issue and the authors might have a good platform to study this question quantitatively.

Reviewer #3: This manuscript presents findings from a multi-campus survey (n = 294) conducted across the University of California system to characterize open source contributors and identify their needs from the perspective of an academic Open Source Program Office (OSPO). The study integrates quantitative survey analysis (including ordinal regression, clustering, and non-parametric tests) with qualitative thematic coding. The authors report that open source is critical to academic work, that a surprisingly high proportion of respondents have served as maintainers (58%), and that lack of time—particularly for documentation—along with funding constraints and institutional culture are the most frequently reported barriers. The authors conclude with policy-relevant recommendations for supporting sustainability within academic OSPO initiatives.

While the study is limited to a single institution, it can be used as a good template for similar studies in other universities. It aligns with PLOS ONE's scope, the manuscript is generally sound, though several clarifications and refinements would improve its claims and generalizability.

1. The use of non-probability snowball sampling is clearly described, but the implications for representativeness are not sufficiently emphasized in the Discussion. Given that recruitment channels likely reached individuals already engaged in open source communities, the sample may overrepresent highly active contributors, in particular maintainers.

The claim that 58% of contributors have served as maintainers is striking and framed as a novel finding. However, without a defined sampling frame or baseline institutional estimates, it is difficult to interpret whether this proportion reflects the broader UC open source population.

Also the text do not make it clear on how a "maintainer" is defined. Is it the user with highest amount of contributions, owner of the repository, self-defined?

2. The manuscript occasionally shifts from describing UC-specific findings to discussing broader "universities" or "the academy". While the policy implications are broadly relevant, the empirical base is confined to one university system. Given UC's size, structure, and research intensity, it may not be representative of smaller or differently structured institutions. I recommend the authors to avoid generalizing or extrapolating the findings to other institutions. However, the authors should provide and suggest that studies of different universities could be conducted with the proposed framework.

Minor points:

Clarify distinctions between "experienced contributors", "aspiring contributors", and "users". Ensure consistent use of "non-research staff" vs "IT staff" vs "academic".

The emergence of cultural themes is one of the more interesting findings. Consider expanding this section slightly, as it appears organically from qualitative data instead of being prompted.

Some figure-heavy sections could benefit from slightly more synthesis in the main text to prevent fragmentation. Also, ensure all key claims are explicitly tied to figure numbers.

The Results section is potentially too dense. The Discussion could be slightly tightened to avoid repetition of detailed numeric results already presented.

Given the comments above, I recommend that the manuscript be revised before being considered for publication.

**********

-->6. PLOS authors have the option to publish the peer review history of their article (what does this mean?). If published, this will include your full peer review and any attached files.

If you choose “no”, your identity will remain anonymous but your review may still be made public.

Do you want your identity to be public for this peer review? For information about this choice, including consent withdrawal, please see our Privacy Policy.-->

Reviewer #1: Yes:Daniel S. Katz

Reviewer #2: Yes:Fabio Zanini

Reviewer #3: Yes:Filipi Nascimento Silva

**********

[NOTE: If reviewer comments were submitted as an attachment file, they will be attached to this email and accessible via the submission site. Please log into your account, locate the manuscript record, and check for the action link "View Attachments". If this link does not appear, there are no attachment files.]

To ensure your figures meet our technical requirements, please review our figure guidelines: https://journals.plos.org/plosone/s/figures

You may also use PLOS’s free figure tool, NAAS, to help you prepare publication quality figures: https://journals.plos.org/plosone/s/figures#loc-tools-for-figure-preparation.

NAAS will assess whether your figures meet our technical requirements by comparing each figure against our figure specifications.

-->

A system-wide snapshot: A multi-campus survey of open source contributors at the University of California

PONE-D-25-68889R1

Dear Dr. Scarlett,

We’re pleased to inform you that your manuscript has been judged scientifically suitable for publication and will be formally accepted for publication once it meets all outstanding technical requirements.

Within one week, you’ll receive an e-mail detailing the required amendments. When these have been addressed, you’ll receive a formal acceptance letter and your manuscript will be scheduled for publication.

An invoice will be generated when your article is formally accepted. Please note, if your institution has a publishing partnership with PLOS and your article meets the relevant criteria, all or part of your publication costs will be covered. Please make sure your user information is up-to-date by logging into Editorial Manager at Editorial Manager® and clicking the ‘Update My Information' link at the top of the page. For questions related to billing, please contact billing support.

If your institution or institutions have a press office, please notify them about your upcoming paper to help maximize its impact. If they’ll be preparing press materials, please inform our press team as soon as possible -- no later than 48 hours after receiving the formal acceptance. Your manuscript will remain under strict press embargo until 2 pm Eastern Time on the date of publication. For more information, please contact onepress@plos.org.

Kind regards,

Vincent Antonio Traag, Ph.D.

Academic Editor

PLOS One

Additional Editor Comments (optional):

Reviewers' comments:

Reviewer's Responses to Questions

-->Comments to the Author

1. If the authors have adequately addressed your comments raised in a previous round of review and you feel that this manuscript is now acceptable for publication, you may indicate that here to bypass the “Comments to the Author” section, enter your conflict of interest statement in the “Confidential to Editor” section, and submit your "Accept" recommendation.-->

Reviewer #1: (No Response)

Reviewer #2: All comments have been addressed

**********

-->2. Is the manuscript technically sound, and do the data support the conclusions?

The manuscript must describe a technically sound piece of scientific research with data that supports the conclusions. Experiments must have been conducted rigorously, with appropriate controls, replication, and sample sizes. The conclusions must be drawn appropriately based on the data presented. -->

Reviewer #1: Yes

Reviewer #2: Yes

**********

-->3. Has the statistical analysis been performed appropriately and rigorously? -->

Reviewer #1: I Don't Know

Reviewer #2: Yes

**********

-->4. Have the authors made all data underlying the findings in their manuscript fully available?

The PLOS Data policy requires authors to make all data underlying the findings described in their manuscript fully available without restriction, with rare exception (please refer to the Data Availability Statement in the manuscript PDF file). The data should be provided as part of the manuscript or its supporting information, or deposited to a public repository. For example, in addition to summary statistics, the data points behind means, medians and variance measures should be available. If there are restrictions on publicly sharing data—e.g. participant privacy or use of data from a third party—those must be specified.-->

Reviewer #1: Yes

Reviewer #2: Yes

**********

-->5. Is the manuscript presented in an intelligible fashion and written in standard English?

PLOS ONE does not copyedit accepted manuscripts, so the language in submitted articles must be clear, correct, and unambiguous. Any typographical or grammatical errors should be corrected at revision, so please note any specific errors here.-->

Reviewer #1: Yes

Reviewer #2: Yes

**********

-->6. Review Comments to the Author

Please use the space provided to explain your answers to the questions above. You may also include additional comments for the author, including concerns about dual publication, research ethics, or publication ethics. (Please upload your review as an attachment if it exceeds 20,000 characters)-->

Reviewer #1: In general, I am happy with the responses to my and other reviewer's comments.

Some small remaining issues:

I don't think "a preference for" in line 444 is an accurate description, as this implies motive.

In lines 545 and 764, I wonder if any IT staff are also research staff, as is the case in some academic institutions.

I've marked this as minor revision, but I do not feel a need to review this again just for these changes.

Reviewer #2: The authors have addressed all requested changes, mostly in a satisfactory fashion. Occasional disagreements, for instance on whether full package reference citation is or is not best practice, might be unresolved (it is best practice as far as I am concerned: recursive software dependencies are very real) but should not impact the overall high quality of the study nor its ability to proceed to acceptance.

Great job, a timely study.

**********

-->7. PLOS authors have the option to publish the peer review history of their article (what does this mean?). If published, this will include your full peer review and any attached files.

If you choose “no”, your identity will remain anonymous but your review may still be made public.

Do you want your identity to be public for this peer review? For information about this choice, including consent withdrawal, please see our Privacy Policy.-->

Reviewer #1: Yes:Daniel S. Katz

Reviewer #2: Yes:Fabio Zanini

**********