You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: _posts/2025-08-05-scipy-bof-lessons-learned.md
+34-36Lines changed: 34 additions & 36 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,7 +2,7 @@
2
2
layout: single
3
3
title: "Listening, learning, and building together: what we heard at our SciPy 2025 BoF"
4
4
excerpt: "We held an incredibly informative community session this year at the SciPy meeting in Tacoma Washington. We asked the community what their open source Python pain points were. Learn more about what we learned in this interactive session."
<imgsrc="/images/blog/scipy-bof/community-discussion-2.png"alt="Attendees from different scientific backgrounds actively participate in a BoF discussion, sharing experiences from across the research software ecosystem.">
<imgsrc="/images/blog/2025/scipy-bof/community-discussion-2.png"alt="Attendees from different scientific backgrounds actively participate in a BoF discussion, sharing experiences from across the research software ecosystem.">
23
23
</picture>
24
24
</figure>
25
25
@@ -47,8 +47,8 @@ Here’s what we heard and how it’s shaping where we go from here.
<imgsrc="/images/blog/scipy-bof/community-discussion.png"alt="SciPy 2025 attendees sit in a discussion circle during the pyOpenSci BoF session, engaged in conversation about research software challenges.">
<imgsrc="/images/blog/2025/scipy-bof/community-discussion.png"alt="SciPy 2025 attendees sit in a discussion circle during the pyOpenSci BoF session, engaged in conversation about research software challenges.">
52
52
</picture>
53
53
</figure>
54
54
@@ -60,8 +60,8 @@ Participants used phrases like “dependency hell,” “non-Python pain,” “
60
60
61
61
People asked:
62
62
63
-
* When should I use [Pixi](https://pixi.sh/) vs [pip](https://pypi.org/project/pip/) vs [uv](https://docs.astral.sh/uv/)?
64
-
* What’s the right way to support non-Python dependencies?
63
+
* When should I use [Pixi](https://pixi.sh/) vs [pip](https://pypi.org/project/pip/) vs [uv](https://docs.astral.sh/uv/)?
64
+
* What’s the right way to support non-Python dependencies?
65
65
* Why does it still feel like setting up my environment is half the battle?
66
66
67
67
Even seasoned developers shared that they still wrestle with [build systems](https://www.pyopensci.org/python-package-guide/package-structure-code/python-package-build-tools.html#build-front-end-vs-build-back-end-tools) and [publication pipelines](https://www.pyopensci.org/python-package-guide/tutorials/publish-pypi.html). And for scientists new to software development, the learning curve can feel nearly vertical.
@@ -71,8 +71,8 @@ Even seasoned developers shared that they still wrestle with [build systems](htt
<img src="/images/blog/scipy-bof/results-open-code-painpoints.png" alt="Mentimeter board filled with participant feedback on how institutions could better support sustainable research software, including ideas like checklists and incentives.
<img src="/images/blog/2025/scipy-bof/results-open-code-painpoints.png" alt="Mentimeter board filled with participant feedback on how institutions could better support sustainable research software, including ideas like checklists and incentives.
76
76
">
77
77
</picture>
78
78
</figure>
@@ -83,8 +83,8 @@ Even seasoned developers shared that they still wrestle with [build systems](htt
83
83
84
84
People weren’t just asking for more documentation. They were asking for:
85
85
86
-
* Docs that actually work (e.g., install instructions that don’t break),
87
-
* Docs that explain why as well as how,
86
+
* Docs that actually work (e.g., install instructions that don’t break),
87
+
* Docs that explain why as well as how,
88
88
* And docs with effective examples, not just API references.
89
89
90
90
We also heard about the challenge of writing good documentation when you’re strapped for time, unsure what your audience needs, or dealing with tools that change frequently. There were several calls for best practice guides—what *has* to be documented, how to make [gallery](https://www.pyopensci.org/python-package-guide/documentation/write-user-documentation/create-package-tutorials.html)\-style examples, and how to make sure docs stay up-to-date across versions.
@@ -93,8 +93,8 @@ We also heard about the challenge of writing good documentation when you’re st
<imgsrc="/images/blog/scipy-bof/results-open-code-painpoints-2.png"alt="Mentimeter slide summarizing common barriers to making research code more open, including time constraints, lack of institutional support, and unclear best practices.">
<imgsrc="/images/blog/2025/scipy-bof/results-open-code-painpoints-2.png"alt="Mentimeter slide summarizing common barriers to making research code more open, including time constraints, lack of institutional support, and unclear best practices.">
98
98
</picture>
99
99
</figure>
100
100
@@ -104,8 +104,8 @@ One of the clearest messages from the BoF was that technical infrastructure only
104
104
105
105
That includes:
106
106
107
-
* Mentoring programs to help new contributors feel supported and seen
108
-
* Ways to match scientists with programmers (and vice versa), especially when each party has complementary knowledge but no bridge between them
107
+
* Mentoring programs to help new contributors feel supported and seen
108
+
* Ways to match scientists with programmers (and vice versa), especially when each party has complementary knowledge but no bridge between them
109
109
* Contributor paths that don’t assume deep technical knowledge, but instead offer orientation and validation
110
110
111
111
Several folks mentioned imposter syndrome, burnout, or the sense of shouting into the void as solo maintainers. It was a good reminder that building sustainable software also means building sustainable communities.
@@ -114,8 +114,8 @@ Several folks mentioned imposter syndrome, burnout, or the sense of shouting int
<img src="/images/blog/scipy-bof/plot-use-of-llms.png" alt="Mentimeter slide displaying audience reactions to generative AI in research software, with mixed responses including excitement, skepticism, and caution.
<img src="/images/blog/2025/scipy-bof/plot-use-of-llms.png" alt="Mentimeter slide displaying audience reactions to generative AI in research software, with mixed responses including excitement, skepticism, and caution.
119
119
">
120
120
</picture>
121
121
</figure>
@@ -126,8 +126,8 @@ Of course, we also asked about LLMs and generative AI and got a spectrum of reac
126
126
127
127
Some folks are excited about the potential to scaffold code, summarize docs, or speed up tedious workflows. Others shared more cautionary takes, raising issues around:
128
128
129
-
* Trust and reproducibility (especially when LLMs hallucinate)
130
-
* Licensing concerns (who owns what?)
129
+
* Trust and reproducibility (especially when LLMs hallucinate)
130
+
* Licensing concerns (who owns what?)
131
131
* The risk that “AI-hype” could distract from foundational work and people
132
132
133
133
In short, people are experimenting, but they’re also wary. There’s interest in using these tools responsibly—**not to replace developers, but to augment and support them**.
@@ -140,14 +140,14 @@ One of the deeper undercurrents in the BoF conversation was how academic norms a
140
140
141
141
We heard:
142
142
143
-
* Researchers don’t get credit for making code reproducible or open.
144
-
* There’s little incentive to write good docs or maintain packages after publication.
143
+
* Researchers don’t get credit for making code reproducible or open.
144
+
* There’s little incentive to write good docs or maintain packages after publication.
145
145
* People are exhausted just trying to meet the minimum requirements for publication (never mind building for reuse).
146
146
147
147
And yet, people had ideas:
148
148
149
-
* Could pyOpenSci or a partner journal offer non-monetary awards for well-packaged, reproducible code?
150
-
* Could we provide press release templates to help institutions spotlight their open science champions?
149
+
* Could pyOpenSci or a partner journal offer non-monetary awards for well-packaged, reproducible code?
150
+
* Could we provide press release templates to help institutions spotlight their open science champions?
151
151
* What if we offered more checklists or templates to help researchers make their code more open, with less guesswork? We’re already taking small steps in this direction through resources like our [packaging guide](https://www.pyopensci.org/python-package-guide/), the [pyos-package-template](https://github.com/pyOpenSci/pyos-package-template), and our [list of peer-reviewed packages](https://www.pyopensci.org/python-packages.html), which offers a bit of well-earned recognition for open research software.
152
152
153
153
These aren’t technical problems. They’re cultural ones. And they’re just as important to address.
@@ -184,19 +184,17 @@ Here are some of the ideas we’re excited to explore next, aligned with the maj
184
184
185
185
* Pilot mentorship, pairing, or office-hour models to connect researchers with developers, especially in early-stage projects.
186
186
187
-
**AI, academic culture & broader systems**
187
+
### AI, academic culture & broader systems
188
188
* Build resources that help the community responsibly evaluate the use of LLMs and generative AI in open source—without overpromising or oversimplifying.
189
-
190
189
* Share reproducibility and openness checklists tailored to academic realities, helping researchers take incremental steps toward sustainable software.
191
-
192
190
* Explore non-monetary awards or spotlights that recognize peer-reviewed, well-documented, and reusable research software—even if it’s not “published” in the traditional sense.
<imgsrc="/images/blog/scipy-bof/breakout-group.png"alt="A small breakout group at SciPy 2025 BoF, with participants gathered around a table talking and taking notes on packaging and documentation pain points.">
<imgsrc="/images/blog/2025/scipy-bof/breakout-group.png"alt="A small breakout group at SciPy 2025 BoF, with participants gathered around a table talking and taking notes on packaging and documentation pain points.">
200
198
</picture>
201
199
</figure>
202
200
@@ -217,10 +215,10 @@ What do you want to see next? Where can we partner, collaborate, or amplify?
217
215
218
216
Whether you’re new to open science or have been building tools for decades, there’s a place for you here.
219
217
220
-
* Check out our [packaging guide](https://www.pyopensci.org/python-package-guide/) for tutorials, tooling comparisons, and overviews of the Python packaging ecosystem. If you spot missing content, typos, or areas for improvement, [open an issue](https://www.pyopensci.org/python-package-guide/#report-issues-or-contribute) to help us make it better.
221
-
*[Volunteer to be a reviewer for pyOpenSci’s software review process](https://docs.google.com/forms/u/6/d/e/1FAIpQLSeVf-L_1-jYeO84OvEE8UemEoCmIiD5ddP_aO8S90vb7srADQ/viewform?usp=send_form).
222
-
*[Submit a research software package to pyOpenSci for peer review.](https://www.pyopensci.org/software-peer-review/how-to/author-guide.html#submit-your-package-for-peer-review)
223
-
*[Donate to pyOpenSci](https://give.communityin.org/pyopensci_2024?ref=ab_0sHhtifYvgR0sHhtifYvgR) to support scholarships for future training events and the development of new learning content.
218
+
* Check out our [packaging guide](https://www.pyopensci.org/python-package-guide/) for tutorials, tooling comparisons, and overviews of the Python packaging ecosystem. If you spot missing content, typos, or areas for improvement, [open an issue](https://www.pyopensci.org/python-package-guide/#report-issues-or-contribute) to help us make it better.
219
+
*[Volunteer to be a reviewer for pyOpenSci’s software review process](https://docs.google.com/forms/u/6/d/e/1FAIpQLSeVf-L_1-jYeO84OvEE8UemEoCmIiD5ddP_aO8S90vb7srADQ/viewform?usp=send_form).
220
+
*[Submit a research software package to pyOpenSci for peer review.](https://www.pyopensci.org/software-peer-review/how-to/author-guide.html#submit-your-package-for-peer-review)
221
+
*[Donate to pyOpenSci](https://give.communityin.org/pyopensci_2024?ref=ab_0sHhtifYvgR0sHhtifYvgR) to support scholarships for future training events and the development of new learning content.
224
222
* Check out our [volunteer page](https://www.pyopensci.org/volunteer.html) for other ways to get involved.
If you are on LinkedIn, check out and [subscribe to our newsletter](https://www.linkedin.com/newsletters/7179551305344933888/?displayConfirmation=true), too.
0 commit comments