Proposed Initiative: "Maintainer Experience" of OpenSSF

[webchick]

(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!

[lehors]

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!

[david-a-wheeler]

@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.

[SecurityCRob]

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) @lehors<https://github.com/lehors> - Securing Software Repositories<https://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 WG<https://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 GitHub<#169 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AQRFDLD37V47WIYKFUEZMGLXIX26FANCNFSM6AAAAAAYS7XDVU>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.******@***.***>>

[webchick]

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?

[webchick]

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. :)

[di]

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!

[SecurityCRob]

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

[lehors]

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. :-)

[annabellegoth2boss]

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...)

[TheFoxAtWork]

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.

[DianaOlympos]

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.

[SecurityCRob]

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.