Meeting Minutes: Board and TAC Monthly (2026-01-26)

Below are the minutes from the recent TAC and Board of Directors meeting. Everyone is encouraged to review the minutes and actively participate in the discussion. This is an opportunity to talk directly with TAC members by replying in the thread below. Your input helps ensure the OpenSSL community remains transparent, collaborative, and responsive to your needs.

Attendees

@Aditya Koranga, @Anton Arapov, @Dmitry Belyavsky, @Hana Andersen, @Lenka Luklova, @Nicola Tuveri, @Tim Hudson

High-level topics covered

• Issue and PR intake, prioritisation, and escalation processes

• Fairness and transparency in handling community vs. commercial requests

• Performance, scalability, and benchmarking gaps

• Provider architecture, ABI stability, and long-term technical debt

• Rust providers, external projects, and ecosystem alignment

• Supply chain / SBOM discussions and Large Business Community (LBC) inputs

• Release cadence and major-version planning

Detailed points and discussion

1) Issue intake, prioritization, and escalation

The group discussed shortcomings in how issues and feature requests are evaluated and prioritized. There is no clear mechanism to signal broad community or commercial interest in an issue, leading to uneven outcomes. Concerns were raised that contributors with existing relationships receive faster attention, which discourages new participants. A draft escalation and intake document was shared for review, describing how public and commercial issues should be handled and escalated. Emphasis was placed on not just defining the process, but executing it consistently.

https://docs.google.com/document/d/15W_HELRhvokmpGHQ2t6GUqBl9RbFTaVqDvbv3cfeoYM/

2) Community fairness and contributor experience

Participants agreed that the OpenSSL Project needs clearer, more predictable processes so first-time contributors are treated consistently and do not need personal relationships to make progress. Better signaling, documentation, and execution were identified as key to improving trust and reducing frustration.

3) Performance and scalability measurement

Anton raised concerns that OpenSSL performance discussions often focus on absolute numbers rather than scalability and predictability under load. External benchmarks (e.g., rustls) highlight gaps in how OpenSSL Library measures and communicates scalability. The group noted that current dashboards are primarily used to detect regressions, not to drive improvement. Meaningful progress would require explicit investment in tooling, benchmarks, and resources.

4) Providers, ABI stability, and versioning

The group discussed expectations that provider ABI should remain compatible across major versions, and concerns about module directory versioning. It was agreed that preemptive changes are unnecessary unless ABI is intentionally broken. Dmitry will raise an issue to clarify requirements and explore options (e.g., module paths vs. directories) without committing to immediate changes.

5) Rust providers and ecosystem alignment

Nicola and others discussed the current state of Rust-based providers, scaffolding, and examples. While providers written in Rust are feasible today, any OpenSSL Library-affiliated project should demonstrate real-world applicability beyond proof-of-concept. There was openness to hosting or supporting such projects if they align with the OpenSSL Project’s mission and are maintainable.

6) Supply chain / SBOM and LBC inputs

Anton reiterated that OpenSSL Project is looking for concrete SBOM proposals from large companies rather than defining solutions internally. A summary of LBC requests was shared to raise awareness of emerging technical and policy topics. The TAC is encouraged to review these inputs for technical relevance.

https://openssl-communities.org/d/ujSDx4YA/summary-of-lbc-requests-for-openssl-board

7) Release cadence and major versions

Tim reiterated the existing approach of regular major releases (approximately every two years) as a necessary way to enable breaking changes and manage long-term technical debt. The discussion emphasized that this cadence requires disciplined engineering planning, overlapping development cycles, and earlier investment in post-release work. This was a restatement of the current operating model rather than a new proposal.

Decisions / Agreed actions

• TAC Members: Review and comment on the draft issue escalation and intake document.

• Dmitry: Open an issue to clarify provider module path/versioning concerns and desired behavior.

• TAC members: Review LBC summary items and SBOM-related inputs for technical relevance.

Next meeting

Planned for February 9, 2026 (UTC).