(I recently attended Open Source Summit in Vancouver, and this issue is based on a convo with Anne Bertucio from Google, who directed me to post an issue here. Apologies in advance if there is a better place / better way to go about sharing this feedback!)

Context: I'm a long-time core maintainer and general cat herder of the Drupal open source project, a member of their security team, and a general security enthusiast since the alt.2600 days. I sort of accidentally learned about OpenSSF's existence last year (and also accidentally learned we are deemed a "critical project"), and since then have spent a few weekends digging around the website and reading a whole bunch. I've attended a couple of town halls, and attended the morning of OpenSSF Day a couple of weeks back. I would rate my knowledge about open source maintainership 9/10, my OpenSSF knowledge maybe 3/10.

So with that in mind, gulp, here goes. :)

---

Problem Statement

Right now, OpenSSF's activities are presented in a way that is congruent with other Linux Foundation projects: there's a strong focus on the how the OpenSSF is structured, how the governance works, how it is run day to day, what are the recent achievements, and so on. All of that makes total sense, through the lens of being a member-driven Linux Foundation project, and wanting to demonstrate your value to prospective members.

However, by and large, open source maintainers:

• Have very little time for "extracurricular activities" beyond their maintainer responsibilities, since they are often balancing these with a job and a family
• Therefore, tend to "silo" into their own projects, their own community, and their own problems, by necessity
• Therefore, be broadly unaware of OpenSSF's existence — if they go to events, and have $1000 to spend on a ticket, they will tend to attend something like DrupalCon, not something like Open Source Summit
• Once learning of OpenSSF's existence, they will have very little time to dig through information (including terms/acronyms they may not already be familiar with, such as "SBOMs") to answer the question "What are the problems you solve for my project and how do I partner with you?"
• When they attempt to answer this question based on the available information, they'll see a lot of evidence of how OpenSSF helps enterprises, governments, etc. and their customers, but not a lot of information of how it helps them as an everyday maintainer. (They may in fact leave with the opposite impression, that the OpenSSF exists to make their job harder, in order to please enterprises / customers :\ — see the blow-up when YubiKeys were distributed to maintainers of all the top Python projects, for example.)

Objectives

Taken together, it seems like in order for OpenSSF to broadly win the "hearts and minds" of maintainers, there needs to be focus on (at least) the following things:

• We need to meet maintainers where they are in order to raise awareness of OpenSSF.
• We need to ensure they achieve this understanding in as little time as possible.
• We need to present the activities of OpenSSF in a pain point/solution-focused way, to help make our benefits tangible and demonstrate empathy with their needs.
• We need to ensure there's proactive, ongoing engagement with maintainers and their projects; "once and done" is too easy to get buried under the day to day demands.

(This effort could dovetail nicely with the work going on in #165)

Proposed Solutions

There are many ways to go about this, and I'm sure you would know better than me what makes sense :), but here are some initial thoughts:

"Maintainer Experience" Working Group

Create an OpenSSF Working Group specifically around maintainers and their needs (similar to the End Users group, but for the producers of open source).

This could also manifest as something similar to the TAC but a committee made up of maintainer representatives. (Just watch the time commitment.)

Dedicated "Landing Page" Specifically Aimed At Maintainers

For example, some sort of "call to action" on the OpenSSF website "Maintainer? Click here!" and/or maybe repurpose https://github.com/openssf (which currently appears empty) for this purpose?

The contents of this page would be geared toward maintainers and their pain points, rather than oriented around how OpenSSF thinks of them. (I can assure you that maintainers don't care whether something is a working group or a project ;)).

For example:

• Want to learn best practices in secure coding? Take our free training.
• Interested your project being automatically scanned for vulnerabilities? Learn more about Alpha-Omega
• Want to ensure your end users are getting the software distributed to them that they're counting on? Check out Sigstore.
• ... (etc.) ...
• Want to talk to us to find out more? Join a dedicated Slack channel

Oh, speaking of which...

Dedicated Slack Channel (+Mailing List?) Aimed At Maintainer Relations

Upon joining OpenSSF Slack I was blown away by the calibre of people there. :O However, if I was entering that space as a maintainer, I would quickly reach the conclusion that this is not a space for me, because the vast majority of conversation in there is about promotion/enablement of OpenSSF itself, the Working Groups' day to day toils, etc.

So some sort of dedicated channel(s) where maintainers can come in, introduce themselves, ask questions related to OpenSSF's activities, get answers from someone, meet and network with other security-conscious open source maintainers. Maybe also a corresponding "Maintainer Office Hours" meeting folks could join, and periodic "What is openSSF for maintainers" onboarding sessions (could re-use these at events).

Forge Partnerships With Open Source Security Teams

Open source security projects' teams are overwhelmed and exhausted. Having partnership from an organization like OpenSSF would be a huge shot in the arm, and an excellent, pragmatic way to demonstrate OpenSSF's value in a way maintainers can fully understand.

What could this look like? Maybe a set of "tiger teams" grouped by programming language who prioritize projects with massive ecosystems, helping them to implement things like sigstore, teach best practices like CVEs, etc.

Go Where Maintainers Are

In each of the critical projects (once again, probably starting within those with massive ecosystems, such as Python), figure out where those maintainers congregate in "real life" (PyCon), and go there. Even better: co-present with the security maintainers from the previous step; now you have automatic credibility within that community, and a reason for people to show up to your talk.

Assume Zero Knowledge In Community Events

In Town Halls, OpenSSF Day, etc. always assume someone in the audience is hearing about OpenSSF for the first time (if you're doing lots of outreach, they probably are!). The first time you use terms like "SBOM" define for people what that is (and/or have a handy glossary page that's distributed ahead of time). When someone gives a status update on Sigstore, give 30 seconds of context as to what that is and why it's important.

Without this, the risk once again is giving off the strong vibe that OpenSSF is for "insiders" and not for maintainers themselves.

Thoughts?

Haha, sorry for the novel, apparently there was a lot to say. ;) Does the problem statement ring true to you? Is there already an initiative underway in OpenSSF that maintainers interested in smoothing these sorts of partnerships could join and participate in? Is this far out of what OpenSSF sees as their mission and better for some other group to tackle?

Very curious of your thoughts!

Thank you for taking the time to not only report the problems you are seeing but also make concrete suggestions on how we might go at addressing them. This is very valuable!

We do have one WG that is maintainers oriented: Securing Software Repositories https://github.com/ossf/wg-securing-software-repos

Have you looked into this? I'm curious to know whether you didn't run into it (which wouldn't surprise me, there is a lot going on and it's not easy to know what's out there) or if you know about it but didn't think it fits the bill. If so, why?

Thanks again!

@lehors - Securing Software Repositories is definitely worth looking at. However, that WG focuses on "maintainers of software repositories, software registries, and tools", e.g., PyPI/pip, npm, RubyGems/bundler, system software registries / {apt-get,dnf}. So that WG does not directly apply to the maintainers of most OSS projects. Of course, most widely-used OSS projects end up in some repo, so a typically OSS maintainer would want them to work well, but that's not the same thing.

The best practices WG generates a number of guides & materials specifically for maintainers, and I think that's the closest match at this moment... but it often focuses on work we're doing, not "here are finished products you can use".

There are a lot of interesting proposals here! A "landing page" for maintainers, in particular, sounds like a great idea to me. We could point to our guides, the education materials, sigstore, etc.

I think that the “maintainer/developer” persona is one of the core foci of our stalwart band of security-friends. I love the idea of a landing page, and materials dedicated to helping kickstart or assist a developer in their personal security journey. I agree with David, the BEST WG feels like a slightly better fit, and we even can augment some of our targets for the EDU.SIG to address getting materials composed/collated/presented for this group.

Cheers,

CRob Director of Security Communications Intel Product Assurance and Security

From: David A. Wheeler @.> Sent: Tuesday, May 30, 2023 9:47 AM To: ossf/tac @.> Cc: Subscribed @.***> Subject: Re: [ossf/tac] Proposed Initiative: "Maintainer Experience" of OpenSSF (Issue #169)

@lehorshttps://github.com/lehors - Securing Software Repositorieshttps://github.com/ossf/wg-securing-software-repos is definitely worth looking at. However, that WG focuses on "maintainers of software repositories, software registries, and tools", e.g., PyPI/pip, npm, RubyGems/bundler, system software registries / {apt-get,dnf}. So that WG does not on the maintainers of most OSS projects. Of course, most widely-used OSS projects end up in some repo, so a typically OSS maintainer would want them to work well, but that's not the same thing.

The best practices WGhttps://github.com/ossf/wg-best-practices-os-developers generates a number of guides & materials specifically for maintainers, and I think that's the closest match at this moment... but it often focuses on work we're doing, not "here are finished products you can use".

There are a lot of interesting proposals here! A "landing page" for maintainers, in particular, sounds like a great idea to me. We could point to our guides, the education materials, sigstore, etc.

— Reply to this email directly, view it on GitHubhttps://github.com/ossf/tac/issues/169#issuecomment-1568467090, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AQRFDLD37V47WIYKFUEZMGLXIX26FANCNFSM6AAAAAAYS7XDVU. You are receiving this because you are subscribed to this thread.Message ID: @.@.>>

Right, echoing some of the other comments here:

• My understanding of https://github.com/ossf/wg-securing-software-repos is they would be engaging more "upstream" from a typical open source maintainer/developer. In the Drupal world, it seems like the types of folks they would engage would be our Drupal.org infrastructure team (~5 people) who manage our GitLab instance and maintain various packaging scripts. Not the 30K module maintainers writing Drupal code who are the ones actually creating the security problems in the first place. ;)

• https://github.com/ossf/wg-best-practices-os-developers indeed seems like a closer fit, but the "problem" (and again, this is not a problem per se, but a lack of alignment in needs for this specific audience) is the README there is very focused on "how the working group gets things done," what's the broader, holistic approach they're taking to achieving their aims, and their Slack channel (as is common with all of the WG Slack channels) consists mostly of a lot of "tactical" chatter amongst the WG members about rescheduling meetings or setting GitHub permissions, vs. a bunch of conversations with open source maintainers themselves, sharing best practices/advice to them directly.

Does this distinction make sense?

Also, thank you so much for taking the time / effort to read and consider this, and also for your patience as I muddle my way through an unfamiliar process. :)

My understanding of https://github.com/ossf/wg-securing-software-repos is they would be engaging more "upstream" from a typical open source maintainer/developer. In the Drupal world, it seems like the types of folks they would engage would be our Drupal.org infrastructure team (~5 people) who manage our GitLab instance and maintain various packaging scripts. Not the 30K module maintainers writing Drupal code who are the ones actually creating the security problems in the first place. ;)

As chair of this WG, +1, absolutely right!

We are VERY happy to have you participating to make our efforts more accessible for everyone! Thank YOU, Angie!!

Ok, I can see how the Best Practices WG might be a better fit. This WG has primarily been oriented towards developing material like guides though. I wonder what's better: focus that WG more towards the maintainers needs as described by @webchick or create a new WG dedicated to just that.

But for that matter I agree with the idea of adding a dedicated landing page idea and in fact it will help people find their way to whichever WG we decide is where they should go. :-)

I think the persona (to issue #165) with the problem @webchick describes is a bit different than the Best Practices WG. As I understand it, Best Practices WG is about content development for the 100k+ developers writing code that's open source, and not knowing they should do something like set up GitHub Branch Protection from the get-go.

This seems to be about what and how the OpenSSF helps an "OSS Core Maintainer." For example, sigstore was set up for Kubernetes because lead participants of the relevant k8s SIG were interested and kicked it off. That kind of difference makes me think this is a new effort (which ties into similar "maintainer/contributor experience" problems the @ossf/governance-committee has been discussing, so I think we've got some kismet here...)

As additional endorsement on the need for this, when the OpenSSF Maintainer Workshop was held (invite only, small audience and also whose intent was to learn and capture these sentiments), the need articulated here, the observations and experience summarized are all key points that arose in those discussions.

Unfortunately (like many things) the volunteers who worked to execute the event where very limited in their time and couldn't commit to provide a comprehensive analysis and write up from all the notes we captured (even though we really wanted to) - but we did capture notes that would potentially be beneficial as an initial gauge on interactions and engagement with maintainers. @SecurityCRob and @bobcallaway were both excellent Moderators in those discussions. Those notes still exist but will need scrubbed a bit as the event was under Chatham House Rules. Once that is done it could be provided publicly.

If you were part of that effort, please let me know if anything i stated is misrepresented as my participation was time-limited and i may not have the follow-on actions correct.

As a maintainer of open source that has been looking at the OpenSSF for quite some time now, I will support what @webchick said.

Most of the "best practices" presented by the OpenSSF are, quite directly, a no-go. At this point, I have written off all that comes out of the OpenSSF and the wider "securing supply chain" ecosystem as "the classic infosec that never matters for us or tries to help us" and I am not alone, most of the maintainers I know have made this analysis too.

I want to be clear. I am not saying that because I want to take down the OpenSSF. I say that to give you real feedback from the ground that what @webchick is doing is being really nice to tell you that, in its current shape and operation, the OpenSSF did not manage to talk to "weekend warriors" maintainers and did not manage to set roots in these communities.

Her recommendations and the work on personas are definitely a path to getting better results there. Note in particular that k8s is definitely not representative of the "weekend warrior" persona as a group of maintainers and contributors 😄 They do a great job, just really different persona.

I'll loop Katherine Druckman in today during the Governance committee meeting. She is helping lead our new DevRel committee that seems to be an excellent place to address @webchick 's observations and concerns. BEST WG will be glad to collaborate on assisting to advocate for the developer/maintainer perspective, and we'll seek to get other groups to participate too.

I also come to OpenSSF from a maintainer perspective. I'd be happy to participate in follow-up work.

All: Here's cut at a "Developer landing page": https://best.openssf.org/developers

Suggestions welcome.

We could link to it from the top-level openssf.org page if we think it's useful.

This page does not resolve this issue, but I think it's a step on the path.

FYI, there's a best practices WG issue to vote to post the "developer landing page" on the main OpenSSF website: https://github.com/ossf/wg-best-practices-os-developers/issues/195 That doesn't resolve all the issues noted here, but it's a step in that direction.

This page does not resolve this issue, but I think it's a step on the path.

Agreed, this is a great start. Could we also link to s2c2f? Or perhaps we want a separate "for organisations" page that would link to s2c2f? 🤔

related to https://github.com/ossf/tac/issues/84

At this point, I have written off all that comes out of the OpenSSF and the wider "securing supply chain" ecosystem as "the classic infosec that never matters for us or tries to help us" and I am not alone, most of the maintainers I know have made this analysis too

To be fair the fuzzing branch is actually useful. They actually talk to actual maintainers, try to cover even unusual use cases (if it's doable) and so on. Unfortunately snapshot fuzzing (or any other custom stuff tailored to specific projects) is unlikely to ever be supported there but it isn't the end of the world if people fuzzing projects have their own clusters. That being said that branch existed long before OpenSSF was created so it's probably safe to say that it isn't representative of OpenSSF in general.

a bit different than the Best Practices WG. As I understand it, Best Practices WG is about content development for the 100k+ developers writing code that's open source

Agreed. That WG group appears to operate on the assumption that everyone is uneducated and has no clue what they are doing and that sort of attitude isn't exactly helpful if the idea is to win the "hearts and minds" of maintainers.

I'm not sure the proposed solutions can work as long as the "consumer" persona is much more important to OpenSSF but it's good to know that it's at least trying to move in the right direction.

make our efforts more accessible for everyone

It would be great if it was possible to download things like https://openssf.org/soss-vision-brief/ without filling out those forms.

I think the WGs that work on Scorecard and the Badge don't entirely agree on their purpose and meaning, and I personally don't agree at all with the consensus, yet I use these almost every day. What isn't useful is the idea of an objective quantity of security, because the accuracy is too low to make a big difference.

What is very useful is guiding my roadmap as a security TPM for FOSS projects. I treat the criteria as checklists. By running the metrics I figure out what I do and don't need to work on. For example, this month I am cleaning up CodeQL alerts as a result of working through https://bestpractices.coreinfrastructure.org/en/projects/6358#analysis and getting a failing score on the static_analysis_fixed metric.

What I would want from the WGs is to reframe their outputs as a guide for security-related workflows. For example there could be a Kanban template with the first swim lane prefilled with cards corresponding to metrics. I have something similar for OpenChain, which has a comparable role for getting an OSPO organized.

What I would want from the WGs is to reframe their outputs as a guide for security-related workflows

Agreed. I think the problem is that they were never designed to be integrated into maintainers' workflows. Up until recently scorecard just dumped json and ignored maintainers' feedback completely. The human-friendly UI was added eventually but it took a weird amount of time and at least one critical project planning to throw scorecard out. The scorecard action is useless in terms of actually preventing issues and so on.

(In theory this discussion can be moved to the corresponding bug trackers but I don't think it's going to be addressed. They no longer auto-close issues though so at least it can be kept there)

Agreed. That WG group appears to operate on the assumption that everyone is uneducated and has no clue what they are doing and that sort of attitude isn't exactly helpful if the idea is to win the "hearts and minds" of maintainers.

That is not accurate. The group works under the assumption that there are multiple levels of "learners" and consumers of OSS. The three main developers we think about are beginners/people that are new to the trade, people that are changing careers into development, and existing experienced developers. The current available class focuses on beginning software engineers (although more experienced developers could benefit from that content as well as they may have not been exposed to it before). There are materials being developed on intermediate and advanced development topics that will be available in the future. Patches, RFEs, and comments are always welcome by the group for new projects to help the community.

The other materials the group has produced (Concise Guides, SCM Guide, C/C++ Guide) are usable by any developer, operator, or consumer of open source.

The Scorecard project is currently working on making integrating the checks in a more user-friendly manner for devs and consumers amongst a host of other bug fixes and enhancements. You can check out their current backlog here: https://github.com/ossf/scorecard/issues

What is very useful is guiding my roadmap as a security TPM for FOSS projects. I treat the criteria as checklists. By running the metrics I figure out what I do and don't need to work on. For example, this month I am cleaning up CodeQL alerts as a result of working through https://bestpractices.coreinfrastructure.org/en/projects/6358#analysis and getting a failing score on the static_analysis_fixed metric.

What I would want from the WGs is to reframe their outputs as a guide for security-related workflows. For example there could be a Kanban template with the first swim lane prefilled with cards corresponding to metrics. I have something similar for OpenChain, which has a comparable role for getting an OSPO organized.

Thank you for the feedback. I'll put this on the docket for the group to discuss in Jan2024. We certainly can spin up a group to work on crafting a checklist/guide to deliver something as you suggest.

In the meantime, the group would welcome your feedback in a future WG meeting or perhaps an issue describing your desired artifact that we could collaborate on together: https://github.com/ossf/wg-best-practices-os-developers/issues

That is not accurate. The group works under the assumption that there are multiple levels of "learners" and consumers of OSS.

As far as I can remember my comment was inspired by a thread where it was discussed that most developers aren't taught how to develop secure software and have no idea what the principle of least privilege is or something like that. I agree I overgeneralized.

Either way I replied to https://github.com/ossf/tac/issues/169#issuecomment-1570166845 and my point is that that WG isn't the place where core maintainers can describe their pain points and get actual things done. For example it's unlikely that that WG can arrange another cluster for people fuzzing a gazillion open source projects.

Patches, RFEs, and comments are always welcome by the group for new projects to help the community.

I don't doubt that patches are always welcome but I'm afraid I don't have time for that. I contribute to projects like OSS-Fuzz and Fuzz-Introspector because they actually help me to address actual issues I have. I contributed to scorecard too but it was because it produced a lot of false positives and it was easier to fix that stuff than to wait for the official fixes.

You can check out their current backlog here: https://github.com/ossf/scorecard/issues

I'm aware where their repository is but thanks.

the group would welcome your feedback in a future WG meeting or perhaps an issue

See https://github.com/ossf/wg-best-practices-os-developers/issues/344

@SecurityCRob It would be valuable to put this on the agenda of a specific meeting. Do you have thoughts on which WG that would be?

Would the Best Practices for OSS Developers WG be the right fit?

That is not accurate. The group works under the assumption that there are multiple levels of "learners" and consumers of OSS. The three main developers we think about are beginners/people that are new to the trade, people that are changing careers into development, and existing experienced developers. The current available class focuses on beginning software engineers (although more experienced developers could benefit from that content as well as they may have not been exposed to it before). There are materials being developed on intermediate and advanced development topics that will be available in the future. Patches, RFEs, and comments are always welcome by the group for new projects to help the community.

That is great, and I laud this. More and better educational materials are always great. It will really help for new projects made by newcomers that are already safety-critical and... Wait. These do not exist. Right. I mean, they probably will at some point, and there are probably some. I also deeply wonder what kind of educational material for "advanced" maintainers you expect would make a difference. Is there really a well of knowledge that experienced maintainers do not already have access to and need about "how to make safe code?" with things we have not been told hundreds or thousands of times for the past 2 to 3 decades?

Like, I get the point of writing these Best Practices; it is really helpful to show policy makers and maintainers to enforce compliance. You need the list to score and enforce the rules. I get which crowd the OpenSSF is talking to here. But that is not maintainers. And so, I will support once more a "Maintainer Experience" group, at least in order to publish data and research on it. We have scant work reporting on Maintainer Experience. The Road and Bridges report, a few research papers, and the Tidelift survey come to mind.

I think this would be something where the OpenSSF could have an important impact in making visible the realities of the sharp end and how it affects security instead of only reacting and trying to make sense of the millions of packages and their security.

Is there really a well of knowledge that experienced maintainers do not already have access to

There are better places to learn things but they can't be easily linked to maintainers/projects to evaluate/certify them. I think some sort of rationale can be found at https://openssf.org/oss-security-mobilization-plan/ where Stream 1 is supposed to "Deliver Baseline Secure Software Development Education and Certification to All". scorecard should start downgrading projects with no OpenSSF "credentials" soon as far as I can remember :-)

And so, I will support once more a "Maintainer Experience" group, at least in order to publish data and research on it

Seconded.

The OpenSSF website tab "Technical Initiatives / For Developers" specifically links to the "For Software Developers" landing page, which tries to provide a short list of materials ready for use directly by software developers.

I'm sure it can be improved, but the intent is for that to help (pull requests welcome). Hopefully that makes a dent in the need to improve maintainer experience.

Is there really a well of knowledge that experienced maintainers do not already have access to and need about "how to make safe code?" with things we have not been told hundreds or thousands of times for the past 2 to 3 decades?

Let me talk a little about education on developing secure software. My experience, and yours may differ, is that many maintainers of important software have never heard about how to develop secure software in enough detail to do anything about it. Most universities & bootcamps don't teach how to develop secure software, and "learning from your peers" only works when many peers already know it. If you're in the security world you're well aware of the issues, but that doesn't mean most software developers know. Here's some evidence for this belief:

1. 53% of software developers report that their organizations don’t ensure training on securing coding [Poneman 2020]
2. No top 40 US “coding” or top 5 non-US CS school required secure coding in 2019 [Forrester 2019]
3. Of U.S. News's top 24 CS 2022 schools, only 1 requires security for undergraduates.
4. The third most popular answer for how to improve OSS security was providing more training to the OSS community. Source: the 2022 v2.0 survey “Addressing Cybersecurity Challenges in Open Source Software” by Stephen Hendrick (VP Research, The Linux Foundation) & Martin McKeay (Senior Editorial Research Manager, Snyk), question q0050mrv. The only higher-ranked items were “define best practices for secure software development” and “provide tools for analyzing and remediating vulnerabilities in the top 500 open source components” - which clearly don’t conflict with training.
5. One article pointedly noted, “universities don’t train computer science students in security”.
6. One survey claimed otherwise, but it is misleading. The State of Developer-Driven Security Survey, Secure Code Warrior, 2022, found that 89% of developers reported they’ve received sufficient training in secure coding skills. However, what this survey really showed is that developers know so little that they think they know more than they do (an unfortunate example of the Dunning–Kruger effect). More than half of those respondents were not familiar with common software vulnerabilities, how to avoid them, and how they can be exploited. 92% said they needed more training on security frameworks, and 86% stated they found it challenging to practice secure coding. In short, they thought they knew enough, yet most knew almost nothing.

Hopefully that makes a dent in the need to improve maintainer experience.

I'm not sure how it can address the underlying issues most of which boil down to the fact that there don't seem to be actual maintainers anywhere at OpenSSF who can figure out how all that stuff affects actual maintainers. For example at some point the OSV database was introduced and somehow it turned into a machine helping to automatically file nonsensical CVEs and somehow I ended up on the receiving end of that nonsense. Promotional PRs fixing imaginary security issues wasted a lot of my time too. I wonder how that WG with basic training materials can change that?

A project to address maintainer experience with Scorecard: https://github.com/ossf/scorecard/issues/3798

A project to address maintainer experience with Scorecard:

I think in terms of maintainer experience scorecard is more or less covered these days in the sense that there is a team at GOSST integrating scorecard into actual projects, talking to actual maintainers and receiving unabridged feedback. Issues they open are thoughtful and based on conversations with actual maintainers. I think it would be nice if those issues were prioritized instead.