Create an OpenSSF GitHub organization for pre-sandbox/prototype projects

[marcelamelara]

The current Project lifecycle docs have guidelines for sandbox projects that are being developed within an existing OpenSSF WG, which mention that these projects should be hosted within the WG's Github organization.

The Problem

Based on feedback I've gotten from OpenSSF community members, there's a need for a space (i.e., GitHub organization) where early pre-sandbox projects can live while they mature enough to reach sandbox stage. This would enable community members to develop and collaborate on anticipated/future OpenSSF projects under the OpenSSF umbrella from the start.

A few reasons community members might want such a space:

1. The project is in early prototype or pre-sandbox stages, and the most suitable host WG can't be identified yet.
2. Even if a host WG has been identified, a tight coupling with the main WG repo may not always make sense. For example, high-turnover prototype development may pose an undue burden or cause permissioning issues on the main WG repo, especially if the project developers aren't the WG repo maintainers.
3. The contributors are from different member OpenSSF member organizations. A dedicated OpenSSF GitHub organization avoids having to create random GitHub organizations for the project or hosting the project under one of the member orgs.

The Proposal

Establish an OpenSSF Labs GitHub organization that has a low barrier to entry while providing a clear pathway towards sandbox status under a WG. LF Hyperledger Labs may provide a good model for this.

The Challenges

We want to be careful not to create a way for this new GitHub organization to become a dumping ground for projects that are "being thrown over the fence". So, there must still be baseline requirements for applying for lab status and transitioning either to sandbox or archived status, in the event that the lab project gains traction or needs to be abandoned.

Checklist

Following the TAC's decision to support the creation of this new GH organization, we have the following outstanding tasks:

• Document new lab proposal process (see: HL labs process)
• Create proposal template (see HL labs template)
• Decide if we should establish group of dedicated labs stewards, a group whose responsibility is to vet labs proposals
• Create dedicated Github Org for labs projects

[idunbarh]

Here is the specific quote that causing us some issues for some prototyping tied to the Security Tooling WG.

It is expected that the initial code or specification developed by an OpenSSF WG be kept within their repository and will not function as a Project in its own right.

The Security Tooling WG has this repo that hosts WG internal docs. It doesn't seem like the correct place for prototypes that may in the future become a stand alone project.

[lehors]

Here is the specific quote that causing us some issues for some prototyping tied to the Security Tooling WG.

It is expected that the initial code or specification developed by an OpenSSF WG be kept within their repository and will not function as a Project in its own right.

The Security Tooling WG has this repo that hosts WG internal docs. It doesn't seem like the correct place for prototypes that may in the future become a stand alone project.

Could you please expand on why this wouldn't be the correct place?
It is fully expected that such projects might eventually become standalone at which point they would get their own repo. Why doesn't that work?

I'm concerned that this would essentially be creating yet another stage for a project to exist, before sandbox. How many stages do we really want to have?

[idunbarh]

Totally agree with the concern about adding additional "official" stages. But even without a defined "pre-sandbox" stage in the OpenSSF project lifecycle, projects will always pass through a "pre-sandbox" stage. Projects don't go from "zero" to "sandbox" when there are requirements for a prototype, diversity in contributors, and etc ... to enter sandbox status.

I see a couple questions that lead to reasons against prototyping within the WG repos.

• Continuity - What does the transition from prototype to sandbox project look like? What are the thoughts around maintaining git history, permissions, etc into new github repos. I assume the WG repos are not intended to be mono repos for sandbox projects.
• Permissions, workflows, and other configurations - If we're looking at prototype code, we're introducing friction since folks will probably not be maintainers are WG repos.
• Not followed today - Are there any examples of projects that started out as prototype code that resides in a WG repo? Looking through the existing WGs I don't really see this process being followed. It seems like most projects that start as WG activity just spin up new orgs.

[marcelamelara]

I'm concerned that this would essentially be creating yet another stage for a project to exist, before sandbox. How many stages do we really want to have?

This is a fair point, and it's definitely a concern I have as well. One possibility to address this is to offer this as a sandbox stage option, though this raises the question of whether the project sandbox stage requirements need to be revisited.

In addition to the points Ian brought up, I'm coming at this from a governance perspective. Having an OpenSSF pre-sandbox or "lab" space would avoid concerns or questions around who hosts projects that are started by or are seeking contributors from different OpenSSF member organizations, but aren't ready for sandbox stage yet. This is especially important for member organizations that require pre-approval open-source contributions through internal SDL processes. If the new/early project is hosted under a well-established GitHub organization, this often makes a stronger case for an SDL review. Currently, though, the alternatives are to host projects under one-off GH organizations or individual accounts which don't have any governance policies.

More generally, though, having such a "pre-sandbox" space has the potential to establish a clearer project pipeline and process for developing full fledged OpenSSF projects.

[gkunz]

Hi,
I would be concerned that an additional de-fact pre-sandbox stage (hosted in a separate org) over-complicates the process - and thereby conflicts with a core idea of a sandbox project: "Encourage experimentation and open collaboration that can add value to the OpenSSF mission and build the ingredients of a successful Incubation level Project." In case a WG decides to kick-off a prototyping activity, I would personally consider this origin in an existing OpenSSF WG, as sufficient to give it a repo in the OpenSSF org. Personally, I believe we should be more inclusive-by-default to foster participation - this is a key strength of open source and open innovation and I would not want to create the perception that working with the OpenSSF is too complicated to bother.

[marcelamelara]

@gkunz I appreciate you highlighting one of the four core goals of sandbox projects "Encourage experimentation and open collaboration". I completely agree that sandbox projects should be experimental, focus on fostering early collaboration, and have a low barrier to entry.

What we're observing, though, is that this isn't how sandbox projects are being treated today. Typical sandbox projects are more mature than experimental-phase projects, and in fact do have several acceptance requirements that can only be met once the project is more mature (e.g. number of maintainers, adherence to the SSDGP, quarterly updates etc).

So the goal of this issue is precisely to find a way to lower this bar and be more inclusive from the start, while establishing a (simple) process for contributors to operate while starting new projects (under a WG or not).

[gkunz]

@marcelamelara, I agree with your and @idunbarh's statement that projects don't go from zero to sandbox - it was rather a misunderstanding on my end, not realizing that given the current governance structure, sandbox is in fact the minimum stage for any form of effort to be allowed to be hosted in the OpenSSF GitHub org. I was under the assumption that WGs could spin out [prototyping] efforts to separate repos within the OpenSSF org.

Anyhow, as I believe that we should be very open to welcoming new prototyping activities and I also see the need for not cluttering up the OpenSSF org (I am seriously less concerned about a brand issue here), your proposed lab-space is actually a nice compromise. Thanks.

[SecurityCRob]

In a recent conversation with staff, providing repo space within our org should not be a blocker for us. We'll want to put together some guidelines for folks and time-box how long things exist prior to moving up or out. We'll need some templates and disclaimer info about something being "beta"/"prototype"/"experimental" to set it apart from the more mature projects that are active.

[presidentoor]

We could consider calling it a Secure Open Source Software (SOSS) Lab, instead of the OpenSSF Lab. This creates a distinction that there are OpenSSF Lifecycle Stages of Sandbox, Incubating, Graduated, and Archived as well as a Lab function that is distinct from a Lifecycle Stage.

[sevansdell]

What action items are needed to close this out:
-TAC process documentation for "lab"
-The actual "lab"
-Testing
-Comms for awareness

Status update on how this is evolving please?

[hythloda]

My read is that this issue can be closed from #264 (comment) as not planned. Perhaps we should have an issue in a backlog of making such guidelines and templates?

[marcelamelara]

My read is that this issue can be closed from #264 (comment) as not planned.

@hythloda Maybe I'm misreading something in that comment, but to me, it sounds like there was a positive response to move this forward earlier this year.

If supporting this effort is still planned, I think an issue with multiple tasks for the items @sevansdell listed and the guidelines/templates is needed.

[SecurityCRob]

what is the status of this? has there been any progress or has it been nacked?

[sevansdell]

I think this is something that still needs done. It requires updating the sandbox lifecycle with this as a "give" and should point to a process document in the TAC repo for how to get access to this repo. Perhaps if we update the sandbox stage request to say: Will you need a sandbox repo? And if the applicant says yes, then when sandbox is approved, some program management process kicks off (whereever that documentation lives)?

[lehors]

It requires updating the sandbox lifecycle with this as a "give"

No, this is to allow interested parties to get a repo to work with before getting into the sandbox stage.

I think having a github org a la ossf-labs to host those would be fine but indeed this still requires putting together some governance structure to manage this.

Let me suggest having a look at how this is done within Hyperledger: https://github.com/hyperledger-labs/

[marcelamelara]

Let me suggest having a look at how this is done within Hyperledger: https://github.com/hyperledger-labs/

Yes! Thanks for this @lehors . Hyperledger Labs is exactly the model I was thinking about when I opened this.

this still requires putting together some governance structure to manage this.

I'm happy to bring in the HL Labs governance documentation as a starting point for us. But who at OpenSSF would approve this new org?

[lehors]

I'm happy to bring in the HL Labs governance documentation as a starting point for us. But who at OpenSSF would approve this new org?

I would think that's up to the TAC.

[sevansdell]

This is on the TAC agenda for 10/29/24.

[marcelamelara]

Per the 10/29/24 TAC meeting, I committed to drafting the initial ossf-labs process and have it ready for review by the next TAC meeting.

[marcelamelara]

A bit delayed, but I'm going to use https://github.com/lf-decentralized-trust-labs/lf-decentralized-trust-labs.github.io as my starting point. I intend to get the PR for the proposal process out before EOY.

FWIW, I don't expect the volume of such new labs projects to be especially high at the beginning so my suggestion would be to have the TAC review new labs proposals until the workload becomes more difficult to manage.