PQCA yearly project life cycle review

[praveksharma]

As per PQCA's Project Lifecycle Policy we are due to review OQS's project lifecycle status and present this at the next TAC meeting on 16 July 2025 (please see https://pqca.github.io/TAC/Processes/Project_Lifecycle.html for more information). This lifecycle status will apply to all of Open Quantum Safe, so liboqs, oqs-provider, oqs-openssh, oqs-boringssl, etc. will have the same lifecycle status. The OQS TSC can choose to vote for each sub-project to have its own lifecycle status, however, the lifecycle status for sub-projects would then need to decided upon in addition to a broader OQS project lifecycle status.

A PQCA project's life cycle status can be one of following:

• Research projects:

  1. Experimentation stage
  2. Labs stage

• Production projects:

  1. Incubation stage
  2. Growth stage
  3. Impact stage
  4. Emeritus stage

While the Research and Production tracks are meant to be largely separate neither label implies code quality properties or usage recommedations; a project can switch between tracks with TAC approval.

Both the Experimentation stage and Incubation stage don't have explicit qualifying criteria but come with the caveat that such projects will recieve "minimal support from the Foundation".

Here are the qualifying criteria for a Labs stage project:

    - Have a defined governing body of at least 5 or more members (owners and core maintainers), of which no more than 1/3 is affiliated with the same employer. If there are 5 governing members, 2 may be from the same employer.
    - Have a documented and publicly accessible description of the project’s governance and decision-making.
    - Identify a minimum set of metrics the project proposes to use to signal project health and maturity. The TAC will use these to evaluate the proposed change in stage and continued health and maturity of the project within their stage. Examples include organizational dependency, commit activity, or other code ownership metrics.
    - Have a clear explanation of the project governance and committer process, which are explicitly defined in the technical charter, that is easy to understand for new participants. These are preferably laid out in a GOVERNANCE.md file and reference a CONTRIBUTING.md and OWNERS.md file showing the current and emeritus committers.
    - Have a public list of research use cases for at least the primary repo (e.g., ADOPTERS.md or logos on the project website).
    - Have a stable API and documentation as to API change procedures
    - Other metrics defined by the applying Project during the application process in cooperation with the TAC.
    - Receive a two-thirds supermajority vote from the TAC to move to the Labs Stage.

and those for a Growth stage project:

    - Develop a growth plan, which will be done in conjunction with their project mentor(s) at the TAC.
    - Document that it is being used successfully in production by at least two independent end users who are of adequate quality and scope in the TAC’s judgment.
    - Demonstrate a substantial ongoing flow of commits and merged contributions.
    - Have a stable API and documentation as to API change procedures
    - Demonstrate that the current level of community participation is sufficient to meet the goals outlined in the growth plan.
    - Since these metrics can vary significantly depending on a project’s type, scope, and size, the TAC has final judgment over the level of activity adequate to meet these criteria.
    - Receive a two-thirds supermajority vote of the TAC to move to the Growth Stage.

I would like to solicit the OQS community's thoughts on this matter and continue the discussion into the status call scheduled for 08 July 2025.

[dstebila]

For additional context, here is the corresponding discussion at PQ Code Package.

[dstebila]

Flagging this for renewed discussion from @open-quantum-safe/tsc in preparation for next Tuesday's TSC meeting.

While I understand the desire for OQS to go in the Growth stage project, I am concerned right now about what we would be putting in a growth plan, and in particular whether our current (somewhat decreased) level of participation will meet the fifth criteria in the Growth stage description: "Demonstrate that the current level of community participation is sufficient to meet the goals outlined in the growth plan."

[baentsch]

Allow me to completely second that: OQS should not be tagged "Growth", for many reasons: One is the lack of participation Douglas mentions, second is the (drop in) level of functionality: At least oqsprovider already lost some (e.g., composite support) and is on the path of losing further capabilities (if I understand @asman-p's redesign proposal correct to drop its PQ-algorithm "agnosticity").

And to be brutally honest, I don't think OQS should be in the "production track" of PQCA's life cycle document to begin with (and surely not in the "Growth" stage): OQS has been very successful as a tool by researchers for researchers. I personally would love to see it return to that value. Two years passed since LF & IBM suggested taking over OQS, more than one year since that happened and nothing has changed in terms of more production-oriented people taking up the baton from the researchers that carried the torch this far -- as per the above, to the contrary, actually.

I also understand there is desire to label OQS "productive" and "Growth" -- but I beg the people asking for that to consider these questions:

1. Is is right to label software as "production track" if it is used in production by some folks but never has been designed for that purpose? And to the contrary and for good reason, carries strong advice against such use?

2. Is it really so undesirable for PQCA to promote and support research (with OQS in that very track)?

3. Are there really no truly productive PQC OSS software solutions that PQCA could rather support in that track? I personally can think of several.

Allow me to urge everyone pushing the desire Douglas mentions above to read (better, even contribute to) the OQS code base -- and compare it with truly productive code bases and the process with which software in such code bases is developed and vetted: You will see a substantial difference in every regard. I personally witnessed both approaches first hand. I do understand that this experience is literally not as valuable as the marketing budget spent by PQCA sponsors, but it is everything I can bring to the table. I urge everyone reading to consider the possibility that something may be amiss here: What is better: Risk OQS being mediocre (or worse, not any more contributed-to) software not achieving either, research or production utility OR focus OQS on being an excellent research tool again -- that may influence with knowledge and maybe code components productive code?

For all these reasons, I'd urge everyone to add to my vote moving OQS onto the research track, Labs stage.

[ashman-p]

I agree with the current assessment that OQS is solidly at Labs stage and more . I also support and respect that OQS began as a research vehicle and that this is the major purpose. I believe research should remain the major focus of OQS.

It should also be acknowledged that OQS is already being integrated and used in industry. This fact is another affirmation to the relevance and impact of OQS. For these reasons, I am also a proponent for some aspects of OQS to progressively move towards Growth stage, at the appropriate time and with the necessary resources. Such an indication has the potential to facilitate broader engagement and foster increased support and contributions.

In summary, the project status is Labs. As time and resources permit, the project should look to engage the industry focused community where possible.

[baentsch]

Thanks very much, @ashman-p ! This designation would resolve one of the big headaches I had with the project in PQCA: An "over-eager" declaration of utility.

It should also be acknowledged that OQS is already being integrated and used in industry.

Agreed, this could be acknowledged -- in a tacit manner, though: OQS --IMO for good reason-- still advises against "unthoughtful" industry use (at least to those companies not already contributing regularly and thus knowing the true state of code). And for oqsprovider, I absolutely and resolutely advise against such use knowing (having written :) most of its code -- and personally knowing at least one FOSS code base much better geared for industrial use (OpenSSLs).

May I further suggest bringing this acknowledgement in line with the current efforts to find more contributors -- not just from research, but also from industry? May it be a fair ask particularly those companies already deploying OQS to reciprocate by actively contributing?

As to "what" to contribute: The TSC yesterday discussed such "new contributors" push -- plus one to describe all open issues in an easy-to-digest manner: May I suggest tagging issues that could particularly benefit from industry contributions? I think in the call, the proposed --but not quite well-liked-- tag was "no math required"? What about adding the tag "industrialization" instead? Such issues could also be created based on the properties of already existing PQC software, that way making it clear which gap still needs to be filled -- and checking whether it'd be widening over time (as is my expectation: Hence my strong argument for favoring work in support of (other) research(ers) such as to stay on top first and foremost in that realm).

[bhess]

I also agree with the assessment of OQS being at the Research/Labs stage.

Since OQS relies on upstream implementations for most algorithms, the maturity of those implementations is another key factor in evaluating it. Naturally, algorithms still in early stages of standardization will not fall under the production category. That said, we do use mlkem-native, which self-identifies as being in the Production/Growth phase. I believe this kind of upstream maturity will be a prerequisite for a potential future reclassification of OQS.

[baentsch]

Thanks also for your support @bhess for this designation! I do agree with the need to have a clear pedigree of (and active support by) the algorithm sources. There's actually many issues open to bring this about: #1928, #2064, #2184 just to list the first to come to mind.

Unfortunately, that is not enough: As soon as any code in OQS "touches upon" key material and/or operates it, that code also needs more thorough vetting if "industrial" use of any OQS API shall be possible. And again, particularly oqsprovider is a big problem in this regard: I know it's by many just considered a project appendix but it carries quite a lot of code (that can be wrong). Possibly my fault, but then again, it has to adapt to two APIs: The one of liboqs and the one of openssl, whereas liboqs has been created as a wrapper around the existing NIST API offering its own API, so conceptually much cleaner and simpler.

[baentsch]

@dstebila What's the current "procedure" then? Given the above, can we consider this settled (OQS in Research track, Labs stage) or would you want to do a separate vote in the TSC? I see open-quantum-safe/tsc#12 has not been resolved and you removed your assignment, though (?).

[dstebila]

My plan had been to carry out a vote on Github. Indeed we have not resolved open-quantum-safe/tsc#12. My intention would be to create a pull request in the TSC repository adding a file called project_lifecycle.md to the governance folder with a brief statement covering the relevant points from this discussion. I would leave the PR as a draft for a couple days to see if anyone wants to suggest any changes, and then make a normal PR and request review from the TSC; once a majority excluding me has approved, it would be considered passed and I would merge it. How does that sound? I think this is in agreement with the OQS charter and with the sentiments expressed in tsc#12. Assuming it goes well, then we could also write down this procedure to finally resolve that longstanding TSC issue.

[dstebila]

This has been resolved via open-quantum-safe/tsc#198.