2025 Funding Process Iteration

[steiza]

We are just wrapping up the 2024 OpenSSF Technical Initiative funding process, but we already have many ideas on what we want to see changed for next year (or things we'll at least consider).

For now, this issue will be used to collect those ideas, and then when the 2025 TAC is seated we'll use this input to do an iteration on https://github.com/ossf/tac/blob/main/process/TI%20Funding%20Request%20Process.md and set the 2025 schedule.

[steiza]

Here are some of the suggestions I've heard:

• How can we make the application easier, especially for smaller amounts?

• Can we create a directory of who has provided services to the OpenSSF in the past? Technical writers, UI/UXperts, security audits, writing code, ...

• Can we provide an abstract "menu" listing out types of request (cloud credits, technical writing, security audits, writing code) and link to example applications, and maybe summarize typical amounts and TI lifecycle stage?

• And / or can we create an end of year report of all the things we funded, to help TIs make similar applications in the future?

• How often should the TAC review funding requests? Quarterly again? Every 2 months? Rolling basis?

• Should there be an easier process for a previously approved request to be renewed for another year? This came up with https://github.com/ossf/tac/issues/315 and https://github.com/ossf/tac/issues/417.

• (EDIT / added) Should we move the application process from issues to pull requests, to be consistent with TI lifecycle updates and TI quarterly updates?

[mlieberman85]

My recommendation would be rolling basis if possible. I think we do so few that having them come up as they need would be fine. If we start to get overwhelmed then I think we can switch to something like quarterly.

[lehors]

• Should there be an easier process for a previously approved request to be renewed for another year?

I don't think the current process is complicated and worth simplifying.

[steiza]

Another item for discussion: how long should the review period be?

I think the 1 week we had for 2024 was too short, especially if folks had business travel or vacation scheduled that week. I would suggest a 2 week review period.

[di]

Would be nice to have some examples of what is/isn't a valid funding request, and how they could be structured. Maybe some previously submitted proposals and the result? Or hypotheticals.

[gkunz]

Would be nice to have some examples of what is/isn't a valid funding request, and how they could be structured. Maybe some previously submitted proposals and the result? Or hypotheticals.

I agree. I believe the current process description doesn't prescribe how exactly the milestones of a funding request are being presented to and reviewed by the TAC, but I would propose to apply the same process as for TI updates to the TAC, i.e., through a summary (markdown) document. These summaries can then ask as guiding examples for new requests.

[steiza]

I believe the current process description doesn't prescribe how exactly the milestones of a funding request are being presented to and reviewed by the TAC, but I would propose to apply the same process as for TI updates to the TAC, i.e., through a summary (markdown) document.

Yes, so I touched on this above with:

• (EDIT / added) Should we move the application process from issues to pull requests, to be consistent with TI lifecycle updates and TI quarterly updates?

Like you mention, TI quarterly updates are done via PRs, which have a nice built-in way to track approvals, allow other people to suggest content or comment on specific content, and you can search for past examples.

Funding requests today are done via Issues. They don't have a built-in way to track approvals, which we work around with comments, emoji reactions, or gitvote. You can comment on an issue but not on a specific line, but like pull requests it's pretty easy to search for past examples.

Conceptually, I like to think of issues as work that's still be scoped out, having implementation discussions, and deciding who will work on it, like we're doing here, and then the result of that work is a pull request that resolves the issue. But I do like how user-friendly the issue template is, and it's easier to fill out in a browser than making a pull request. I don't currently have a strong preference for if funding requests continue to be done via issues or pull requests.

[bobcallaway]

I'm still strongly against moving to rolling proposals. Batching forces us to evaluate and judge comparatively, which is an important function for the TAC.

We have a demand (and potentially awareness) problem with a lack of requestors.

[marcelamelara]

How often should the TAC review funding requests? Quarterly again? Every 2 months? Rolling basis?

Like I've mentioned previously, I have a strong preference for having a fixed review schedule, rather than reviewing on a rolling basis. It allows me to set aside time for reviewing and I think makes TIs scope their requests a bit better as well.

Should we move the application process from issues to pull requests, to be consistent with TI lifecycle updates and TI quarterly updates?

I'm really in favor of moving the funding request process to PRs.

I agree with @bobcallaway that we likely have a lack of awareness about the funding opportunities within TIs. Last year, we posted the dates for all for 2024 in a blog post, but it's unclear how many TI participants were reached. I suggest we focus our advertising of the funding process on Slack and with the help of WG/TI leads.

[steiza]

With #435 we addressed most of the items brought up here that we had rough consensus on - with the exception of moving the funding process from issues to pull requests. It'll be a week or two before I have time to address that item, if someone wants to take that on in the meantime.

[marcelamelara]

Following the Feb 2025 funding request review cycle, we wanted to open up a discussion about how to handle contractor requests moving forward. The context for this is that request #445 showed that unfortunately several of us have difficulties evaluating requests solely based on technical merit (which should be the TAC's focus) when questions arise about especially large funding amounts that are being requested.

From a short discussion in the private TAC channel on Slack, a suggested path forward is to make slight changes to the information we require in the initial funding request. If it's a contractor request: 1) do not include $ amounts or other financial info (only expected work time), and 2) do not disclose specific contractors, only indicate if a candidate contractor has been identified.

I believe this is more closely aligned with the intent of having TAC review technical merit, and OpenSSF staff review the financial aspect. I also don't believe that this adds more complexity to the process since contracts already need to be reviewed and issued by staff, so it makes more sense to defer the discussion about contractor selection and funding to that point.

FWIW, this is already how we've handled other similar requests like security audits and surveys, so there is precedent for more clearly separating the technical from the financial decision.

@ossf/tac and @riaankleinhans please chime in.

[steiza]

We talked about this at the Governance Committee meeting last Thursday, and staff noted that having vendor information and financial amount is very helpful for them to process the funding request (and it'd be nice to only have one form people fill out for both TAC review and staff approval). In light of that, here are the modifications staff suggested (@Naomi-Wash keep me honest!)

• If the request is for a security audit, staff would like OSTIF to always run the RFP
• If it's not a security audit
  • If the request is below some threshold ($10k?) and the funding request has a vendor in mind, staff will manage payment but trust the community on selection
  • Otherwise OpenSSF TPM will run the vendor selection process

So essentially we no longer require specifying a vendor, although you are welcome to suggest someone. For small funding grants (at whatever threshold we define) if you have a vendor you can just go ahead, otherwise staff will help your run a RFP.

In this proposal, we would still require a dollar amount on the funding request, although since you might not have selected a vendor it would be a ballpark estimate.

Does that make sense to everyone?

[marcelamelara]

Thanks for the update @steiza ! This is the sort of guidance I was ultimately looking for. Given that we're reviewing at least one request for a vendor in cycle 2, did we settle on what that threshold is for running a vendor selection process? It'd be great to let the requestor know a priori how their request will be handled following TAC approval.

CC @Naomi-Wash