TRL support for Status

[adulau]

Did you evaluate the option to use the TRL level for the Status?

[bfabio]

Hi @adulau, I was not familiar with it before.

My impression is that TRL comes from a research. status in publiccode.yml is intentionally much simpler to just answer a very basic question: is it usable or not.

Do you see any particular benefit compared to the current status values?

[adulau]

Thanks for the feedback. Indeed the basic question is super important if the project is usable or not.

Now the point is more to know the level of usability of an open source project. We did some mapping already and plan to find metrics on git repositories to assign a TRL level. Here is current mapping of TRL and open source project (still very early):

TRL Level	TRL Name	Typical Open Source Project State	Usability Level (for Users)	Indicators in an Open Source Context
TRL 1	Basic principles observed	Idea, research notes, or early concept	Not usable	Whitepapers, discussions, research repo, no runnable code
TRL 2	Technology concept formulated	Initial architecture or proof sketches	Not usable	Design documents, experimental branches, incomplete prototypes
TRL 3	Experimental proof of concept	Proof-of-concept implementation	Usable only by developers	Minimal code, manual execution, no packaging, unstable APIs
TRL 4	Technology validated in lab	Early prototype	Very limited usability	Runs locally, partial documentation, frequent breaking changes
TRL 5	Technology validated in relevant environment	Functional prototype tested by early adopters	Usable by technical users	Installation instructions exist, example datasets, early feedback loop
TRL 6	Technology demonstrated in relevant environment	Beta-stage open source project	Moderately usable	Releases published, issue tracking active, partial automation, growing community
TRL 7	System prototype in operational environment	Production pilot deployments	Usable by practitioners	Stable core features, upgrade path, CI/CD, real-world users
TRL 8	System complete and qualified	Mature open source software	Highly usable	Good documentation, packages/containers, API stability, security practices, contributor guidelines
TRL 9	Actual system proven in operation	Widely adopted, production-grade open source ecosystem	Very high usability	Large user base, governance model, long-term maintenance, integrations, ecosystem tooling

[bfabio]

Uhm, interesting. The TRL levels map pretty closely to the current values:

TRL	developmentStatus
1-2	concept
3-4	development
5-6	beta
7-9	stable

WDYT about simply using this mapping to convert between the two?

[libremente]

Uhm, interesting. The TRL levels map pretty closely to the current values:

TRL developmentStatus
1-2 concept
3-4 development
5-6 beta
7-9 stable
WDYT about simply using this mapping to convert between the two?

Yes @bfabio, we considered the TLR levels back in the days (also because some italian providers actually use it) but we opted to use a more "user friendly" approach. Since it's a recognized standard it makes sense to adopt it but I don't understand your proposal though, you want to put this mapping in the docs and leave the specification as it is or you want to implement this standard in the publiccode.yml?

[bfabio]

@libremente just to be clear, I wasn't proposing a change to the spec. I was just thinking that if @adulau needs TRL, they could maybe map it from softwareStatus: it's coarser, but it maps 1:1 and might work for their use case?

[libremente]

@libremente just to be clear, I wasn't proposing a change to the spec. I was just thinking that if @adulau needs TRL, they could maybe map it from softwareStatus: it's coarser, but it maps 1:1 and might work for their use case?

Ok! Makes sense, thanks for the clarification 👍