Google Summer of Code 2026: Submit Your Project Ideas! 🚀

[AceTheCreator]

Hey folks! It's that time of the year again...

Google Summer of Code 2026 applications are open, and we're applying again this year. This is our chance to bring fresh energy, new contributors, and most importantly, future maintainers into the AsyncAPI ecosystem.

A Call to Maintainers

If you maintain any AsyncAPI project, this is your moment. GSoC 2026 is the perfect opportunity to onboard a new maintainer to your team. We're actively prioritizing projects that demonstrate a clear path to maintainership, where contributors don't just solve a problem, but become stewards of the codebase.

We've put together a playbook for mentors interested in GSoC on how to get the best from their contributors this summer. Feel free to have a look at https://docs.google.com/document/d/1vmvPCBRBe4UrGL7qkzNrwPyiFt5gp6yPscvmu--RRNQ/edit?usp=sharing.

Timeline: We Have Two Weeks!

We're running on a tight schedule. Project idea submissions close on February 1st, so we need your input now.

How to Submit Your Project Idea

Reply to this discussion with your project idea, or create a new issue thread in your project repository with the label gsoc-26. Include:

• Project Title: Clear and descriptive
• Problem Statement: What problem does this solve?
• Goals & Deliverables: What will be built?
• Skills Required: Languages, frameworks, tools
• Mentors: Your name(s) and availability
• Expected Timeline: Realistic summer timeline
• Maintainership Path: How can the contributor transition to a maintainer role?

What Makes a Great GSoC Project?

• Clear scope and well-defined deliverables
• Meaningful impact on the AsyncAPI ecosystem
• Strong mentorship and knowledge transfer opportunities
• Realistic timeline for summer work
• Clear path to maintainership or ongoing contribution

Why GSoC Matters for AsyncAPI

Last year was incredible. Our contributors shipped production-grade work, learned alongside experienced maintainers, and strengthened our community. Several GSoC alumni have stayed involved and become trusted voices in the ecosystem.

This year, we're doubling down by focusing on maintainership pathways. You're not just getting a summer project, you're building the next generation of AsyncAPI leaders.

Next Steps

Ready to mentor? Share your project idea in this discussion or start a new thread.

Questions? Drop a comment below or reach out in the AsyncAPI Slack.

Interested in contributing? Bookmark this discussion and come back when you're ready to apply!

How to connect with us

• Join our Slack workspace. Just make sure to follow our code of conduct.
• Join the dedicated Mentorship channel #mentorship that we will use to coordinate all mentorship programs at AsyncAPI

Let's make GSoC 2026 our best season yet. 💜

cc @asyncapi/tsc_members

[derberg]

afaik, looking at https://www.asyncapi.com/docs/community/030-project-vision-strategy-goals/2026_community_goals maintainership projects are the only way to go, not optional as you wrote We're actively prioritizing projects that demonstrate a clear path to maintainership

[AceTheCreator]

afaik, looking at https://www.asyncapi.com/docs/community/030-project-vision-strategy-goals/2026_community_goals maintainership projects are the only way to go, not optional as you wrote We're actively prioritizing projects that demonstrate a clear path to maintainership

By "actively prioritizing", I mean that maintainers are welcome to submit any project ideas, but we'll only move forward with those that have a clear maintainership pathway.

This logic is straightforward, more project submissions increase our chances of getting more GSoC slots from Google. So while we're filtering for maintainership-focused projects, casting a wider net upfront helps us secure more slots overall, which means more opportunities to onboard maintainers across the project.

In other words, we want quantity in submissions to boost our allocation, but quality (maintainership focus) in the ideas we actually advance. Except if you think otherwise? cc @thulieblack

[thulieblack]

@AceTheCreator, we should follow the voted Community Goals, even if we get only 2 projects under GSoC that serve the overall goal, that should be fine. Also, I believe we should also take into account the lessons we learnt from the previous GSoC.

For me, Maintenance projects are the only way to go; there isn't any other option.

[imabp]

AsyncAPI Spec MCP is one of the projects i wanted to start with @derberg mainly focussing on building an AI layer over the spec that can be consumed by any MCP client.

[SamarthShukla17]

Hi everyone 👋,

I’m a prospective GSoC 2026 mentee interested in contributing to the AsyncAPI ecosystem, particularly around the AsyncAPI website.

After reviewing the outcomes of the GSoC 2025 website redesign and the current open website issues, it appears that many of the remaining problems cluster into a few clear, high-impact areas. Based on that, I wanted to suggest the following potential GSoC project ideas that mentors could adopt or refine.

---

Project Idea 1: Theming & Dark Mode Hardening for AsyncAPI Website

Problem Statement
Dark mode and theming are still incomplete or inconsistent across the website, leading to recurring issues and regressions.

Goals & Deliverables

• Complete and stabilize dark mode across all pages
• Ensure consistent theme tokens, contrast, and persistence
• Prevent regressions through better structure and testing

Skills Required
React, Next.js, TypeScript, TailwindCSS, CSS theming

Maintainership Path
Contributor gains deep ownership of website theming and long-term responsibility for visual consistency.

---

Project Idea 2: Accessibility (a11y) Improvements for AsyncAPI Website

Problem Statement
Accessibility gaps (contrast, keyboard navigation, motion preferences) exist across multiple pages and components.

Goals & Deliverables

• Systematic a11y improvements across the website
• Address common accessibility issues and standards compliance
• Improve inclusivity and usability for all users

Skills Required
Web accessibility (a11y), React, semantic HTML, CSS

Maintainership Path
Contributor becomes a go-to maintainer for accessibility standards on the website.

---

Project Idea 3: UI Consistency & Design System Hardening

Problem Statement
Recurring UI and layout issues indicate gaps in component consistency and design system enforcement.

Goals & Deliverables

• Improve component consistency, spacing, and responsiveness
• Reduce recurring UI/layout bugs
• Make the website easier to maintain and extend

Skills Required
React, Next.js, TypeScript, TailwindCSS, component design

Maintainership Path
Contributor takes long-term ownership of the website UI and design system.

---

All three ideas build on the existing redesign rather than redoing it, aim to reduce recurring website issues, and provide a clear path toward maintainership.

Personally, I’d be very interested in applying as a mentee for either the UI consistency/design system project or the theming & dark mode project, if mentors feel these ideas align with AsyncAPI’s GSoC 2026 goals.

Happy to refine scope or align with maintainers on priorities.
Thanks for your time — excited to contribute!

— Samarth

[princerajpoot20]

We will not proceed with this one. FYR: https://github.com/orgs/asyncapi/discussions/2247#discussioncomment-15618780

[rohithyarramala]

Hi @AceTheCreator , @derberg, and @thulieblack ! 🚀

I’d like to propose a project that aligns with the 2026 goal of building sustainable maintainership through intelligent automation.

Project Title: AI-Powered Assistant & Automated Spec Validator
Problem Statement: New users often struggle with AsyncAPI schema complexities, and maintainers spend significant time correcting repetitive errors in community-submitted specs or answering standard documentation questions.

Goals & Deliverables:
AI Verification Pipeline: An automated flow that verifies AsyncAPI code against instructions and auto-fixes schema inconsistencies. (I have already developed a working prototype for this).
Assistant Integration: A lightweight, fine-tuned model (Phi-2) integrated into the AsyncAPI Website and Studio for real-time debugging and support.
Low-Cost Infrastructure: Deployment using vLLM/Ollama to ensure the tool remains cost-effective for the organization.

Skills Required:
Python (FastAPI, PyTorch/Transformers)
JavaScript/TypeScript (for Website/Studio integration)
LLM Fine-tuning & Data Scraping

Expected Timeline: June: Data collection ( its already done by help of lukasz ) in the past year, fine-tuning Phi-2, and integration of web llm with the dynamic loading (deployment ).
July: Integration with the AsyncAPI website and Studio sidebar.
August: Optimisation (quantisation), 1st-line support automation, and final documentation.

Maintainership Path: I am committed to becoming the long-term steward of the AI/Chatbot repository. My goal is to maintain the fine-tuning datasets, manage the verification logic, and onboard future contributors as the AsyncAPI spec evolves.

Feasibility & Progress: I have already prototyped the verification pipeline and the UI layout. You can see the initial logic and model progress here: https://www.awesomescreenshot.com/video/39400218?key=6ddfcafebd825b206a8c1d0314fdc839.

isit really useful : now a days many team uses ( chatgpt, claude or even gemini ) model for development but here the any of the modals unable to create a perfect asyncapi specification ;

it help experienced one to make thier work faster , and new commer learn and adapt faster

Best, Rohith Yarramala

[princerajpoot20]

FYI: Starting this thread as a heads-up.
I would like to propose a maintainership-focused project for the website repo.

I will discuss this with other folks and share the project idea according to the template in the coming week. I will edit it here itself.

[princerajpoot20]

A small request to all the mentors proposing ideas: please re-review the project and your availability. In case you are not available, we should have a backup plan for mentorship.

The reason I’m saying this is that we currently have a couple of 2025 GSoC projects that are still ongoing, even though the program has officially ended.
This does not look good for us as an organization.

Hence, please keep this in mind. Otherwise, there is a possibility that we might not qualify in the future because of such incidents.

cc: @asyncapi/tsc_members

[SamarthShukla17]

@princerajpoot20 @AceTheCreator

Thanks for raising this — I think this is an important point to keep in mind.

From a contributor/mentee perspective, one possible way to reduce this risk (especially for the website) could be to consolidate overlapping or ongoing efforts into a single, clearly owned GSoC project, rather than splitting them across loosely related tasks.

For the AsyncAPI website specifically, a lot of the remaining open issues and follow-up work from the 2025 redesign seem to overlap around:

• theming & dark mode,
• UI consistency,
• and design system enforcement.

Instead of treating these as separate tracks, this could potentially be framed as one focused website hardening project that:

• builds directly on the existing redesign,
• prioritizes finishing and stabilizing core UI/theming work,
• and gives a contributor clear ownership and accountability over a well-defined surface area.

I’d be very interested in working on such a consolidated website project (combining theming/dark mode + UI consistency/design system hardening), under active mentorship, to help ensure this area is properly completed and maintained long-term.

Happy to adapt scope based on mentor availability — just wanted to share this as a possible way to align with the maintainership and risk-reduction goals you mentioned.

[SamarthShukla17]

Sharing a concrete GSoC 2026 website project idea here for visibility:
👉 asyncapi/website#5023

[princerajpoot20]

Sharing this here as well for reference.
The work is part of last year’s GSoC project, and it will be completed by @Shriya-Chauhan as part of that.

I know we are delayed in completing it, but since it is part of her work, it cannot be outsourced to someone else or turned into a new project idea to do the remaining work.

There isn’t much work left. Mostly final changes and refactoring.

Hence, we will not proceed with the same issue again and again in every GSoC.

In the worst case, if @Shriya-Chauhan decides not to continue for any reason (though I’m confident we won’t be in that situation), the remaining ad hoc work can be done outside GSoC. There is no need to include it again as part of GSoC.

[SamarthShukla17]

Sure, thanks for the heads up. Meanwhile I'll look into other issues.

[Anuragsharma15-dell]

Hi @AceTheCreator , @derberg, and @thulieblack ! ✋

I’d like to propose a project that aligns with the 2026 goal of building sustainable maintainership through intelligent automation and tooling.

Project Title: AsyncAPI CLI Semantic Linter & Auto-Fix Engine

Problem Statement

The AsyncAPI CLI currently provides validation that focuses on syntactic correctness via the AsyncAPI Parser. While this ensures specs conform to the specification, it does not address semantic quality, best practices, or long-term maintainability.

As a result, AsyncAPI documents that pass validation may still suffer from:

inconsistent naming and structure

unclear or missing documentation

duplicated message and schema definitions

misuse of references

patterns that make future evolution difficult

These issues are repeatedly caught during manual reviews by maintainers and are not enforced consistently across projects. The CLI lacks a first-class mechanism to encode AsyncAPI best practices and provide actionable, automated feedback to users.

Goals & Deliverables

1. CLI-Native Linter Command

Introduce a new first-class CLI command:

asyncapi lint

asyncapi lint --fix

Integrate seamlessly with existing CLI command structure and configuration patterns

Support human-readable and machine-readable outputs for local use and CI pipelines

2. Linter Core (CLI Plugin Architecture)

Implement the linter as a core CLI module written in TypeScript

Use @asyncapi/parser to parse and validate the AsyncAPI document once, then reuse the parsed model for linting

Build an internal traversal layer that walks:

channels

operations

messages

schemas

components and references

3. Rule Engine Design

Define a standardized lint rule interface within the CLI:

rule metadata (id, description, severity, category)

target node types

execution logic

optional auto-fix function

Enable rule configuration via:

CLI flags

project-level configuration files (e.g. .asyncapirc)

Support severity levels aligned with CLI exit codes (error → fail, warning → pass with warnings)

4. Semantic Rule Categories
   Structural Consistency

Ensure channels, operations, and messages are coherently connected

Detect unused or orphaned message definitions

Flag inconsistent payload usage across operations

Documentation Quality

Enforce required descriptions on channels, messages, and operations

Detect placeholder or low-signal documentation

Encourage examples where applicable

Reusability & Reference Hygiene

Detect duplicated schemas or messages that should be referenced

Validate correct and consistent $ref usage

Flag excessive inline definitions that reduce reuse

Maintainability & Evolution

Detect patterns likely to introduce breaking changes

Encourage backward-compatible schema practices

Flag missing versioning or deprecation metadata

5. Auto-Fix Engine

Implement an opt-in auto-fix pipeline within the CLI

Allow rules to expose deterministic, non-breaking fixes

Apply fixes through controlled transformations of the parsed AsyncAPI model

Provide:

fix previews

selective rule-based fixing

safe rollback on failure

6. CI & GitHub Action Integration

Expose linting functionality via the existing AsyncAPI CLI GitHub Action

Enable maintainers to:

enforce linting as a required PR check

differentiate between warnings and errors

Output inline annotations for improved review experience

7. Rule Governance Inside CLI

Ship a default AsyncAPI Recommended Ruleset bundled with the CLI

Version rules independently to align with AsyncAPI spec evolution

Provide contribution guidelines focused on:

adding new rules

improving existing rules

minimizing changes to core CLI logic

8. Add a new asyncapi quality or asyncapi lint command to the AsyncAPI CLI

Build a rule-driven linting framework inside the CLI that supports:

best-practice enforcement

structural consistency checks

documentation quality rules

reusability and reference hygiene

Create a configurable rule engine that allows users to enable/disable rules and customize severity

Implement a safe auto-fix mode (--fix) to automatically correct common issues with a preview of changes

Provide a built-in “AsyncAPI Quality Ruleset” maintained by AsyncAPI maintainers

Provide CI integration through GitHub Actions with clear reporting and PR annotations

9. testing & Reliability

Add comprehensive tests inside the CLI repo:

unit tests for rule logic

integration tests for asyncapi lint command

regression tests for auto-fix safety

Ensure deterministic behavior across environments and spec sizes

Technologies & Implementation Details

Language: TypeScript

Core Dependencies:

@asyncapi/parser (parsing & base validation)

CLI Framework: Existing AsyncAPI CLI architecture

Testing: Jest

CI Integration: GitHub Actions via AsyncAPI CLI Action

Maintainership Path

Ownership centers on the linting subsystem inside the AsyncAPI CLI.
The maintainer is responsible for:

evolving semantic rules alongside the AsyncAPI specification

reviewing rule contributions from the community

maintaining CLI integrations and CI behavior

ensuring lint rules remain consistent and stable across CLI releases

This structure allows future contributors to start by authoring lint rules, gradually progressing toward deeper CLI ownership.

[Adi-204]

Project idea: AsyncAPI Generator Maintainership - A complete hands-on open source experience

Goal: To mentor contributors in becoming maintainers of the AsyncAPI Generator by developing real-world maintainership skills beyond coding, including project ownership, code review, issue triage, and long-term project stewardship.

Issue - asyncapi/generator#1860

[thulieblack]

I keep seeing ideas being shared, but some of the most important things are missing.

Its crucial to go through the details Ace shared on How to Submit your Idea

• Project Title: Clear and descriptive
• Problem Statement: What problem does this solve?
• Goals & Deliverables: What will be built?
• Skills Required: Languages, frameworks, tools
• Mentors: Your name(s) and availability
• Expected Timeline: Realistic summer timeline
• Maintainership Path: How can the contributor transition to a maintainer role?

[Shurtu-gal]

@AceTheCreator @thulieblack this might not be the correct place to ask but what is supposed to be done for incomplete projects in previous GSoC programs?

Example: asyncapi/studio#224 was in GSoC 2024 under @smoya but has not gone to completion.

Should I just go ahead as a maintainer and complete the issue?

[AayushSaini101]

GSoC Project for the CLI: asyncapi/cli#1991 @AceTheCreator @thulieblack

[harshvvardhann]

I wanna contribute to projects, can anyone tell me where can i see projects and how can i contribute to them in breif...

[princerajpoot20]

GSoC Project idea: AsyncAPI Website Maintainership - more than just contribution

Issue - asyncapi/website#5052

[vakrahul]

hey guys so when will the final project will be announced

[SamarthShukla17]

Hi @princerajpoot20 and @vishvamsinh28 — thanks for opening this maintainership-focused GSoC idea. (asyncapi/website#5052)

I’d like to align myself with this specific project and use it as the basis for my GSoC 2026 proposal.

Over the last few days, I’ve been going through the AsyncAPI website repository — reading open issues, PRs, and parts of the frontend code — to better understand the kind of work maintainers actually deal with. From what I’ve observed, a significant portion of the ongoing maintenance effort involves frontend-related topics such as UI consistency, component reuse, and review coordination, rather than just adding new features.

What interests me about this project is the explicit focus on maintainership as a responsibility, not just contribution. I’m specifically interested in growing into a frontend-focused website maintainer by:

helping with frontend-related issue triage over time,

contributing small, well-scoped fixes and refactors,

reviewing PRs where appropriate to reduce maintainer load,

and improving documentation or conventions where things are unclear for new contributors.

I want to be transparent that my AsyncAPI contribution history is still at an early stage. My goal is to start with modest, well-aligned contributions and build trust through consistency and responsiveness — both during GSoC and beyond it.

If possible, I’d really appreciate guidance on:

which areas of the website would currently benefit most from a new maintainer-in-training,

what kinds of early contributions you’d consider most meaningful as proposal groundwork,

and any expectations you’d like a strong proposal for this project to address explicitly.

I’ll be drafting my proposal using the official GSoC template and would be glad to refine it based on your feedback so it aligns closely with how you envision this maintainership journey.

Thanks for your time — happy to learn and contribute.

[AceTheCreator]

GSoC Project Idea Proposals:

• Conference Website
• AsyncAPI React

[Khushboo1324]

Hi @AceTheCreator, @derberg, and @thulieblack 👋,

I’d like to propose a GSoC 2026 project idea aimed at improving the sustainability of the AsyncAPI Conference platform by enhancing its codebase structure and building unified developer documentation to strengthen long-term maintainability and contributor onboarding.

Project Title: Improving the AsyncAPI Conference Website and Building Unified Developer Documentation for Long-Term Sustainability

Background & Motivation :
While exploring the AsyncAPI repositories and attempting to contribute, I noticed that finding specific documentation, setup instructions, and workflow details was sometimes challenging, especially during the initial stages. Understanding project architecture and contribution processes required navigating multiple sources.
This experience highlighted the importance of having clear, centralized, and well-structured documentation alongside a clean and maintainable codebase.
Motivated by this, I would like to work on improving both the technical structure of the conference website and the accessibility of contributor documentation.

Problem Statement:
The AsyncAPI Conference website plays a critical role in the community, but currently faces challenges such as:

• Scattered and limited onboarding documentation
• Technical debt and duplicated logic
• Difficulties for new contributors in understanding workflows
• Risk of long-term maintainership gaps
  These issues increase maintenance overhead and slow down community growth.

Project Goals & Deliverables:

Core Website Improvements

• Refactor and modularize the codebase
• Reduce technical debt and duplicated logic
• Improve performance and accessibility
• Enhance schedule, speaker, and meetup systems

Unified Documentation Platform

• Create centralized onboarding guides
• Document architecture and workflows
• Consolidate existing resources
• Add tutorials and best practices

Sustainability Enhancements

• Define clear maintenance workflows
• Improve contribution guidelines
• Establish ownership boundaries

Skills Required:

• JavaScript / TypeScript
• React / Next.js
• Git & GitHub
• Web performance and accessibility
• Technical writing

Expected Timeline:

• Weeks 1–2: Community bonding and setup
• Weeks 3–6: Refactoring and cleanup
• Weeks 7–9: Feature improvements
• Weeks 10–12: Documentation development
• Weeks 13–14: Integration and testing
• Weeks 15–16: Handover and maintenance preparation

Maintainership Path:
Throughout the program, I plan to:

• Take ownership of selected components
• Participate actively in reviews and discussions
• Maintain documentation updates
• Assist new contributors
  After GSoC, I aim to continue contributing as a long-term maintainer by managing features, reviewing pull requests, and supporting community members.

Availability:
I can dedicate approximately 22–28 hours per week during the GSoC period and am committed to maintaining consistent communication with mentors.

I would be grateful for your feedback on this proposal and would be happy to refine it based on community suggestions. I look forward to contributing to the long-term success of the AsyncAPI ecosystem.

Thank you for your time and guidance.

Best regards,
Choudhary Khushboo

[Prasad8830]

Does anyone know where we can find the final list of this year's projects?

[sammy200-ui]

i think you are referring this #2276

[KUNDAN1334]

---

GSoC 2026 AsyncAPI React Component Applicant

Hey @AceTheCreator @asyncapi/core @asyncapi/mentors!

Already contributed 2 PRs:
PR 1 : Next.js 16 Playground fix (100% working localhost:3000) [ https://github.com/asyncapi/asyncapi-react/pull/1229]
PR 2: README broken link fix [ https://github.com/asyncapi/asyncapi-react/pull/1230]

Ready for main GSoC project:

• no-parser distribution fix (Phase 1)
• Extension system design (Phase 2)
• Angular integration (Phase 3)
• Full maintainership transition

Playground tested: Multiple AsyncAPI 3.0 specs + schema examples working perfectly!

Next: Targeting good-first-issues + detailed proposal by March.

Weekly sync possible? Ready to own asyncapi-react long-term!