Best Open-Source AI Projects to Contribute to in 2026
Compare eight open-source AI projects using live GitHub activity, newcomer issues, contribution docs, licensing, and merge throughput.
Table of Contents
The best open-source AI project to contribute to is not the one with the most stars. It is the one that matches your skills and shows a current path from issue to reviewed pull request.
We compared eight active repositories using a live GitHub snapshot from 27 July 2026: license, open newcomer labels, pull requests merged in the previous 30 days, contribution documentation, and code-of-conduct coverage.
The result: vLLM has the clearest large-project newcomer surface; promptfoo has strong evaluation-focused throughput; GEPA offers a smaller codebase; and FutureAGI has the most open good-first-issue labels in this set. Stars did not determine the picks.
Disclosure: FutureAGI publishes this blog and maintains one of the eight repositories. We applied the same five-signal check to it and do not present it as an independent winner.
Which Open-Source AI Project Fits Your Goal?
Use this table to pick a shortlist before reading the repository reviews.
| Your goal | Start with | Why |
|---|---|---|
| Learn GPU inference and model serving | vLLM | Large active codebase, 27 good-first issues, 36 help-wanted issues |
| Build LLM evals or red-team checks | promptfoo | Focused domain and 208 merged PRs in the 30-day snapshot |
| Work on agent and model integrations | LangChain | Broad integration surface and mature contribution process |
| Explore declarative prompt optimization | DSPy or GEPA | Research ideas are visible in compact Python codebases |
| Learn language-model training internals | OLMo-core | Transparent training stack maintained by Ai2 |
| Work on LLM observability | Langfuse | High repository throughput across a full-stack product |
| Find a large current first-issue queue | FutureAGI | 106 open good-first issues; publisher affiliation disclosed above |
If none of those domains interests you, do not force the match. Contributing to a tool you already use is usually better than chasing a famous repository you will stop reading after one weekend.
How Did We Evaluate Contributor Fit?
We used the Contributor-Fit Scorecard, a reproducible five-signal check.
Signal 1: The License Is Clear
A repository must have an identifiable open-source license. MIT and Apache-2.0 are easy for many companies, but copyleft licenses are valid open source too.
The open-source software license guide explains the trade-offs. A missing license is different from a license you would not choose.
Signal 2: Work Is Happening Now
We checked the latest push and pull requests merged from 27 June through 27 July 2026.
Merged-PR totals include maintainers, bots, and internal contributors. They measure repository throughput, not the acceptance probability for a stranger.
Signal 3: A Newcomer Path Exists
We counted open good first issue and help wanted labels. A zero does not make a project closed to newcomers, but it means you need a stronger understanding of the codebase before choosing work.
Labels are a snapshot, not inventory guarantees. Open the issue and check assignees and recent comments before starting.
Signal 4: The Contribution Process Is Written Down
Every project in the final set had a detectable contribution guide. We also checked for a code of conduct through GitHub’s community profile.
Documentation reduces guesswork. It does not prove maintainers will review your change quickly.
Signal 5: The Project Matches a Real Learning Goal
We rejected a single composite score. Ten easy documentation issues in a domain you dislike are not “better” than one hard compiler task you want to learn.
The final decision is a fit judgment after the four observable checks.
What Did the Live GitHub Snapshot Show?
The table below is the original data behind the recommendations.
| Project | Stars | License signal | Good first / help wanted | PRs merged in 30 days (all authors) | CONTRIBUTING | Code of conduct |
|---|---|---|---|---|---|---|
| vLLM | 87,339 | Apache-2.0 | 27 / 36 | 1,074 | Yes | Yes |
| promptfoo | 23,665 | MIT | 0 / 0 | 208 | Yes | Yes |
| LangChain | 142,710 | MIT | 0 / 11 | 135 | Yes | Yes |
| DSPy | 36,415 | MIT | 0 / 1 | 38 | Yes | Not detected |
| OLMo-core | 1,429 | Apache-2.0 | 0 / 0 | 51 | Yes | Not detected |
| FutureAGI | 1,509 | Apache-2.0 | 106 / 0 | 313* | Yes | Yes |
| Langfuse | 31,961 | Mixed repository | 0 / 0 | 571 | Yes | Not detected |
| GEPA | 5,879 | MIT | 2 / 0 | 15 | Yes | Not detected |
Publisher-row note: FutureAGI’s 313 merged PRs include maintainers, internal contributors, and bots. It is not a count of outside community submissions or an external-contributor acceptance rate.
Method notes: stars and labels came from the GitHub API on 27 July 2026. “Merged” used the GitHub search query is:pr is:merged merged:>=2026-06-27. “Not detected” means GitHub’s community profile did not return the file; it is not proof that no community policy exists elsewhere. Row order is not a numerical ranking.

This snapshot is useful precisely because it can expire. Re-run the checks before investing a weekend.
Which Large Projects Have the Strongest Contribution Paths?
Large projects give you mature tests, review systems, and many subdomains. They also demand more reading before your first meaningful change.
vLLM: Best for Inference Systems
Best for: Python and C++ contributors interested in GPU serving, schedulers, kernels, model support, and distributed inference.
Current evidence:
- 87,339 stars and 1,074 merged PRs in the 30-day snapshot.
- 27 good-first issues and 36 help-wanted issues.
- CONTRIBUTING, code-of-conduct, and DCO files are present.
Where things get hard: a label does not make GPU code beginner-level. Start with documentation, tests, model compatibility, or a clearly scoped Python issue unless you already understand the serving path.
The vLLM explainer gives you the architecture vocabulary before you open the scheduler code.
promptfoo: Best for Evaluation and Red Teaming
Best for: TypeScript contributors who want visible work in evaluation, provider adapters, assertions, security testing, and documentation.
Current evidence:
- MIT license, CONTRIBUTING guide, and code of conduct.
- 208 merged PRs in the 30-day snapshot.
- No open good-first or help-wanted issues at the snapshot time.
Where things get hard: the empty newcomer-label queue means you should arrive with a reproducible bug, a provider gap, or a small documented proposal.
For the broader tool landscape, compare the open-source evaluation frameworks before deciding that promptfoo is the right codebase.
LangChain: Best for Integrations
Best for: contributors who want Python or JavaScript integrations, framework maintenance, tests, and documentation at ecosystem scale.
Current evidence:
- MIT license and a complete GitHub community profile.
- 11 open help-wanted issues.
- 135 merged PRs in the previous 30 days.
Where things get hard: the codebase is large, and an integration that looks isolated can affect shared abstractions. Read the package-specific guide and tests, not only the root README.
The open-source agent frameworks guide helps you decide whether LangChain’s abstractions are the ones you want to learn.
Langfuse: Best for Full-Stack Observability
Best for: TypeScript and infrastructure contributors interested in traces, prompts, datasets, evaluation workflows, and product analytics.
Current evidence:
- 31,961 stars and 571 merged PRs in the 30-day snapshot.
- A contribution guide is present.
- Core code is MIT-licensed, while enterprise modules use separate commercial terms under Langfuse’s repository license.
Where things get hard: the repository is not one-license-simple. Check which directory your change touches and read Langfuse’s licensing notes before assuming the core MIT terms cover it.
The open-source LLM observability comparison maps Langfuse against other tracing stacks.
Which Smaller Projects Let You See More of the System?
Smaller does not automatically mean easier. It means the architecture can be easier to hold in your head and a focused change is more visible.
DSPy: Best for Declarative LM Programming
Best for: Python contributors interested in signatures, modules, optimizers, adapters, and research ideas expressed as software.
Current evidence:
- MIT license and 36,415 stars.
- 38 merged PRs in the 30-day snapshot.
- A contribution guide and one open help-wanted issue.
Where things get hard: optimization behavior is easy to change and hard to validate. Good contributions need a clear experiment or regression test, not only a clean implementation.
Read what DSPy is and how its optimizer loop works before selecting an issue.
OLMo-core: Best for Model Training Internals
Best for: experienced Python and distributed-systems contributors who want to study a transparent training stack.
Current evidence:
- Apache-2.0 license and active development on 27 July.
- 51 merged PRs in the previous 30 days.
- A contribution guide, but no newcomer labels in the snapshot.
Where things get hard: this is not a beginner-first recommendation. Training code carries distributed, numerical, and reproducibility constraints that make “small” changes expensive to validate.
Use the current allenai/OLMo-core repository, not the quieter legacy allenai/OLMo codebase. The open-source versus open-weight guide explains why OLMo’s release transparency matters.
FutureAGI: Best Current First-Issue Inventory
Disclosure: FutureAGI publishes this blog and maintains the repository. We included it under the same snapshot method rather than presenting it as an independent winner.
Best for: Python, TypeScript, documentation, and AI-infrastructure contributors who want a large current queue of scoped starter issues.
Current evidence:
- Apache-2.0 license, contribution guide, and code of conduct.
- 106 open good-first issues.
- 313 merged PRs in the 30-day snapshot.
Where things get hard: a large label count can include uneven scope. Confirm the issue is current, unclaimed, and testable before starting. The community is also much smaller than vLLM, LangChain, or Langfuse.
The open-source stack for reliable AI agents shows where the repository’s eval, trace, guardrail, and optimization components fit.
GEPA: Best for a Compact Optimization Codebase
Best for: contributors interested in reflective prompt optimization and research-to-code work in a smaller Python repository.
Current evidence:
- MIT license and 5,879 stars.
- Two good-first issues and 15 merged PRs in the 30-day snapshot.
- A root contribution guide plus contributor documentation.
Where things get hard: a smaller maintainer group means review capacity can vary. Read recent merged pull requests before judging response time from the star count.
GEPA is an independent project. FutureAGI also implements a GEPA-style optimizer in its broader optimization stack; the similar name is not an ownership relationship.
How Should You Make the First Contribution?
Do not follow a universal “open an issue first” diagram. Repository policies differ.

Read the Local Rules
Start with CONTRIBUTING.md, the code of conduct, issue templates, and any CLA or DCO requirement.
GitHub’s current beginner guide to open-source contributions makes the same point: understand the repository before choosing the task.
Reproduce Before You Propose
Build the project, run the relevant tests, and reproduce the bug or missing behavior. Record the smallest example that demonstrates it.
If the project asks for an issue or design discussion, open one. If it accepts small fixes directly, do not add process the maintainers did not request.
Keep the Patch Reviewable
Change one thing. Add or update tests. Explain what changed, why it changed, and how you verified it.
Avoid drive-by refactors around the target. A first pull request should reduce reviewer uncertainty.
Stay Through the Review
Respond to comments, push follow-up commits, and close the loop if you can no longer continue.
A useful contribution is not the code you generated. It is the change the project can understand, test, maintain, and merge.
What Changes When You Use AI to Contribute?
AI assistance is now a repository-policy question, not only a personal workflow choice.
Ghostty’s AI policy requires disclosure and expects contributors to understand the code they submit. In a different response to AI-generated noise, tldraw temporarily closed external pull requests.
Before using an agent:
- check the repository’s AI policy and contribution guide;
- disclose assistance when required;
- verify licenses and provenance for copied code;
- run the full relevant test path;
- read and explain every changed line;
- commit to maintaining the patch through review.
“The model wrote it” is not an answer to a security, design, or test question.
Which Project Should You Choose This Week?
Pick by the work you want to understand:
- vLLM for inference infrastructure;
- promptfoo for eval and red-team workflows;
- LangChain for integrations;
- Langfuse for observability;
- DSPy or GEPA for optimization;
- OLMo-core for training systems;
- FutureAGI for a large current first-issue queue, with our affiliation in view.
Then rerun the live checks. Open one recent merged pull request. Read the contribution policy. Confirm the issue is current.
The best first project is not the easiest logo to recognize. It is the repository where you can explain the problem, test the fix, and stay long enough to get the change reviewed.
Frequently Asked Questions About Contributing to Open-Source AI Projects
What are the best open-source AI projects to contribute to in 2026?
How do I know whether a repository welcomes new contributors?
Should I open an issue before submitting a pull request?
Can I use AI coding tools for an open-source contribution?
Is a permissive license required for a contributor-friendly project?
Open-source software lets you use, study, and change code under an OSI license. Here are the license families, what does not qualify, and why it matters.
FutureAGI, DeepEval, Promptfoo, Ragas, UpTrain, Inspect AI, DeepChecks, MLflow Evaluate as OSS LLM eval frameworks in 2026. Compared.
Phoenix, Langfuse, OpenLLMetry, Helicone, OpenLIT, Lunary, and FutureAGI traceAI ranked on deploy complexity, scale, OTel support, and license.