How I Got Into Google Summer of Code 2026 with SciML

When I started college I was a web developer. React, REST APIs, the usual. I had never touched scientific computing, and I definitely had never written Julia. A year later I'm a Google Summer of Code 2026 contributor with NumFOCUS — SciML, working on the numerical solvers that power differential-equation modeling across science and engineering.

This is how that happened.

Finding the project

I wanted to contribute somewhere that was both technically deep and welcoming to newcomers. SciML kept coming up. The ecosystem — OrdinaryDiffEq.jl, ModelingToolkit.jl, DifferentialEquations.jl — is enormous, but the maintainers genuinely review first-time PRs and leave good-first-issue labels.

My first contributions

I didn't start with anything glamorous. I started by reading failing CI logs.

• I picked up a bug in the Magnus integrators and traced it down to a convergence issue.
• I dug into convergence-order tests that were quietly flaky.
• I implemented small solver enhancements and learned how the stepping interface fits together.

# The kind of thing I was staring at for hours
prob = ODEProblem(f, u0, tspan, p)
sol = solve(prob, MagnusGL6(), dt=1e-2)
@test sol.errors[:final] < 1e-6

The lesson: you don't need to understand the whole codebase to be useful. You need to make one test go from red to green.

Benchmarking and DAE work

After the solver fixes I moved into SciMLBenchmarks.jl, contributing a DAE benchmark suite using ModelingToolkit.jl. Benchmarks are an underrated way to contribute — they force you to understand the performance characteristics of the code, not just the correctness.

What I'd tell my past self

1. Read CI before you read code. Failing tests are a map.
2. Ask narrow questions. "Why does this test expect order 6?" beats "how does this work?"
3. Show up consistently. Maintainers remember the person who keeps coming back.

GSoC wasn't a lottery ticket. It was the natural next step after months of small, real contributions.