Open Source Working Group Minutes RIPE 91
Wednesday, 22 October 2025, 09:00–10:30 (UTC+3)
Chairs: Marcos Sanz, Marco d’Itri, Sasha Romijn
Scribe: Alun Davies
Status: Draft
View the stenography transcript
A. Administrative Matters
Marcos Sanz (WG Co-chair)
Marcos opened the Open Source WG with a welcome and housekeeping - Meetecho and stream info, a reminder of the Code of Conduct, a reminder to please rate the talks - before handing over to the first speaker.
B. Scope Creep in Open Source
Ondrej Zajíček (CZ.NIC | BIRD)
Ondřej unpacked how open-source projects drift beyond their remit—through user pressure, dependencies, and horizontal/vertical feature creep—and weighed when that integration improves consistency versus dilutes focus. Using BIRD as a case study (e.g., EVPN), he showed the trade-off in practice: verify external interface setup rather than turn the daemon into a full system configurator, keeping the core lean while avoiding “can of worms” scope.
Ondřej Surý (ISC) backed the thesis but pressed on two pragmatics: who maintains new features, and how BIRD will keep interfaces stable as it evolves. He asked what concrete path the project will take and whether they could report back in a few years. Ondřej Zajíček said they’re exploring YANG-modeled APIs with code generation to reduce maintenance burden and enforce consistency, alongside versioned interfaces where clients can request a specific API version (NETCONF-style).
Marcos Sanz asked whether any BIRD components were so loosely coupled that they should be spun out into separate projects. Ondřej said they’re considering splitting the CLI/URI layer into its own package that would talk to BIRD via an API—an aspirational idea rather than a concrete plan.
There were no further questions.
C. When to actually rewrite it in Rust?
Annika Hannig (Alice BGP Looking Glass)
Annika walked through a three-year rewrite of Birdwatcher in Rust aimed at fixing hard-to-tune GC/memory issues and gain stronger typing, safer concurrency, and clearer state-machine parsing. Keeping scope tight (single-table first, fewer regex, direct BIRD socket I/O), the new implementation proved faster and more maintainable, with multi-table support now close to complete and early testing under way.
Gordon Gidófalvy (Nokia) asked about the community impact of a Rust rewrite - whether the language’s steep learning curve could shrink the pool of contributors. Annika acknowledged the barrier (including sometimes-opaque error messages) but said it’s manageable; once contributors get past the initial hump, Rust’s type system and compiler checks let people contribute with greater confidence, especially with unit tests.
Ondřej Sury (ISC) asked whether Annika now had a clear answer to “when to rewrite it in Rust” and if the rewrite was worth it. Annika said yes - for her it delivered learning plus performance/memory benefits - but the broader rule is project-dependent, and contributions over time will be the real test. Ondřej summed it up: there’s no universal rule; rewrite when it makes sense.
Marco d’Itri (Seeweb | DHH) noted that there are some real problems he's encountered with Rust. Rust crates often pin to specific, unstable APIs, forcing multiple versions of the same library and making distro maintenance (e.g., Debian security) painful. Annika agreed—dependency/version churn is a real drawback in today’s Rust ecosystem, and better tooling/policies are needed.
There were no further questions.
D. Streamlining the release process from the git
Ondřej Surý (ISC)
Ondřej Surý described how ISC made releases “boring”: keep main always releasable, branch at checkpoints, and auto-generate user-facing release notes from merge-request descriptions (via git-changelog), backed by danger checks, linters, and SPDX. He also covered the messy bits—multiple release trains, private security fixes, and coordinated releases—and argued for pushing more automation so a release is essentially a one-click operation.
Ondřej Zajíček (CZ.NIC | BIRD) asked about branch strategy - whether to rebase and keep a single final patch per release branch, or move development to a “next” branch and use main for releases. The speaker responded that ISC keeps main for development plus per-train release branches; when a MR lands on main, a job auto-backports it to the relevant release branches (with manual fixes if refactors cause conflicts).
Annika asked about the recommendation to employ code from matting tools - for example Go FMT or Rust FMT - noting that she personally likes them a lot. She added that she had found Black harmful to readability in otherwise PEP 8–compliant, linted Python code, and asked when Ondrej considered a formatter preferable to relying on linters or other tools. Ondřej responded that ISC treats formatters as “use when it makes sense” to offload style decisions and keep consistency. Python is mostly for tests, while C code ships a .clang-format so contributors don’t fight styles—and he acknowledged the Python/Black trade-offs, wishing the ecosystem had converged on one style from the start.
Shane Kerr (IBM) asked if ISC now does any real-world, pre-release production trials, recalling past ad-hoc F-root tests that weren’t structured or useful. Ondřej said the resolver is where “the dragons are”: some developers run it on their home networks, and a few trusted customers provide early feedback on security fixes (cores/traces), which helps a lot. Rather than alpha/beta stages, ISC moved to a faster monthly release cadence so bugs surface quickly, fixes ship sooner, and pressure to cram features into a big release is reduced.
Gert Doering (SpaceNet AG) noted that even with strict CI—building across platforms and running extensive client/server tests—real users still hit breakage because the feature set and option combinations are too large to exhaustively cover. Ondřej acknowledged the challenge and invited a follow-up, mentioning ISC’s broader automation (e.g., option fuzzing/property tests and Hypothesis-style case generation). They agreed to continue the discussion offline.
There were no further questions.
E. AOB
Marcos Sanz
Marcos closed the session, thanking everyone for joining, and noting that he looked forward to seeing everyone in Edinburgh for RIPE 92 or on the mailing list.