By the time you're reading this, many students have already discovered the Apache IoTDB project ideas for Google Summer of Code (GSoC) 2026. Interest is usually high — but only a limited number of proposals can be accepted each year.
Successful proposals usually share a few common characteristics: preparation, clear technical design, and early interaction with the community.
If you plan to apply to Apache IoTDB under the Apache Software Foundation, this guide will help you avoid common pitfalls and submit a proposal that mentors can confidently support.
⚠️ For more details about the program, please refer to our previous blog: "Join Apache IoTDB in GSoC 2026: Project Ideas Now Open".
How Mentors Evaluate Proposals
Before writing a single paragraph, understand how proposals are typically reviewed.
IoTDB mentors tend to look for evidence that you can:
understand an existing distributed system
design changes that fit the architecture
deliver working, tested code
communicate clearly with the community mentor
A polished document without technical depth rarely succeeds. Conversely, a technically grounded proposal — even if not perfect — stands out quickly.
What Strong Proposals Usually Show
Across previous years, successful applicants typically demonstrate three things early:
1. Evidence of Code Familiarity
Mentors quickly notice whether you have:
read relevant modules
traced data flow
understood key abstractions
identified real constraints
💡 Tip: Reference specific classes, APIs, or components when possible.
2. Prior Community Interaction
One of the ASF evaluation signals is community engagement.
Strong applicants usually:
introduce themselves to community
ask focused technical questions
discuss design trade-offs
respond constructively to feedback
👉 IoTDB dev mailing list:
👉 Community channels:
Proposals from students who have not engaged with the community beforehand are generally seen as higher risk.
3. Realistic Execution Planning
GSoC is a time-bounded engineering project, not an open-ended research idea.
Mentors expect:
scoped milestones
measurable deliverables
buffer time for debugging
awareness of risks
Overly ambitious plans are often down-rated.
Recommended Proposal Structure (ASF-Aligned)
The ASF provides a template. Below is how to make each section actually work in practice.
About Me — Focus on Signal, Not Length
Keep this concise and relevant.
Good content includes:
Java/Python experience (depending on project)
database or distributed systems coursework
open-source contributions
relevant internships or projects
Less helpful:
generic self-descriptions
unrelated achievements
long autobiographies
Mentors are scanning for technical readiness.
💡 Full Reference: https://community.apache.org/gsoc/#application-template
Background — Show You Did the Homework
This section is where many proposals become too superficial.
You should clearly explain:
what currently exists
where the limitations are
what can be reused
what must be built
For example:
Connector projects should discuss pushdown limitations
Integration projects should discuss data model mapping
AINode projects should discuss model deployment constraints
Goal: convince mentors you understand the problem space, not just the idea title.
Design & Technical Approach — The Make-or-Break Section
This is the most heavily weighted part of your proposal.
A strong design section typically includes:
high-level architecture diagram
component breakdown
data flow explanation
API interaction points
edge case considerations
Depending on your chosen project:
Connector work should define schema/type mapping clearly
Stream integration should explain source/sink semantics
AI projects should describe model loading and device handling
Avoid vague statements like:
"The system will efficiently process data."
Instead, be concrete about how.
Deliverables — Make Them Measurable
Your deliverables should be objectively verifiable.
Good examples:
Connector supports predicate pushdown for time filters
Integration tests covering major data types
Documentation with deployment steps
Benchmark report with defined workload
Weak examples:
"Improve performance"
"Optimize queries"
"Enhance usability"
If mentors cannot measure completion, the proposal feels risky.
Timeline — Be Realistic and Structured
A typical medium project should include:
community bonding tasks
phased implementation
testing period
documentation window
buffer for unexpected issues
Common mistake: allocating zero time for debugging.
Always leave slack.
Common Mistakes to Avoid
Every year, mentors see patterns that hurt otherwise capable applicants.
Watch for these:
❌ No prior communication with the community
❌ Proposal repeats the idea page without analysis
❌ No evidence of code exploration
❌ Timeline is overly aggressive
❌ Design lacks architectural detail
❌ No testing strategy
❌ Copy-pasted or template-heavy writing
Avoiding these alone already improves your odds significantly.
How to Engage Effectively with the IoTDB Community
If you have not interacted yet, start now.
Recommended approach:
Subscribe to the dev mailing list
Read recent discussions and documentations
Introduce yourself briefly
Ask one well-researched question
Attempt a small contribution(for example, fixing a GitHub issue)
👉 Community Group: https://github.com/apache/iotdb/issues/1995#english
👉 Apache IoTDB: https://iotdb.apache.org/
👉 IoTDB GitHub: https://github.com/apache/iotdb
Public discussions help both mentors and other contributors follow the conversation and provide feedback. Quality of interaction matters far more than volume.
Final Pre-Submission Checklist
Before you submit, verify:
✅ You have communicated with the mentor
✅ Your design includes concrete technical details
✅ Deliverables are measurable
✅ Timeline includes buffer time
✅ Proposal has been proofread
✅ You understand the IoTDB architecture basics
If several boxes are unchecked, improve the proposal before submitting.
⚠️ Still have questions? Feel free to reach out to us anytime.
Closing Thoughts
GSoC with Apache IoTDB is both demanding and rewarding. The community values contributors who are curious, technically grounded, and collaborative.
If you invest time now — reading code, asking good questions, and refining your design — your proposal will stand out naturally.
We look forward to seeing your ideas and working with the next generation of IoTDB contributors.
