Post NUMFocus project summit 2024 notes

[mattijn]

The following notes were shared before in the steering-committee slack channel of the Vega project, but since that channel has a burning archive of messages older than 90 days it was considered valuable to keep these notes in a public place as well.

5-7 September there was the NUMFocus project summit 2024. See https://www.nfsummit24.com.

From the Vega project organisation @binste, @arvind and me were attending.
My thoughts and experiences as a (shared) short reflection on attending the NumFocus project summit.

Sharing experiences on how to do open source software as maintainers is very valuable.
It is very interesting to meet all different kind of people, but basically with the same question, how can you develop and maintain open source software in a sustainable way.

There were some presentations on the functioning of NumFOCUS. Much of this was very much a learning experience. What stand out for me was the variation in support NumFOCUS can offer to each project. See sheet below in what type of support to all the projects.
There were organised different sessions on different topics, see all topics as issues in this GitHub repository: https://github.com/numfocus/project-summit-2024-unconference/issues. The session notes are attached within each issue with main findings of each session.

In general I noticed that people are utilising NumFOCUS in multifold ways. As ‘safety net’ when organising a conference. For access to ‘small development grants’ (up to 10K). For trademark ownerships. Assistance and proofreading grants. GPU credits on GitHub action, to name a few.

So basically it was not about, what is your package and what can it do, but more about, what are your experiences and lessons that you can share on how to make the development and maintenance more sustainable.

We will get info on our enrolment soon.

Projects that founded startups or consulting branches:

• https://www.ionworks.com/
• https://prefix.dev/
• https://quantstack.net/
• https://probabl.ai/
• https://www.pymc-labs.com/
• https://juliahub.com/

Grants options that were shared:

• https://chanzuckerberg.com/
• https://science.nasa.gov/open-science/nasa-open-science-funding-opportunities/
• https://www.outreachy.org/
• https://developers.google.com/season-of-docs
• https://summerofcode.withgoogle.com/
• https://www.sovereigntechfund.de/

Projects that shared their previous submitted proposals:

• https://github.com/astropy/astropy-project/tree/main/finance/large_astropy_proposals
• https://www.ogrants.org/
• https://github.com/matplotlib?q=NASA&type=all&language=&sort=
• https://github.com/matplotlib?q=czi&type=all&language=&sort=
• https://zenodo.org/records/3406803

My notes based based on discussions on writing proposals for grant calls (summarised by LLM):

• Focus on opportunities ("shots on goal").
• Storytelling in 5 pages: Clearly explain the project's importance and urgency.
• Write for non-technical audiences: Ensure clarity so even non-experts believe and understand your proposal.
• Persuade reviewers: Make them think, “This is essential and should happen now.”
• Build relationships with corporations: Show how the project is being used, highlight locked-in projects, and demonstrate communication and relationship-building skills.
• Target what’s important: Tailor your story to focus on publicly known priorities of the grant.
• Engage with grant officers: Use the contact information on agency websites. A phone call is often the best approach.
• Seek feedback mid-way: Ask for suggestions on improving your proposal before submission.
• Consider pre-existing relationships: Cold emails aren’t always effective. Webinars may reveal if the grant isn’t a good fit.
• NUMFocus support: They can provide feedback, proofreading, and endorsement letters for grant applications.
• Simplify for reviewers: Assume the grant officer isn’t reading carefully. Repeat key points to ensure the message is clear.
• Help reviewers “tick the box”: Make your application easy to evaluate.
• Repository of successful grants: Learn from past grants, including their format and responses to calls.
• Show market research and sustainability plans: Funders want to know how the project will sustain itself after the grant.
• Co-funding is attractive: Show how you’ll secure additional funding for better chances of success.
• Consider membership models and consultancy: Explore these for sustainability beyond grants.
• Incorporate OSS into employment: If working for a company, seek approval to contribute to open-source projects as part of your role.

At the summit Arvind, Stefan and I had some brainstorms

• How to introduce research goals (again) within the different packages within the various packages belonging to the Vega project.
• How and where we could push for improvements to reduce barriers to enter and attract developers.
• We have some ideas on this, see also this network analysis of types done by Stefan https://mattijn.github.io/vega-altair-types/. Example bring in paid developers to ‘Resolve technical debt’, reduce things that are ‘overly abstract and overly complex’ and overcoming ‘errors in type signatures’.
• How to bring back the lessons learned from newer packages back into the Vega project? Examples such as Mosaic, Altair Express, Umwelt, BlueFish etc.
• The JSON file format as intermediate representation is very powerful, but how can it be used for binary data streams, such as array data or images?

We opened several GitHub issues and discussions during and just after the summit as such:

• Can WASM builds of Altair be adopted within the CI part of Github Action? altair#3578
• Use https://blog.scientific-python.org for Altair specific blog posts. altair#3579
• Would a Matplotlib backend be useful? altair#3035 (reply in thread)
• Regularly test against nightly builds of our dependencies altair#3574
• adopt nightly builds in accordance with SPEC-4 altair#3576
• Switch from hatch to uv for package and environment management altair#3577
• improve accessibility for screen reader users altair#3575
• Make all features in Altair thread-safe altair#3589
• feat: Add 'olli' renderer to generate accessible text structures for screen reader users altair#3580
• docs: Make plausible web analytics public and add link to maintainer notes altair#3571

To summarise from my side: it was fun!