From Blank Slate to GSoC 2025 Contributor: What Really Made the Difference

When people ask me to share my GSoC proposal, I always understand the reason: A good proposal is one of the key pieces that gets you selected.

But one thing I have come to believe deeply is that the proposal is not the beginning of the journey, and it’s certainly not the end. It’s the output, the final result of weeks of research, exploration, doubt, learning, and growth. And if there’s anything I hope this post offers, it’s not just the proposal itself, but the process that made it possible.

I want to share what actually helped me earn a spot in GSoC. Not the polished end product, but the messy middle: the decisions, the mindset, the people I met, and the thinking I had to develop along the way. Because that’s what really made the difference.

I Started with Nothing, Then Researched Relentlessly

When I first saw the p5.js idea titled “Friendly Sketch Embedder”, I had no idea what creative coding even meant. I didn’t understand how embedding worked, what “instance mode” referred to, or how something like p5.js could be integrated into modern websites. But I didn’t let that stop me.

Instead, I leaned into curiosity. I started with the name, Friendly Sketch Embedder, and asked, “What does that mean?” That one question took me down a rabbit hole. I started Googling terms. I tried to find existing embedding tools. I played with whatever examples I could find. I kept a doc open where I dumped every small thing I learned. Slowly, the fog began to lift. And because I was actively writing, testing, and experimenting, I wasn’t just consuming information, I was processing it.

I Reached Out to Real People, Especially on LinkedIn

One of the most valuable decisions I made during my preparation was stepping outside my own bubble. I knew I couldn’t figure everything out alone, and I didn’t want to. So I started reaching out to real people, especially on LinkedIn.

I searched for people in the creative coding and p5.js space. I sent thoughtful DMs and emails. I didn’t just say, “Can you help?” I explained what I was working on, what I didn’t understand, and why their insights would mean a lot. One of the people who responded and truly made a difference was Umar. He patiently walked me through key concepts and even gave me suggestions on how to proceed with my idea.

That early feedback helped me clarify my approach and gave me the confidence to go even deeper. Later on, I joined the p5.js Discord server. Again, I didn’t just lurk or say hi. I asked specific questions. I shared context. And the community responded with openness and clarity. Through them, I learned about existing tools, embedding methods, and got pointed toward real examples, some of which dramatically improved my proposal.

I Used ChatGPT, But Not in a Shallow Way

Let’s talk about AI, because yes, I used ChatGPT. But I never used it to write my proposal for me. I used it the way you would use a mentor if you had one beside you: as a sounding board.

I would share an idea I was considering, like using iframe vs. script tags for embedding, and ask it to challenge me. I would prompt it with:
“What are the trade-offs between using srcdoc in an iframe versus injecting code through a script tag?” Or: “Can you help me understand the implications of global scope pollution in p5.js?”

And because I came with questions, not answers, I got responses that helped me see deeper. ChatGPT became a partner in the thinking process. It pushed me to clarify assumptions and reason through architecture, not just take shortcuts. That made me more prepared when talking to mentors and writing the proposal.

I Built a Prototype Alongside My Proposal

This was probably the single most impactful thing I did. While writing the proposal, I started coding a prototype, even though it wasn’t required. I wanted to test my ideas in practice. Could I actually generate iframe and script-based embeds dynamically? Would p5 sketches run inside the embedded preview?

As I built, I discovered edge cases. I ran into limitations. I learned how browsers interpret embedded JavaScript. I played with the srcdoc attribute. I had to debug sketch rendering issues. All of this made my proposal sharper. Because I wasn’t guessing anymore, I was speaking from experience.

By the time I submitted, my proposal included working code examples and clear justifications for each technical decision. That made it not just a proposal, but a small demonstration of commitment.

I was told by the organisation that the level of depth and clarity in how I wrote my solution made my proposal stand out.

I Asked Better Questions as I Learned More

In the beginning, my questions were broad and hesitant. I was figuring things out, and that’s okay. But as I learned more, I realized that the quality of your questions reflects the depth of your understanding.

Instead of asking “What should I do?” I began asking,
“How can I maintain sketch interactivity while preventing global variable collisions?”
or
“What’s the best way to structure an embed tool that supports both beginners and power users?”

I Documented Everything, Even the Messy Parts

I didn’t just work in private. I pushed everything, ideas, code snippets, and random notes to GitHub. It wasn’t perfect. Some branches were half-broken. Some commits were just notes to myself. But it showed progress. It showed that I was serious.

More importantly, it helped me keep track of how my thinking evolved. When I went back and saw how my approach had changed, it gave me a sense of how much I had grown, even before getting accepted.

Final Thought: The Proposal Matters, But What Leads to It Matters More

Yes, your proposal has to be strong. It needs to be detailed, logical, and thoughtfully structured. But what gives it power is the story that leads up to it. The research. The curiosity. The conversations. The experiments. The late nights trying to figure out why your iframe won’t render the canvas.

If you’re applying to GSoC or any open-source program, don’t just ask for someone’s proposal template. Ask what questions they asked. What prototypes did they build? How they learned what to leave out.

And then build your own.

If you’ve been through this process, I would love to hear your story, too. What helped you grow during your GSoC journey? Let’s create better resources for future contributors.

If you’d like to see the proposal that came out of this process, feel free to send me a DM I am happy to share it and answer any questions you might have.

#GSoC #OpenSource #GoogleSummerOfCode #CreativeCoding #p5js #DeveloperExperience #LearningInPublic #TechWriting