Open Science Labs Project Affiliation Program #

The Open Science Labs (OSL) Project Affiliation Program is for independent open-source projects that align with OSL's mission and want to be connected to the OSL ecosystem.

Affiliation is a lightweight relationship. It gives aligned projects visibility, community connection, and access to OSL opportunities, while project governance, maintenance, technical decisions, releases, and roadmap ownership remain with the project's own maintainers.

Affiliation is a relationship, not a transfer of ownership.

Purpose #

The purpose of affiliation is to:

• recognize projects aligned with open science, open source, education, research, public-interest technology, or related infrastructure;
• help contributors discover healthy projects;
• allow projects to participate in OSL opportunities when appropriate;
• create pathways for collaboration between maintainers, contributors, mentors, researchers, and partner organizations;
• promote projects that share OSL's values of openness, inclusion, learning, mentorship, and responsible maintenance.

Benefits #

Affiliated projects may receive:

• Project directory listing: inclusion in the OSL public project list.
• Visibility and promotion: amplification through OSL channels, events, blog posts, demos, or community updates when relevant.
• Program eligibility: ability to submit project ideas for OSL internships, Google Summer of Code, grants, sponsorship opportunities, or similar programs when available.
• Community access: connection with the OSL Discord community and related contributor networks.
• Collaboration opportunities: introductions to mentors, reviewers, partner communities, or funding opportunities when there is a good fit.
• Contributor pathways: a clearer route for newcomers to discover and contribute to the project.

Affiliation does not guarantee that a project will receive funding, interns, contributors, grants, sponsorship, or long-term maintenance support from OSL.

Google Summer of Code and Limited Programs #

Affiliated projects may submit ideas for Google Summer of Code (GSoC), internships, grants, or similar programs when OSL is participating and when the project is ready to mentor contributors.

Participation is not guaranteed. OSL will do its best to participate in GSoC and similar opportunities when possible, but these programs depend on external selection, OSL capacity, mentor availability, project readiness, and a limited number of contributor slots. Even when OSL participates, not every affiliated project idea can be selected or funded.

Projects that want to participate in GSoC or internships should provide clear project ideas, public issues, active mentors, communication channels, and enough review capacity to support contributors responsibly.

Acknowledging OSL Affiliation #

Affiliated projects should acknowledge their relationship with OSL in their README.md and, when applicable, in their public documentation.

Suggested wording:

This project is affiliated with Open Science Labs (OSL). Affiliation means that the project aligns with OSL's mission and is connected to the OSL ecosystem, while governance, roadmap, maintenance, and releases remain the responsibility of the project maintainers.

Projects should avoid language that suggests OSL owns, governs, certifies, or guarantees the project unless there is a separate written agreement.

Eligibility Criteria #

To become and remain affiliated with OSL, a project must:

• be released under an OSI-approved open-source license;
• include a public LICENSE file;
• include a CODE_OF_CONDUCT.md or equivalent public Code of Conduct;
• provide a maintainer contact or public communication path;
• have at least one active or reachable maintainer;
• use public development practices, such as a public repository, issue tracker, contribution guide, project board, or documented contact process;
• align with OSL's mission and values;
• maintain an open and inclusive project environment.

Recommended, but not always required at the time of application:

• CONTRIBUTING.md;
• public roadmap or project ideas;
• issue labels for newcomers;
• security reporting instructions;
• basic user and developer documentation;
• recent release notes or changelog.

Affiliation Fit Checklist #

Use this checklist before opening an affiliation request. A project does not need to be large or mature, but it should be healthy enough for OSL to list it publicly and direct community attention toward it.

Required for Affiliation #

• [ ] The project has a clear open-source, open-science, research, education, public-interest, or open-technology purpose.
• [ ] The project uses an OSI-approved open-source license.
• [ ] The repository includes a public LICENSE file.
• [ ] The project includes a CODE_OF_CONDUCT.md or equivalent public Code of Conduct with a reporting path.
• [ ] The project has at least one active or reachable maintainer.
• [ ] The project has a public repository.
• [ ] The project has a public issue tracker, discussion channel, project board, or documented way to contact maintainers.
• [ ] The project is not archived, closed-source, abandoned, misleading, or unsafe for contributors.
• [ ] The maintainers agree that affiliation does not transfer ownership, governance, intellectual property, or maintenance responsibility to OSL.
• [ ] If accepted, the project will acknowledge its OSL affiliation in its README.md and, when applicable, public documentation.

Recommended for Affiliation #

• [ ] The repository has a README explaining the project, users, and current status.
• [ ] The project has contributor instructions or a CONTRIBUTING.md.
• [ ] The project has basic user or developer documentation.
• [ ] The project has a public roadmap, project ideas, or issue labels for contributors.
• [ ] The project has a SECURITY.md or vulnerability reporting path when relevant.
• [ ] The project has recent releases, commits, issue responses, or a documented stable-maintenance status.
• [ ] The project can explain what kind of collaboration it is seeking through OSL.

Maintenance Expectations #

Affiliated projects can be fast-moving, mature, or stable. OSL does not require constant feature development. However, affiliated projects must remain maintained enough that contributors, users, and OSL can understand the project status.

OSL uses the following maintenance levels:

For affiliation, both Active and Maintained / Stable are acceptable states. A stable project should make that status clear in its documentation so contributors understand what to expect.

Automated Maintenance Checks #

OSL may use automated bots to help review affiliated projects. The goal is to keep the public project directory accurate and to avoid sending contributors to unmaintained repositories.

For affiliated projects, bots may check quarterly:

• whether the repository is public and reachable;
• whether the repository has an OSI-approved LICENSE;
• whether the repository has a CODE_OF_CONDUCT.md;
• whether the project is archived;
• whether the listed website, documentation, and community links are reachable;
• whether there has been recent public activity or a documented stable status;
• whether maintainers are still listed and reachable;
• whether important issues or pull requests have gone unanswered for a long period;
• whether project metadata in the OSL website remains accurate.

Bots should support human review. A bot warning does not automatically mean a project is abandoned. Maintainers may explain that the project is stable, low-maintenance, between maintainers, or temporarily paused.

Review and Removal Workflow #

When an affiliated project appears to be unmaintained or out of compliance, OSL may follow this workflow:

Projects can avoid removal by:

• restoring the required license or Code of Conduct;
• updating broken links;
• responding to the maintenance review;
• identifying a new maintainer;
• documenting that the project is stable and maintained with lower activity;
• publishing a realistic maintenance plan;
• asking OSL to pause the listing temporarily while maintainership is being resolved.

Removal from the OSL list is not permanent. A project may request affiliation again after it restores the baseline requirements and maintenance status.

Limits and Responsibilities #

Affiliated projects remain independent. OSL does not:

• own the project or its intellectual property;
• control the roadmap, releases, governance, or technical decisions;
• guarantee funding, contributors, interns, mentors, reviews, or adoption;
• guarantee participation in Google Summer of Code, internships, grants, or sponsorship opportunities;
• guarantee a Google Summer of Code contributor slot, even when OSL participates;
• provide legal, security, medical, or financial certification;
• endorse every technical choice or public statement made by the project.

Maintainers are responsible for:

• keeping the project open-source and properly licensed;
• maintaining the Code of Conduct and responding to community concerns;
• reviewing issues and pull requests when they invite contributions;
• keeping project links and OSL metadata accurate;
• keeping the OSL affiliation acknowledgement accurate in the project's README.md and public documentation;
• communicating major changes in ownership, scope, license, governance, or maintenance status;
• protecting contributors from unsafe or hostile community behavior.

OSL may pause, remove, or decline affiliation if a project becomes inactive, closed-source, unsafe, misleading, hostile, or misaligned with OSL values.

How to Apply #

Interested projects should request affiliation through the OSL affiliation requests repository:

https://github.com/OpenScienceLabs/affiliation-requests

An affiliation request should include links to evidence, not only written statements. Useful evidence includes:

• project name and repository URL;
• project website or documentation URL, if available;
• maintainer names and contact information;
• license link;
• Code of Conduct link;
• short project description;
• current maintenance status;
• public communication channel or contact path;
• contribution instructions, roadmap, project ideas, or starter issues when available;
• security reporting path when relevant;
• why the project aligns with OSL;
• what kind of collaboration or visibility the project is seeking;
• whether the project wants to submit ideas for internships, Google Summer of Code, grants, or other OSL opportunities.

If GitHub is not accessible to an applicant, they may contact team@opensciencelabs.org and ask for support opening the request.

Affiliation Request Workflow #

OSL uses a lightweight, transparent workflow for affiliation requests:

1. Request opened: maintainers open an issue in the affiliation requests repository with the requested information and evidence links.
2. Completeness check: OSL checks that required information is present, including license, Code of Conduct, maintainer contact, repository link, and project description.
3. Eligibility review: OSL reviews mission alignment, openness, maintenance status, community safety, and whether the project is appropriate for OSL's public project list.
4. Maintainer follow-up: OSL may ask questions, request missing links, or suggest changes before approval.
5. Decision: the request is approved, declined, or marked as needing changes. Declined or incomplete projects may apply again after addressing the feedback.
6. Listing update: if approved, OSL opens or merges a website update adding the project to the public project list.
7. Onboarding: OSL confirms the listed metadata, preferred communication channel, maintainer contact, and whether the project wants to participate in any eligible OSL opportunities.
8. Periodic review: the project remains subject to automated and human maintenance checks while it is listed by OSL.

Affiliation requests are not first-come, first-served. OSL may prioritize requests based on completeness, mission fit, community safety, available review capacity, and whether the project is seeking participation in time-sensitive programs.

Review Criteria #

OSL reviews affiliation requests using these criteria:

• Mission fit: the project contributes to open science, open source, research, education, public-interest technology, or useful open infrastructure.
• Openness: the project is publicly developed and uses an OSI-approved license.
• Community safety: the project has a Code of Conduct and does not create a hostile or unsafe environment for contributors.
• Maintenance status: maintainers are reachable and the project is active or clearly documented as stable.
• Contributor readiness: contributors have a way to ask questions, open issues, or understand how to participate.
• Metadata quality: the project provides enough accurate information for OSL to list and periodically review it.
• Program readiness: if the project wants internships, Google Summer of Code, grants, or similar opportunities, it has enough maintainer capacity and project ideas to support contributors responsibly.

Boundaries of Affiliation #

Affiliation creates a public relationship between OSL and an independent project. It does not make the project an OSL-governed or OSL-owned project.

Affiliation does not mean:

• OSL owns the repository, name, logo, code, data, intellectual property, or governance of the project;
• OSL is responsible for maintaining the project;
• OSL certifies the technical, scientific, security, legal, medical, financial, or ethical correctness of the project;
• OSL endorses every decision, release, public statement, dependency, or integration made by the project;
• the project is guaranteed funding, contributors, interns, mentors, grants, sponsorship, fiscal hosting, promotion, or event participation;
• the project may imply that OSL controls or guarantees its work;
• the project may use OSL branding in a way that suggests ownership, certification, or formal sponsorship without written permission.

Affiliated projects may describe themselves as an "OSL affiliated project" only while they are listed by OSL and remain in good standing. If affiliation is paused or removed, the project should stop presenting itself as currently affiliated with OSL.

Review Process #

OSL reviews affiliation requests for mission alignment, openness, maintenance status, community safety, and readiness for contributors. If approved, the project is added to the OSL project list and may participate in relevant OSL programs according to each program's requirements and capacity.

For more information or inquiries, contact team@opensciencelabs.org.