Open Science Labs Incubator Program #

The Open Science Labs (OSL) Incubator Program is a structured pathway for open-source projects that need active support to become sustainable. It is for projects that are early-stage, restarting, transitioning into open source, or ready to improve their maintenance, documentation, governance, contributor onboarding, and release practices.

Incubation is deeper than affiliation. Affiliation connects an independent project with the OSL ecosystem. Incubation creates a shared growth plan between project maintainers and OSL.

Incubation is a growth pathway from idea to sustainable project.

What Incubation Is For #

The Incubator Program helps projects:

• turn promising ideas into usable open-source projects;
• define a public roadmap, milestones, and contribution path;
• improve documentation, testing, packaging, releases, and maintainability;
• onboard contributors through clear issues, mentoring, and review practices;
• prepare ideas for internships, Google Summer of Code, grants, sponsorships, or other opportunities when available;
• build a maintainer model that can continue beyond the original author;
• graduate into an independent and sustainable project.

Incubated projects may be scientific software, research infrastructure, educational tools, public-interest technology, or support tools for open-source work such as automation, DevOps, documentation, data workflows, and community infrastructure.

What OSL May Provide #

Depending on project needs and OSL capacity, incubated projects may receive:

• project-structure and roadmap guidance;
• mentorship for maintainers and contributors;
• support defining newcomer-friendly issues and internship ideas;
• visibility through OSL channels, events, blog posts, demos, or community updates;
• guidance on documentation, packaging, testing, releases, governance, and contributor workflows;
• help identifying grants, sponsors, fiscal-hosting paths, reviewers, or partner organizations;
• periodic maintenance and health checks.

Incubation does not guarantee funding, contributors, interns, mentors, external program acceptance, publication, adoption, or long-term OSL maintenance.

Google Summer of Code and Limited Programs #

Incubated projects may prepare ideas for Google Summer of Code (GSoC), internships, grants, or similar programs when OSL is participating and when the project has enough mentor capacity.

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 incubated project idea can be selected or funded.

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

Acknowledging OSL Incubation #

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

Suggested wording:

This project is incubated by Open Science Labs (OSL). Incubation means that OSL supports the project through mentorship, structure, community connection, and sustainability guidance, while day-to-day maintenance, roadmap decisions, and releases remain the responsibility of the project maintainers.

Projects should update this acknowledgement if their status changes, such as moving from PoC to incubation, graduating, leaving the OSL organization, or being removed from OSL public listings.

Incubation Fit Checklist #

Use this checklist before applying. A project does not need to be perfect, but it should be ready for public collaboration and active maintainer engagement.

Required for Incubation #

• [ ] The project has a clear purpose and public-interest, open-science, research, education, or open-technology alignment.
• [ ] 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 and reachable maintainer.
• [ ] The project has a public repository or a public proposal repository.
• [ ] The project has a public issue tracker, project board, or documented way to discuss work.
• [ ] The project has at least one public communication channel or documented contact path for users and contributors.
• [ ] The maintainer is willing to communicate with OSL mentors or reviewers during incubation.
• [ ] The project can be maintained in public and can welcome contributors in a respectful environment.
• [ ] If accepted, the project will acknowledge its OSL incubation status in its README.md and, when applicable, public documentation.

Strongly Recommended Before Acceptance #

• [ ] The repository has a README explaining the project, users, and current status.
• [ ] The project has a CONTRIBUTING.md or contributor instructions.
• [ ] The project has an initial roadmap or milestones for the next 3 to 6 months.
• [ ] There are starter issues or planned tasks for contributors.
• [ ] The project has basic user or developer documentation.
• [ ] The project has tests, validation examples, or a plan to add them.
• [ ] The project has an architecture, design, or technical overview when relevant.
• [ ] The project has a release, versioning, or publication plan when relevant.
• [ ] The project has a SECURITY.md or vulnerability reporting path when relevant.
• [ ] The project has a documented maintainer list, roles, or decision-making process.
• [ ] The project has early user, adopter, contributor, citation, deployment, or pilot evidence when available.
• [ ] The maintainers can explain what kind of help they need from OSL.

Scientific Software Review Expectations #

For scientific software, OSL may require an external or community review path as part of graduation:

• [ ] Scientific Python projects that are in pyOpenSci scope should follow pyOpenSci guidelines during incubation and must be accepted by pyOpenSci before graduating.
• [ ] Scientific R projects that are in rOpenSci scope should follow rOpenSci guidelines during incubation and must be accepted by rOpenSci before graduating.
• [ ] Scientific projects outside pyOpenSci or rOpenSci scope should define an equivalent review path with OSL during incubation.

How to Apply #

Applications for incubation should be submitted through the OSL Incubator project applications repository:

https://github.com/osl-incubator/project-applications

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

• project name and short description;
• repository, documentation, or proposal link;
• maintainer names and contact information;
• license and Code of Conduct links;
• current project stage and maintenance status;
• problem statement and intended users;
• roadmap or milestones for the next 3 to 6 months;
• contributor and mentoring needs;
• expected OSL support;
• links to contribution instructions, starter issues, release notes, security policy, governance, or architecture documentation when available;
• evidence of users, adopters, citations, deployments, pilots, or community interest when available;
• whether the project is scientific Python, scientific R, or another scientific software project that may need external review before graduation.

OSL reviews applications for mission alignment, openness, maintainer readiness, community safety, feasibility, and available mentor capacity.

How OSL Reviews Projects #

OSL uses a lightweight due-diligence process inspired by mature open-source foundation practices. The review should be transparent, evidence-based, and proportional to the project's stage.

For incubation applications and stage changes, OSL may review:

• Application completeness: required links and project information are present.
• Maintainer readiness: maintainers are reachable and have enough capacity to support contributors.
• Governance and continuity: roles, decision-making, ownership, and maintainer succession are clear enough for the project stage.
• Contributor readiness: issues, contribution instructions, communication channels, and review expectations are discoverable.
• Technical readiness: the problem, design, roadmap, release process, and quality practices are appropriate for the project stage.
• Security and safety: the project has a way to report sensitive issues and maintainers can respond to community or safety concerns.
• Adoption or usefulness evidence: the project can show intended users, early users, pilots, citations, deployments, or community interest when appropriate.
• Scientific review path: scientific projects have a pyOpenSci, rOpenSci, or equivalent review plan when relevant.

Detailed issue templates, labels, bot configuration, and operational review checklists should live in the project applications repository, not on this overview page.

Incubation Lifecycle #

The Incubator Program has three main stages and one non-active lifecycle outcome.

1. Proof of Concept (PoC) #

The PoC stage is for ideas, prototypes, or early repositories that need validation before becoming full incubated projects.

PoC projects should have:

• a clear problem statement;
• an early design, prototype, or proposal;
• an OSI-approved license;
• a Code of Conduct;
• at least one named maintainer or project author;
• a public repository or proposal space;
• initial issues, questions, or planned tasks;
• a lightweight roadmap for the next 1 to 3 months.

PoC projects are expected to show active exploration. They do not need mature releases, but maintainers must be responsive.

A PoC project may move into Incubation when it demonstrates feasibility, alignment with OSL, maintainer commitment, and a realistic development plan.

2. Incubation #

The Incubation stage is for projects that are ready for structured development and contributor support.

Incubating projects should have:

• active maintainer participation;
• public roadmap and milestones;
• contribution instructions;
• public issues or project tasks;
• regular communication with OSL mentors or reviewers;
• progress toward documentation, tests, packaging, releases, governance, and sustainability;
• enough mentor capacity before accepting interns or major contributor programs.

Incubating projects are normally expected to be Active. If maintainers need to pause, they should communicate the pause and publish a maintenance plan.

3. Graduated #

Graduation means that the project has reached a sustainable state and no longer needs active incubation support.

Graduated projects may stay under an OSL-controlled GitHub organization or move outside OSL to an independent organization, maintainer-owned organization, lab, foundation, company, or community home.

A graduated project may still be listed by OSL, but its maintainers remain responsible for governance, maintenance, releases, licensing, Code of Conduct, and community safety.

Graduation Criteria #

A project may request graduation when it has met its incubation milestones and can show that it is responsibly maintained.

General graduation expectations:

• successful completion of incubation milestones;
• active or stable maintenance;
• clear maintainer team or governance model;
• a maintainer team appropriate to the size and risk of the project;
• at least two maintainers preferred, or a documented continuity plan when the project has only one maintainer;
• public documentation and contribution process;
• documented decision-making, ownership, and maintainer onboarding/offboarding practices appropriate to the project stage;
• release, deployment, publication, citation, user, or adoption evidence appropriate to the project scope;
• documented release or versioning process when relevant;
• security or vulnerability reporting process when relevant;
• ongoing OSI-approved licensing;
• ongoing Code of Conduct;
• sustainable communication and issue-review practices;
• clear plan for where the repository will live after graduation.

Additional scientific software expectations:

• scientific Python projects in pyOpenSci scope must be accepted through the pyOpenSci review process before graduation;
• scientific R projects in rOpenSci scope must be accepted through the rOpenSci review process before graduation;
• scientific projects outside those scopes must complete an equivalent review path agreed with OSL during incubation.

A graduation request should include links to evidence for:

• completed milestones;
• current maintainer list and maintainer roles;
• current maintenance status;
• governance or decision-making process;
• future roadmap or maintenance plan;
• documentation, contribution instructions, and release process;
• security or vulnerability reporting process when relevant;
• user, adoption, deployment, citation, or publication evidence when available;
• desired repository location after graduation;
• pyOpenSci acceptance link for in-scope scientific Python projects;
• rOpenSci acceptance link for in-scope scientific R projects;
• explanation of the equivalent review path for scientific projects outside pyOpenSci or rOpenSci scope.

Graduation Review Workflow #

Graduation should be public and evidence-based. OSL may use the following high-level workflow:

1. Graduation request: maintainers open a request in the project applications repository with links to evidence.
2. Completeness check: OSL checks that required information is present and asks for missing evidence if needed.
3. Readiness review: OSL reviewers evaluate maintenance, governance, contributor readiness, documentation, security, adoption or usefulness, and any scientific review requirement.
4. Public comment period: OSL may leave the request open for community feedback, usually for about two weeks.
5. Decision and transition: OSL approves graduation, asks for additional work, pauses the request, or declines it with documented reasons.
6. Website and repository update: OSL updates project listings, repository location, status, and maintenance metadata.

OSL maintainers, mentors, or governance representatives review graduation requests before approving the transition.

Scientific Python Projects and pyOpenSci #

Scientific Python projects under the OSL Incubator Program should follow pyOpenSci guidelines during incubation. pyOpenSci provides community-led guidance and review criteria for Python packages used in scientific and open-science contexts.

Maintainers should use these resources while preparing the project:

• pyOpenSci Python Package Guide
• pyOpenSci Peer Review Process
• pyOpenSci Packaging Guide
• pyOpenSci Documentation Guide
• pyOpenSci Testing Guide

For scientific Python projects that are in pyOpenSci scope, graduation from the OSL Incubator Program depends on acceptance through the pyOpenSci review process. Maintainers should prepare the package, submit it for review, respond to reviewer feedback, and provide the acceptance link as part of the OSL graduation request.

Scientific R Projects and rOpenSci #

Scientific R projects under the OSL Incubator Program should follow rOpenSci guidelines during incubation. rOpenSci provides community-led guidance and peer review for scientific R packages, including packages related to scientific data lifecycles and statistical software.

Maintainers should use these resources while preparing the project:

• rOpenSci Software Peer Review
• rOpenSci Packages: Development, Maintenance, and Peer Review
• rOpenSci Packaging Guide
• rOpenSci Software Peer Review Policies
• rOpenSci Guide for Authors
• rOpenSci Statistical Software Peer Review
• rOpenSci Package Maintenance Cheatsheet

For scientific R projects that are in rOpenSci scope, graduation from the OSL Incubator Program depends on acceptance through the rOpenSci review process. Maintainers should prepare the package, submit it for review, respond to reviewer and editor feedback, and provide the acceptance link as part of the OSL graduation request.

Equivalent Review for Out-of-Scope Scientific Projects #

Some scientific projects may not fit pyOpenSci or rOpenSci scope. In those cases, OSL may define an equivalent graduation criterion during incubation, such as review by another appropriate community, publication venue, domain experts, standards group, or an OSL-appointed review group.

The equivalent review path should be documented before graduation so maintainers know what evidence is required.

Maintenance Levels #

Incubation requires active stewardship because OSL may direct contributors, interns, mentors, and public attention to the project.

Automated Incubation Checks #

OSL may use bots to monitor project health, keep public listings accurate, and flag problems early. Bots support human review; they do not replace maintainer judgment.

Bots may check:

• whether the repository is public and reachable;
• whether the project has an OSI-approved LICENSE;
• whether the project has a CODE_OF_CONDUCT.md;
• whether the repository has been archived;
• whether maintainer information is available;
• whether project website and documentation links are reachable;
• recent commits, releases, merged pull requests, and issue activity;
• stale pull requests or unanswered issues;
• progress against milestones or roadmap items;
• whether contributor-friendly issues exist when the project is seeking contributors;
• whether OSL website metadata matches the actual project status.

Suggested check frequency:

At-Risk, Pause, Removal, and Archive Workflow #

When a project appears inactive or out of compliance, OSL may use the following workflow:

Maintainers can resolve an at-risk status by:

• responding to the maintenance review;
• restoring missing license or Code of Conduct files;
• updating broken links and project metadata;
• closing, triaging, or responding to stale community requests;
• documenting a stable-maintenance status;
• transferring or adding maintainers;
• publishing a new roadmap or maintenance plan;
• asking OSL to pause incubation while maintainership is reorganized.

Graduated Projects Outside OSL #

After graduation, a project may move outside an OSL GitHub organization. This is acceptable and often healthy: graduation means the project can operate with less direct OSL support.

When a graduated project moves outside OSL:

• the project may still be listed as a graduated OSL project;
• the external maintainers remain responsible for maintenance, governance, licensing, releases, Code of Conduct, and community safety;
• OSL bots may continue checking public signals such as repository reachability, license, Code of Conduct, archived status, and maintenance activity;
• if the external project becomes inactive or no longer meets the baseline requirements, the bot may open a pull request to remove it from OSL lists and ping maintainers in that pull request;
• OSL does not archive repositories outside OSL-controlled organizations.

A removed graduated project can be restored to the OSL list if maintainers respond, restore the baseline requirements, and show that the project is active or responsibly maintained as stable.

Responsibilities and Limits #

Project maintainers are responsible for:

• maintaining the repository and community spaces;
• reviewing contributor work;
• communicating project status;
• upholding the Code of Conduct;
• keeping license and governance information accurate;
• keeping the OSL incubation acknowledgement accurate in the project's README.md and public documentation;
• telling OSL when the project needs to pause, transfer maintainership, or change direction.

OSL may pause or end incubation if a project loses maintainers, repeatedly fails baseline requirements, becomes unsafe for contributors, moves closed-source, or no longer aligns with OSL's mission.

OSL does not guarantee:

• funding, grants, sponsorship, or paid contributors;
• acceptance into Google Summer of Code or any external program;
• a Google Summer of Code contributor slot, even when OSL participates;
• publication, adoption, external review acceptance, or long-term success;
• indefinite OSL maintenance;
• that every incubated project will graduate.