GSoC 2026: The Full Story
I recently finished Google Summer of Code 2026, and for a long time before that, I didn't know if I'd ever get to say that sentence. Here's the story of how it actually happened.
It started in October the year before, right after a college project I’d worked on under a batch of seniors who mentored a group of us. As soon as that project ended, those seniors sat us down and told us what came next. They talked about a program called Google Summer of Code, mentioned that people from our circle had gotten in the year before, and said that if we wanted to keep building something real once college gave us time back, this was a good place to look. I’d known about GSoC for about a year by then. I’d asked people a few questions here and there, but never really acted on it. That “later” had finally arrived, and I found out I wasn’t ready for it.
September and October that year weren’t great, honestly. I wasn’t focused on anything, not GSoC, not my own studies, not really anything. I wanted to do GSoC but had no clue what I wanted to work on, and I wasn’t being serious enough about figuring it out either. At some point during those two months I just decided to cut back on a lot of things that were taking up my time and energy without going anywhere, mostly random distractions I’d let pile up. Nothing major happened to trigger it, I just sat down one day and figured I needed to focus. Looking back, it’s still one of the better decisions I’ve made, even if it didn’t feel like a big deal at the time.
Around that same September, I started looking at a few open source organizations. ArduPilot, which works on drones and autonomous vehicles. Project Mesa, a Python framework for simulating small independent “agents” that follow simple rules and end up creating complex behavior when you put a lot of them together. SymPy, a library that lets code do algebra and calculus symbolically instead of just crunching numbers. And GNU Octave, which is basically a free and open version of MATLAB. Each of these had its own short chapter in my life that September and October. ArduPilot came first, and I went in with zero guidance, clicking through random issues. I picked one and started working on it, and before I could finish, someone else solved it. That happens a lot in open source. There’s almost always someone faster working on the same thing. I was also at the lowest point of my distraction phase right then, so ArduPilot never really stuck.
Somewhere in that mess, though, one thought stayed with me: doing GSoC just for the sake of GSoC isn’t worth much. The stipend, the resume line, whatever prestige people imagine comes with it, none of that survives the actual work. What you need is something you’d stay up late for even if nobody was paying you anything. Something close to an addiction, but a good one.
On a senior’s suggestion, I turned to Octave. Its core is confusing, and honestly it still is for me. I looked at the previous year’s GSoC projects, one from the statistics package and one from a package called chebfun, found chebfun equally confusing, and picked statistics mostly on instinct. Then came the annoying part of just building Octave from source, which kept throwing errors at me until it finally compiled. Small win, nothing exciting. And then 20 days of doing nothing at all. I had it installed and no idea what to actually do with it, so I just left it there. I wasn’t even sure anymore if I wanted to do this.
Then one ordinary morning, after DIWALI a senior named Swayam Shah texted me. Just a simple check in, asking what I was doing after the project and how GSoC prep was going. Nothing dramatic about the message itself. But something about someone who had no real reason to care, still checking in, hit me differently. I wasn’t even checking in on myself like that. I decided right there to leave behind whatever had been holding me back and give this a proper shot. Not really for GSoC, but because I wanted to be connected to something again, to keep showing up for the same thing again and again instead of drifting.
I found an issue asking for the makima interpolation function to be implemented in Octave. My technical background at the time was solid C++, since I’d been doing it since 11th standard and it was really the only thing I was good at, plus some introductory Python and C#. Nothing specific to statistics. I read the contributing guidelines and the attached MATLAB documentation, understood enough to get started, used AI to help debug my own shaky first attempt, and eventually got something that technically worked, as long as you didn’t look too closely. Thin validation, weak error handling, more proof that it could run than a finished function. I opened a pull request anyway, with the copyright header, documentation, code, and a few test cases that, looking back, weren’t even checked against real MATLAB output. They just compared against my own code’s behavior, which isn’t a great way to test anything, but I didn’t know better yet.
And then something happened I didn’t expect. Andreas Bertsatos, who’s my mentor now, actually looked at the PR. He appreciated it, and he even posted about it in the maintainers’ chat, giving credit for the contribution. In open source, a lot of pull requests just disappear into silence, especially now with so much AI generated noise making maintainers cautious about reviewing things closely. Getting seen like that felt like a big deal. My code wasn’t following the project’s style, but that’s not something you get on your first try anyway. It comes with time and a lot of small corrections, and I’m still not sure I’ve fully got it even now. The PR eventually merged, and I spent the next few days being pretty insufferable about it to anyone who’d listen.
Around the same time, on the Octave community forum, Andreas and other developers would post test cases and ask for real MATLAB output to compare against. I started running those and posting the results back, and I kept doing this for months. No pull request attached, no visible credit, nothing flashy. But that’s how the other developers, and Andreas especially, got to know me before I’d built anything major. Some weeks I’d test an entire feature and its test suite while he was still working on it. That kind of quiet consistency ended up mattering more than I realized at the time.
Toward the end of that year, I went deeper into the statistics package and its dependency, a package called datatypes, and one of my bigger contributions there was upgrading an embedded library called LIBSVM from a 2021 version all the way up to the current one, and enabling a feature it hadn’t supported before. The funniest memory attached to this is from a hackathon I went to around the same time, MumbaiHacks, which honestly had some of the worst logistics I’ve seen. No stable wifi, no charging points, general chaos. And that was the exact evening both pull requests merged. Warnings started showing up in the terminal for anyone using Octave, Andreas tagged me to fix it, and there it was on 4% battery with a bad hotspot trying to sort out a package release from a hackathon floor. Somehow it got fixed. The best part is this happened 2 days before end semester exams, so the next morning we packed up and went home to study. Small consolation, whatever we built that chaotic night still got our team into the top 10% of teams at that event.
Going back a bit, on 19th October that same year, Andreas had opened two new issues on the statistics repository. One for building a LinearModel framework from scratch, and one for building an anova framework. Neither of us knew it then, but these were exactly the two projects that became GSoC 2026. Reading the LinearModel one for the first time, I remember thinking it sounded huge, way bigger than anything I could take on. Building a whole class from scratch is very different from patching a single function. There’s the architecture, the edge cases, and the discipline of matching another language’s behavior down to the smallest detail. It’s also never really about how much you already know going in. It’s about what the project actually needs, what already exists, and where the real gaps are. You don’t get to choose the shape of the problem.
I also knew I couldn’t just walk up to Andreas and ask for hand holding without having anything to show. He’s a researcher and professor, and the only person reviewing every single pull request on that package. But every single time I did bring something concrete, a real contribution or a real question, he’d answer in full detail. Every time. The guidance was always there. You just had to show up with something first.
In the middle of my next round of exams, I picked up a smaller task related to what would eventually become a fraction of something similar to my GSoC project, adding a summary method to the cvpartition class and integrating a table structure into it. The review comments on that one PR alone taught me a lot about exactly what was missing and why. I had exams the next morning on plenty of those nights and genuinely did not care. I’d study 4 to 5 hours right before the exam and spend the rest of the night on Octave. Somehow the semester still ended at 8.78, helped by a strong lab component and a bit of luck on which questions actually showed up. Not exactly a method I’d recommend, but it worked out.
Riding that bit of confidence, I asked Andreas in mid December if there was any groundwork needed on the anova project. His answer stuck with me because it was honest. He said that without deep statistical knowledge of ANOVA specifically, it was better to leave it for later, since it needed a lot more time and complexity than standalone functions, and he simply didn’t have the bandwidth to walk someone through it step by step while also maintaining the whole package. That, he said, was exactly why he’d floated it as a possible GSoC project in the first place. So I put that energy into research instead. Over the next 2 months I basically wrote an unofficial research paper on both projects, going through past GSoC implementations, the newest classes already built, the underlying dependencies, and mapping out exactly what existed versus what these two issues were actually asking for. Not a formal proposal yet, just groundwork.
There were 2 to 3 other people also active in Octave around that time, and I was the most consistent of the group and the first to really get going. A senior also reminded me of something GSoC veterans seem to learn eventually: no matter how hard you work, no matter whatever efforts you put in, some of the outcome comes down to plain luck. Whether the organization gets picked at all, how many project slots it gets, who else applies for the same thing, none of that is in your control. So as a backup, I looked at two other organizations, Project Mesa and SymPy. Mesa I only ever read about, never actually contributed to. SymPy I took further, after a senior named Rushabh Mehta, who’d contributed there the year before, sent me his blog and pointed me toward good first issues. Between December and January, a couple of my SymPy pull requests got accepted, including one merged by a maintainer named Oscar Benjamin, which felt great at the time. But my Python was never that strong, later pull requests there stalled, and every time someone made progress on the Octave issues, I’d get anxious about it, even though it had nothing to do with SymPy. Splitting my attention like that had its own quiet cost.
By January, once real discussion had started around the LinearModel issue, I had the “should I keep a backup or go all in” conversation with Swayam again. His advice was simple: focus on whatever your heart is actually in, but accept beforehand that luck plays a real part in the outcome, so you don’t get to be bitter about it later if you chose to ignore that now. He still suggested keeping something as a cushion. Rushabh, separately, told me plenty of people couldn’t move as fast as I had even with AI helping them, and encouraged me to look for more issues in SymPy. I told him it was staying my backup, since I already had over a dozen pull requests merged in Octave and my roots there were much deeper. After that second talk with Swayam, I stopped checking SymPy altogether and made peace with letting things play out however they would.
By late January, only 3 people were really active in that part of Octave, me and two others I’ll just call Person A and Person B. Person B was quietly working toward a proposal for the anova project. Person A had been pointed by Andreas toward a specific piece of the LinearModel project, a parser that would let the fitting function accept formula strings as input. Within a couple of days, Person A came up with a pull request for it that was clearly AI generated, thin on robustness, with an AI sounding description, and worse, AI sounding replies to review comments. Andreas asked for real changes and better testing and got more of the same. That’s probably the point where his patience ran out. He’s building something that has to be provably correct against MATLAB, and “mostly works” doesn’t survive contact with statistics. Using AI wasn’t really the problem. Using it and not taking responsibility for what it produced was.
Watching that unfold, I decided to just build that parser myself, properly. I spent 2 full days reading the MATLAB documentation and the original research paper (Symbolic Description of Factorial Models for Analysis of Variance) the whole formula notation comes from, the first time I’d ever read a research paper and tried to turn it directly into working code. Then I spent 3 more days implementing the whole thing, something over 1,500 lines, all working, with a few more rounds of changes after that. Andreas accepted it and it went into production. It gave me real footing on the LinearModel project, and it turned out to also be useful ground for the anova project too, since the two overlapped more than expected.
By then, the distractions I’d cut out earlier that previous year were long gone, replaced by a different kind of tunnel vision. I had also completely stepped away from social media for that period. I deactivated everything and was so disconnected from it that I genuinely had no idea what event or fest was happening in college, or even when something was coming up. I skipped almost every campus event that year because I was hooked on reading MATLAB docs and hunting bugs, and on nights I wasn’t doing that, I was just reading through other people’s function implementations for fun. At the time I told myself it would all be worth it if I got selected. Looking back, I think I could have found a better balance, instead of treating every hour spent socializing as a threat to the goal. What’s done is done, and in exchange I got a lot of quiet, focused time, just me, Octave, and MATLAB docs. Meanwhile people around me made different choices with their time. Some went deep into other hackathons, some picked up new skills, some just rested. No judgment on any of that. We were all just betting differently.
Before any of the proposal writing could matter, Octave itself had to be selected as a GSoC organization, which is never guaranteed even if it’s shown up for years before. That announcement came on 19th February, at 11:30 PM, and I was genuinely anxious watching it. Octave got selected. One hurdle cleared, and right behind it came the next one, because getting the org accepted isn’t the same as getting a project slot. Apply for something low on the org’s priority list with only 2 slots open, and you can do everything right and still miss it.
I kept contributing and kept reading. Around that time I also took on a leadership role for a batch of juniors in a college coding community, running workshops and events through March, and April, on top of everything else. Basically, my solution to having any free time at all was to fill it with more responsibility rather than risk it turning back into distraction. As February wrapped up, the proposal window opened, from 16th to 31st March. Right as I was starting to draft, Andreas set up a private group with the three of us and scheduled a call. That was the first time I actually spoke to him directly. We did introductions, talked about who was working on what, and it was less like an interview and more like a briefing meant to keep us from stepping on each other. He told Person A plainly not to lean on AI blindly, which, in the end, didn’t fully stick. I asked what he wanted to see in the proposals. By then I felt fairly confident about my own standing, since I’d been the most consistently active of the three.
I turned 2 months of research into 3 actual proposals, one for anova, one for LinearModel, and a backup project I hadn’t researched as deeply, all sent to the same org and mentor in that order of priority. The first two were genuinely thorough, covering what Octave was, what already existed, what the actual gap was, how I planned to close it, what the final product would look like, what difficulties I expected, and what I’d already contributed. The third was more of a placeholder. All of this happened while I was also running event logistics for an entire batch of juniors, which made for a pretty stretched few weeks. My activity on the Octave forum kept quietly building the whole time too, climbing trust levels and eventually earning a badge for showing up more than 100 days in a row. Small things on paper, but they added up to an honest record of just not stopping. On 31st March, I submitted everything and it was finally out of my hands.
April became a long stretch of trying not to think about it too much, waiting for results due at the end of the month. I stepped back from Octave a bit, focused on college events, kept half an eye on the forum, shipped a few more small pull requests, while Person A kept posting AI generated code on the LinearModel issue, which Andreas mostly stopped engaging with. On 2nd April I asked if I should be looking at anything project related, and he told me to wait for the official announcement since slot numbers weren’t public yet, though off the record he mentioned I’d probably get the LinearModel project and to treat that as unofficial until it was confirmed. I was thrilled but stayed nervous the rest of the month anyway. I deliberately kept a bit of doubt in the back of my mind, thinking that if I didn’t let myself hope too much, it would hurt less if it went wrong. Swayam stayed a constant through all of it, listening whenever I needed to talk, giving advice I sometimes followed and sometimes didn’t.
On the evening of 29th April, Swayam called to say the results had technically leaked. There’s a known quirk with the GSoC website where, if you check your profile through your browser’s developer tools before the public announcement, a flag in the response would already show whether you’d been selected and for which org. Seniors who’d been through it before all knew this trick. We got on a call, I shared my screen, and there it was, a contributor flag set to true and the org listed as GNU Octave. Friends who’d also applied checked theirs and found nothing there, a quiet confirmation either way, a full day before it became official. Every senior who knew congratulated me after that.
The next day was still nerve wracking regardless. I sat in front of my laptop from 10:30 PM that night, on a call with a classmate, both of us just waiting. At 11:30 PM I opened the results page, refreshed my profile, and there it was properly this time. LinearModel and CompactLinearModel, with Andreas Bertsatos (from the University of Athens, Greece) and Colin B. MacDonald (from the University of Oxford, currently at the University of British Columbia) as mentors. My friend started screaming. Within minutes every group chat I was in turned into a wall of congratulations. I didn’t sleep that night, even with exams 5 days away, because I was already thinking ahead about how I’d approach the project.
To be fair, not everyone’s story ended the same way that week. A classmate from the same department also got selected that cycle under a different program, which was nice to see. But a few friends who’d worked just as hard didn’t get in, and that was genuinely hard to watch, since effort and outcome don’t always match up. My honest take on the whole process, having gone through it, is that you’re better off going in contribution first rather than proposal first. In a purely proposal driven track, if someone stronger on paper applies for the same slot, your months of prior work can matter less than you’d hope, and luck plays a bigger role. In a contribution driven track, consistency builds up steadily over time, which is a much safer bet than one well written document.
Two projects came out of Octave that cycle. Person B got the anova project, based on a single proposal in that lane. I’d submitted for 3 projects and was given LinearModel, my second choice on the list, and I was completely happy about it, because the actual work mattered more to me than where it ranked on a form. LinearModel meant building an entire linear regression framework from scratch, matched as closely as possible to MATLAB’s behavior. Two classes, LinearModel as the full framework and CompactLinearModel as a lighter version for once a model was already fit, plus a stepwiselm function for automated model selection on top. By the numbers, at the end of it, LinearModel came out to roughly 9,850 lines, CompactLinearModel a bit over 3,320, stepwiselm close to 2,450, and fitlm over 700. Line counts don’t measure quality, only functionality, robustness, and test coverage do that, but the numbers give some sense of the scale involved.
Community bonding ran until 24th May, and honestly I barely touched the project during it. I told my mentors upfront that I had end semester exams, and Andreas, being pretty relaxed about it, was completely fine with that. My studying that stretch wasn’t fully focused either, if I’m honest, since a good chunk of it quietly went into figuring out how I’d actually approach the project once real work started. Before the period ended, Andreas asked both of us to submit a rough plan so progress could be tracked from the first week. I did, and so did Person B for anova.
Once the actual coding period began, a routine set in fast. Weekly meetings, mostly on Thursdays, with the anova meeting scheduled before mine since Andreas mentored both. Every week had its own goals, and every week ended with a blog post covering what I’d built. I never really felt pressure building up, because the updates stayed constant and visible the whole way through. The build order started with class properties and their documentation, then display methods, and then the real core of it, the math. The whole point of the class is that when someone fits a linear regression, they get back a proper object they can then work with through every other method. That structure came together slowly, meeting by meeting, method by method. I’d push code and a blog update before each sync, so there was always something concrete to react to, whether Andreas had already reviewed it or we worked through it live, with questions saved up either way. My second mentor, Colin, couldn’t join the earlier meeting slot because of the time difference, which got sorted out later.
Meanwhile, on the anova side, things weren’t moving the same way. Responses from that contributor were sparse, sometimes missing entirely, even on the shared group thread, and since it’s all open source, that silence was visible to everyone. The two projects shared some functionality, which made things a bit awkward, until I just implemented what I needed directly inside LinearModel instead of waiting on something that wasn’t coming reliably.
My own weeks stayed on track, with methods landing one after another, everything checked against MATLAB, test cases building up steadily, and questions saved for the weekly syncs rather than fired off constantly. By the time midterm evaluation came around, fitlm and the core LinearModel class were solid. Andreas’s requirement for midterm was simple, get things stable enough that he could release a new version of the statistics package including my work, since a release means it reaches every actual user right away instead of sitting on a branch. That genuinely excited me, the idea that someone could just update their package and start using something I’d built. The other contributor submitted their pull requests at the last possible moment after being asked days earlier, and somehow Andreas still managed to review, merge, and cut the release in time. Midterm ran from 6th to 10th July, and the day after it cleared, the first stipend came through, 45% of $3,000, landing in a Payoneer account before making it to my local account a couple of days later. Earned in my third year of college, off the back of a project that had started, less than a year earlier, with a random interpolation issue and some code testing.
Work continued after that. The whole of CompactLinearModel, the stepwiselm function, and a handful of remaining LinearModel methods were still left. Then college started back up, third year began, and the whole balance changed overnight. Full days on campus from 8 to 5:30, and then GSoC only started once I got home, usually running until 3 or 4 in the morning, the same pattern I’d half followed the year before, minus the excuse of not knowing better this time. I was also secretary of the club by then, so I had that to manage alongside GSoC, and the thing that kept quietly getting sacrificed was sleep. The weekly meeting shifted to 10:30 PM on Thursdays, which finally let Colin join consistently, and sometimes Thomas Kolman, the anova project’s second mentor, joined too, so the two projects would compare notes on the same call sometimes. Those late meetings turned out to be some of the most enjoyable parts of the whole project, with Colin asking sharp questions about the plotting methods especially, the kind that sent me back to double check things I’d been coasting on. On the anova side, the same pattern from midterm mostly continued, presence came and went, and at one point Andreas voiced his frustration about it openly on the main forum. There was one week I had a company interview and missed a sync, but I flagged it well in advance and there was no issue with that.
Through all of this, one thing kept proving itself true: if you really want to do something, you find the time for it. If you don’t, you find a reason not to. It applies to everything, not just GSoC. We shall give time to everything and everyone we are associated with, we shall be responsive, and we shall make sure that nothing we choose to be a part of gets ignored just because it becomes inconvenient. It doesn’t matter what the thing is. It held true for exams, it held true for the club, it held true for GSoC, and I expect it to hold true for whatever comes next too.
Final evaluation carried the same shape as midterm, more pull requests, another release cut around the same time, the same rhythm one more time. The real difficulties across the whole project were quieter than any dramatic version of this story would suggest. Learning to work around parts of Octave’s class system that are still actively being developed and won’t fully land until a future version. Learning, properly, how to deal with changes landing on the main branch while my own work was still in progress elsewhere, and the discipline of resolving that without losing weeks of work. That last one I learned the hard way, which tends to be the only way it actually sticks. Beyond the technical side, the whole project taught me a lot about designing something at a scale I’d never really attempted, about taking an idea straight out of a research paper and turning it into tested, working code, and about how the small decisions you make early on quietly decide how much trouble you inherit later.
What I keep coming back to, now that all of it is behind me, is that GSoC was never really the point, even though it was the whole point when this started. Somewhere along the way, working on this stopped feeling like an assignment and started feeling like just what I did, and for long stretches I genuinely forgot any of it was in service of a stipend or a line on a resume. I feel like part of that community now in a way that has almost nothing to do with the program that got me in the door in the first place, and I plan to keep contributing after this, exploring other packages and staying in touch with people I only met because I kept showing up. The stipend was real and I’m grateful for it, $3,000 earned on my own terms in my third year of college, but by the end it was never actually the thing I was chasing.
If there’s a moral in all of this, I think it’s a simple one. Show up consistently, long before anyone is watching or grading you for it. Build things because you actually want to understand how they work, not because you want to be seen wanting to understand them. I learned that good work is rarely about getting everything right the first time, but about being willing to learn from every review, every mistake, and every failure and come back better the next time. Let the recognition and the outcome arrange themselves around that, instead of chasing the outcome first and hoping the substance follows. It rarely works in that order. It worked in this one.
None of it would have gone the way it did without the people who supported me throughout this journey. A special thanks to Swayam Shah, who was there even before GSoC became a serious goal for me, constantly listening to my endless yapping about Octave, GSoC, proposals and everything in between, and giving me advice through all the uncertain phases. My friends deserve a huge thanks as well. They were there for me through some of the lowest and most difficult phases of this journey, kept motivating me when I needed it, and stayed around even when things weren’t going well. Their support, encouragement, and simply having people around who believed in me made a bigger difference than they probably realize.
And of course, a huge thanks to Andreas Bertsatos, who took a stranger’s rough, imperfect first pull request seriously enough to actually respond to it in full, and stayed patient through every basic question and every mistake I made along the way. More than just teaching me about Octave or statistics, his reviews taught me how to think about writing software properly: to care about robustness, testing, compatibility, documentation, and the small details that make code actually usable. That kind of patience isn’t a given in open source, and it made a real difference in how this whole year turned out. I’m genuinely grateful to everyone who made this journey what it was.