[Technical Initiative Funding Request]: GoReleaser Pro access for OpenSSF Projects

[brandtkeller]

Technical Initiative

Zarf (and other projects with verbal agreement)

Lifecycle Phase

sandbox (other projects in varying levels)

Funding amount

$948/yr

Problem Statement

Many OpenSSF projects utilize Go and GoReleaser for building and distributing their release artifacts. However, a critical gap exists: these projects cannot easily perform nightly or CI-driven "pre-releases" that faithfully mirror official releases. This discrepancy reduces confidence in release reproducibility and can result in last-minute errors or regressions going undetected until final release. GoReleaser Pro offers capabilities—such as "nightly" snapshot releases that follow the same pipelines and signing processes as production releases — which directly address this issue. These features are essential for elevating release fidelity and increasing confidence in the reliability of official software artifacts. While each project could individually license GoReleaser Pro, a centralized, shared license supported by the OpenSSF would be more efficient and equitable, benefiting all OpenSSF Go-based projects, including those in bomctl, GUAC, and other OpenSSF-maintained repositories.

Who does this affect?

This affects maintainers and consumers of OpenSSF Golang-based projects. For maintainers, it streamlines and enhances the release workflow. For users, it increases the trustworthiness of distributed artifacts.

Have there been previous attempts to resolve the problem?

Most OpenSSF projects using GoReleaser currently rely solely on the open-source version. Some attempt to script workarounds to achieve similar nightly builds, but these often diverge from the official release processes and introduce technical debt. No formal shared licensing initiative has been pursued until now.

Why should it be tackled now and by this TI?

With the growing emphasis on software supply chain integrity, reproducibility, and attestation, ensuring parity between nightly and official release workflows is critical. The OpenSSF’s emphasis on high-integrity, verifiable software releases makes this a timely opportunity to remove a systemic weak link. This small investment strengthens a foundational release tool used across multiple technical initiatives, accelerating their ability to confidently ship secure, signed, and reproducible binaries.

Give an idea of what is required to make the funding initiative happen

A GoReleaser Pro license ($948 annually) will be centrally maintained and made available to OpenSSF Golang-based projects. Access control can be managed through a GitHub organization or release automation account designated by the OpenSSF TAC.

What is going to be needed to deliver this funding initiative?

Only funding for the GoReleaser Pro license is required. No additional infrastructure or engineering support is needed at this time.

Are there tools or tech that still need to be produced to facilitate the funding initiative?

No additional tools are needed.

Give a summary of the requirements that contextualize the costs of the funding initiative

GoReleaser Pro costs $948 per year for a license. This funding initiative would support a centrally administered license that may be shared across OpenSSF projects under agreed usage policies (e.g., via GitHub Actions secrets or shared CI accounts). The cost is low relative to the value provided to a broad swath of projects.

Who is responsible for doing the work of this funding initiative?

Brandt Keller (@brandtkeller), OpenSSF contributor and maintainer of Zarf, will coordinate with any required OpenSSF entities to help the license provisioning and ensure projects are onboarded to use it appropriately.

Who is accountable for doing the work of this funding initiative?

OpenSSF TAC

If the responsible or accountable parties are no longer available, what is the backup contact or plan?

The OpenSSF TAC may reassign ownership to another active OpenSSF Golang project maintainer.

What license is this funding initiative being used under?

N/A – this is not a code funding request.

Code of Conduct

• [x] I agree to follow the OpenSSF's Code of Conduct

List the major milestones by date and identify the overall timeline within which the technical initiative plans to accomplish their goals. Any payments for services, sponsorships, etc., will require LF Legal and Financial review.

By the end of Q2'25: License purchased and provisioned for OpenSSF automation usage.

Beginning of Q3'25: Nightly builds and CI release pipelines begin to adopt GoReleaser Pro features for reproducible testing across OpenSSF Golang projects.

If this is a request for funding to issue a contract, then OpenSSF will issue that contract. Please provide a Statement of Work (SOW) that we may review. Any contracting action will take 4-6 weeks to issue.

No Statement of Work (SoW) is required.

[steiza]

/vote

[git-vote[bot]]

Vote created

@steiza has called for a vote on [Technical Initiative Funding Request]: GoReleaser Pro access for OpenSSF Projects (#475).

The members of the following teams have binding votes:

Team
@ossf/tac

Non-binding votes are also appreciated as a sign of support!

How to vote

You can cast your vote by reacting to this comment. The following reactions are supported:

In favor	Against	Abstain
👍	👎	👀

Please note that voting for multiple options is not allowed and those votes won't be counted.

The vote will be open for 14days. It will pass if at least 55% of the users with binding votes vote In favor 👍. Once it's closed, results will be published here as a new comment.

[steiza]

This is an interesting idea. Do we know who else uses goreleaser specifically in OpenSSF? It's a bit difficult to search across the organizations that OpenSSF projects are, but I was able to find Scorecard, Criticality Score, and Sigstore projects that use it. Are there other folks who would use this as well? Does the Linux Foundation already have a GoReleaser Pro subscription?

After the TAC vote, we'll have to work with staff to figure out budgeting. A recurring expense like this would probably not fall under the TI funding budget item and need to come from elsewhere in the OpenSSF budget - but staff can help us work that out.

[brandtkeller]

It is a difficult one to query given all the disparate GitHub organizations. Nonetheless of the projects listed under I can immediately point to minder, guac, bomctl, gittuf, and openvex. There are a few other projects that could utilize it but do not produce releases to-date.

I would love to hear if the Linux Foundation already has a subscription. Understood on this being a recurring cost and maybe not fitting TI funding.

[mlieberman85]

I'm in favor of this other than what @steiza brought up about the "recurring spend" bit. I will say that I know a lot of the recurring spend concerns were focused more on things like cloud spend, recurring support costs, etc. This seems a little tangential to it, but probably still requires some guidance from staff on how we implement this right.

[gkunz]

Having the capability to run proper nightly builds is a great benefit for a relatively low cost. I support this and would argue for moving this item into an "operational costs" category rather then TI funding - in particular if the license benefits multiple projects.

[git-vote[bot]]

Vote status

So far 33.33% of the users with binding vote are in favor and 0.00% are against (passing threshold: 55%).

Summary

In favor	Against	Abstain	Not voted
3	0	0	6

Binding votes (3)

User	Vote	Timestamp
gkunz	In favor	2025-04-28 9:19:56.0 +00:00:00
mlieberman85	In favor	2025-04-24 22:52:03.0 +00:00:00
steiza	In favor	2025-04-25 12:15:52.0 +00:00:00
@justaugustus	Pending
@scovetta	Pending
@bobcallaway	Pending
@lehors	Pending
@marcelamelara	Pending
@camaleon2016	Pending

[marcelamelara]

I'm supportive of funding a GoReleaser Pro license (provided that the LF doesn't already have one), and turning this into a recurring expense. IMO, the TI funding request is a good way to raise the need to the TAC and staff.

[camaleon2016]

I'm supportive. I'd like staff to give us an idea of budget and constraints, if any, prior to voting. What would need to be dropped, etc?

[cipherboy]

This is an interesting idea. Do we know who else uses goreleaser specifically in OpenSSF?

While not yet here (see #461), OpenBao uses goreleaser and has been interested in the Pro version for a while as it'd make it possible to do release validation testing prior to publishing.

[git-vote[bot]]

Vote closed

The vote passed! 🎉

66.67% of the users with binding vote were in favor and 0.00% were against (passing threshold: 55%).

Summary

In favor	Against	Abstain	Not voted
6	0	0	3

Binding votes (6)

User	Vote	Timestamp
@marcelamelara	In favor	2025-04-28 16:34:17.0 +00:00:00
@scovetta	In favor	2025-04-29 15:14:38.0 +00:00:00
@gkunz	In favor	2025-04-28 9:19:56.0 +00:00:00
@steiza	In favor	2025-04-25 12:15:52.0 +00:00:00
@mlieberman85	In favor	2025-04-24 22:52:03.0 +00:00:00
@lehors	In favor	2025-04-28 13:37:30.0 +00:00:00

[brandtkeller]

Checking back in - curious if there are any updates or movement on progressing with this initiative request?

Thank you!

[kj-powell]

Thanks for checking in! Apologies for this going on so long. We are connecting with LF legal due to GoReleaser Pro being a closed license. We will hopefully have an update for you all in a week.

[kj-powell]

Update: we were asked to go through an additional level of approval, so we are still waiting for approval. Apologies for the long wait!

[afmarcum]

Approved by GM.

[kj-powell]

License key sent to Brandt

[bobcallaway]

@kj-powell as Sigstore also uses go-releaser, could we get access to this key

[cipherboy]

@kj-powell Same for OpenBao if that's alright!