GSoC 2026: a Hopeful Rejection

TL;DR

I was rejected for GSoC 2026 after months of preparation. The disappointment was tough, but the entire experience integrated me into open-source culture. My prep work involved building a deep understanding of routing engine mechanics and systems engineering principles, giving me the necessary foundation to start my own FOSS project, Pico Router.

Helpful Definition

"Google Summer of Code is a global, online program focused on bringing new contributors into open source software development. GSoC Contributors work with an open source organization on a 12+ week programming project under the guidance of mentors." — summerofcode.withgoogle.com

How It Started

In late 2025, I happened to discover Google Summer of Code while watching a Green Code video. It caught my eye due to its "meritocratic" appeal (very attractive for any self-taught engineer), and let's be honest, the fact that it was backed by Google also had something to do with it :-). Being in the midst of my work on Focal Grid and just being introduced to the world of GIS technology, I looked through the org list to find a project that could fit me. I ended up landing on OpenStreetMap thanks to the sheer variety of prominent GIS projects they maintain. I checked the proposed projects page on the official wiki only to find out there was just one project up for grabs at the time. Remembering that "the early bird gets the worm," I scanned the repo and contacted the mentor to share my interest in the project.

The Prep Phase

My preparations kicked off by exploring target repo (closure.osm.ch) more thoroughly. In short, the project consists of a monorepo including a Next.js frontend and a FastAPI backend. As expected, the frontend handles the web UI while the Python backend handles most of the business logic. The main goal of closure.osm.ch is to expose a new routing API that community-sources and aggregates public closure data. At the time, it only featured a landing page plus a "closure-aware" routing demo. With the main mentor stated goal being integration with one or more dynamic routing engines, I took a look at what engine was currently being used for the demo. It turned out to be Valhalla, making my very next step exploring and understanding that repository in order to propose an optimal integration.

Valhalla, being an enormous decade-plus C++ codebase, was especially challenging to wrap my head around. It was designed with strict OOP principles in mind, which on one hand made it easier for me to focus on studying individual aspects of the system, while on the other hand the countless levels of abstraction and polymorphism made my head spin. Luckily for me, the core maintainer team numbers only four people, making discussions with far-reaching system consequences much easier. I have to give a big thanks to this very team for not only hearing out my (at times naive) ideas but also those of all the other participants equally, without a show of favoritism.

I'd like to mention that open-source software took a bit of adjusting for me. It was quite intimidating, and I was self-conscious about not fitting in and seeming too much like a clueless noob (maybe something worth delving into in another blog post). In fact, this very feeling of fear made me delve into documentation for hours, scour subreddits, and quintuple-check every message and contribution before sending.

Pre-submission Contributions

As clearly stated by the GSoC and OSM guidelines, contributions to the projects one applies to are obligatory for consideration. Knowing this, I set out to deliver my first-ever PRs to both closures.osm.ch and Valhalla.

To summarize, my main merged PR for Valhalla added version logging during the startup of the official Docker image. Besides that, I spent some time helping with issue triage and technical discussions surrounding vector tiles and the live traffic subsystem.

On the closures.osm.ch side, I fixed Docker compatibility issues, integrated vitest together with an initial unit test suite, improved backend build reliability, and reported a handful of architectural issues I encountered while studying the codebase.

Lastly, I wanted to experience the OpenStreetMap ecosystem from the perspective of a data contributor as well. To that end, I made a handful of map edits around both Barcelona and Nijmegen, getting familiar with the editing workflow and the review process along the way.

If you're interested in seeing a compilation of all my contributions, feel free to check out my full GSoC proposal below.

Summary of the Proposal

I'll try to keep the breakdown of the proposal short, as you can view the entire submitted document below.

In a nutshell, I identified a handful of problems with the current closure-aware routing approach that were keeping it from being production-ready. Supposedly due to its "demo" nature, I encountered a few spots with a very unclear separation of concerns. Firstly, the entire routing logic was located in the Next.js frontend, defeating the purpose of the REST API as the project's focal point. It basically just sent a routing request to a remote Valhalla instance with the exclude_locations parameter filled with closures fetched from the accompanying PostGIS database. exclude_locations is limited to 50 location points max, which is way too little for any serious trip, and uses closest-point map matching, leading to unreliable routing accuracy. Moreover, the OpenLR module was built from scratch but was not compliant with the actual open standard.

The main considerations for the solution were to have a system that could provide native-like integration with routing engines while staying engine-agnostic, adding as little runtime overhead as possible, and integrating seamlessly with the existing closures.osm.ch infrastructure.

The solution I came up with was the addition of a new sidecar service called Closure Sync. Its design is best illustrated by the diagram below:

As you can see, Closure Sync represents an independent service that is meant to be placed in the same host environment as the routing engine. It utilizes a Live Traffic overlay provided by many routing engines, which offers an API to change edge costs dynamically at runtime. In essence, the service polls a remote closures.osm.ch instance every couple of minutes to fetch live data and transforms the fetched data into a readable traffic overlay format, where all closed edges are assigned an infinite cost, effectively closing them.

I planned to initially write Closure Sync in Python to comply with a realistic milestone-based schedule. However, after a successful PoC, the service would ideally be rewritten in a compiled language to increase native performance and ship as a single binary.

Moving On

As suggested by the title of this post, my proposal was unfortunately rejected. It really wasn't the rejection itself that disappointed me, but rather some of the details surrounding it. Prior to submitting my proposal, I had publicly asked for some feedback in the Valhalla discussion on GitHub. I shortly afterward found out that asking for feedback like that is not really in accordance with the "GSoC mentality," but the maintainers were still patient with me and engaged thoroughly. The point is that a couple of days after the conclusion of the discussion (still a few days before the deadline), another GSoC-aspiring commenter joined, name-dropping the mentor and thanking them because some of his doubts had been answered. Thinking little of it, I moved on with my preparations.

After getting rejected, I naturally wanted to know what the winning picks were. To my surprise, I found the same commenter presenting a rework of closures.osm.ch that included a "sidecar service called Closure Sync." This is not meant as an exposé of this particular participant. I publicly shared my idea, so it's only natural that he used it in his own preparation, and I did not see his project, so it is not my place to judge it. It did, however, make the rejection sting more. On top of that, I was slightly put off by the follow-up contact with the mentor when asking for feedback and clarity surrounding the situation.

That being said, I in no way regret the time I put in. I knew from the start that the majority of proposals never see the light of day. In exploring Valhalla, I've developed a deep appreciation for routing technology, and I'm determined to grow my status as a trusted contributor to the project (more contributions in works). Moreover, I learned from scratch what it means to create open-source software. It deeply resonated with my principles, and I'm looking forward to finding more cool projects to help out on.

While working on the GSoC proposal, I also deepened my knowledge of embedded systems, leaving me with an itch to do more impactful work on a real project. In essence, that's where the idea for Pico Router was born. Having gained the fundamental knowledge of how one of the most powerful and impactful routing engines works on the inside, I started looking for MCU-compatible alternatives. Sadly (or luckily), no one has yet tried to take on the challenge in a FOSS format, clearing the way for this new adventure!