Contribution to Google DeepMind's OpenSpiel

01 Context

OpenSpiel is a framework for research in reinforcement learning and game theory, maintained by Google DeepMind. It provides implementations of games and algorithms used in multi-agent RL research — the kind of infrastructure that underpins work on AlphaGo-style game-playing systems and mechanism design experiments.

The framework is primarily Python-facing but has significant C++ at its core — game implementations, solvers, and performance-critical algorithm components. Python users interact with the C++ layer through compiled extension modules.

02 Problem

OpenSpiel's CI/CD pipeline didn't produce Windows wheels. Windows users had to build from source, which requires a working C++ build environment and correct CMake configuration — a significant barrier that excluded a meaningful portion of the research community.

The existing build system predated PEP 517 (the standard that defines how Python build backends should work) and didn't use cibuildwheel — the de-facto standard for building Python wheels across platforms and Python versions. Adding Windows support meant touching the build configuration at multiple layers: the CI pipeline, the Python packaging configuration, and the C++ build flags that needed to be Windows-compatible.

03 Approach

The interesting part wasn't the code — it was reading the existing build system closely enough to understand the abstraction boundary DeepMind had drawn between the C++ game logic and the Python packaging layer. That boundary isn't always where you expect it.

I migrated the build configuration to use cibuildwheel with a pyproject.toml-based setup (PEP 517 compliant). This replaced a series of ad-hoc shell scripts and custom CMake invocations with a standardized pipeline that handles Python version matrix, platform-specific compilation flags, and wheel signing automatically.

The Windows-specific work involved reconciling CMake flags that worked on Linux/macOS but produced warnings or errors under MSVC, and ensuring the C++ extension ABI was stable across the Windows Python versions that OpenSpiel supports.

04 Result

PR #1426 was merged. OpenSpiel's CI pipeline now produces Windows wheels on each release, installable via pip without a local C++ build environment.

The secondary outcome was that the modernized build pipeline made the matrix of supported Python versions and platforms explicit in configuration rather than implicit in documentation. Adding a new Python version to the support matrix is now a one-line change in pyproject.toml.

05 Retrospective

Build system work is the kind of contribution that's easy to undervalue because it's invisible when it works. The right metric isn't the lines changed — it's the number of researchers who can now install the library on Windows without filing a support issue.

What I learned: reading a large C++ project's build configuration is a useful way to understand its architecture. The build graph reveals dependencies that don't show up in the code — which components are truly independent, which are coupled through linking, and where the interface between the C++ and Python layers actually lives.

The PR review process with DeepMind engineers was the most educational part. The feedback was specific to the CMake configuration — flags I'd set conservatively that could be tightened — and to the CI matrix, which I'd initially scoped too broadly. That kind of targeted review is rare in open source and worth more than most code comments.