On Monday 19 May 2025 I went to DevOops #8, the eighth edition of the DevOops Amsterdam meetup, this time run together with the Amsterdam.dev community. According to the event listing on Luma it was presented by Fiberplane and hosted by Datadog at its Amsterdam office. The program slide read: doors at 18:00, food and drinks at 18:30, welcome at 19:00, two talks with a break between them, then conversations and lightning talks until 21:30.
This is a throwback post. I took the photos and recorded part of the talks, and what follows comes from the slides, the recordings and the event page. I name only the two speakers listed on the program slide.
The room before the welcome, with the DevOops #8 slide on the screen.
The welcome
The hosts opened by noting that the DevOops series was close to its third anniversary, and thanked Datadog for hosting. A Datadog representative then gave a one-minute pitch: an observability platform that also covers security and cloud cost management, centralising metrics, traces and logs for engineers, SREs and platform teams. It was the second time the company hosted DevOops, they said.
A presenter from the organising side followed with a short introduction. The pitch was that they had become a playground for Cloudflare’s developer platform, with a JavaScript API framework and a debugging playground for AI agents built with the Cloudflare SDKs. The Amsterdam.dev organiser then introduced the community: a jobs site for Amsterdam-based tech companies plus a monthly meetup, always looking for speakers and hosts. The upcoming dates they mentioned were DevOpsDays Amsterdam on 18 to 20 June, Kubernetes Community Days Utrecht on 3 July, and Open Source Summit Europe in Amsterdam.
The program slide, cropped to the schedule.
Building developer experience through open source programs and policies
The first talk was by Ayodeji Ogundare, developer advocate at Adyen, who leads the OSPO (Open Source Program Office) initiative there, according to his own intro slide. The talk’s argument, as I followed it:
- Developer experience in open source is the level of friction you meet when you use or contribute to a project: clear flow, clear documentation and a clear policy, versus guessing how, where and when to contribute. Bad experience costs time, talent and trust, and leads to duplicated work and blocked contributions.
- A war story. He described spending hours on a pull request, only to learn that the file was generated and that a manual change would be overwritten by the next automation run. A contribution guide would have saved him that.
- InnerSource is open source culture inside the company: the same practices, with code that is not public. His slide put it as “better DX starts inside, charity begins at home”. Every developer should be able to read and contribute to code outside their own team.
- External DX reflects internal habits. A maintainer who takes two years to answer a pull request, which he said had happened to him, tells you something about the team behind the project.
- The role of an OSPO: define and execute the open source strategy, enable effective participation and contribution, and ensure compliance while fostering an open culture. The benefits on the slide were faster onboarding, easier open source adoption, safer contribution pathways and fewer legal and process delays.
- How to start: the closing slides said to start small and fix one friction point. Engineering leads should make open source participation part of the job and clarify what is allowed, which projects and how many hours. Maintainers should keep contribution docs current, respond quickly or delegate well, and track their engagement.
- Where to read more: the final resource slide pointed to the github/github-ospo repository, the TODO Group and the Linux Foundation’s open source management training course.
I only have the first part of this talk as clean audio, so I am relying on the slides for the second half.
My take: the OSPO conversation matters most for companies that consume far more open source than they contribute. A one-page policy that says who may contribute, on which projects and during which hours removes most of the friction he described, and it costs almost nothing to write.
A story about a licence
In a short recording from around the break, a speaker I could not identify, most likely in the discussion after the first talk, told a story about a library that carried a small variation of the MIT licence with an added clause that the software must be used for good, not evil. The speaker’s company could not guarantee how its users would use the software, so after long discussions with lawyers they removed the library. It is a good reminder to read the licence text, not just its name.
Chat with your codebase with Candle and Tree-sitter
The second talk was by Pratim Bhosale, senior developer advocate at Treblle by her own introduction (the program slide lists her as Pratim Bhosale of Treblle). She opened with a slide citing a Y Combinator video, that 25% of the startups in the 2025 batch have 95% of their code written by AI, and then asked what really happens when you type a question such as “How does re-ranking work in this code?” into an AI IDE chat.
To find out, she built a command line tool in Rust that imitates the flow. In the demo it loaded an index of a repository, answered the question while streaming the reply from GPT-4o mini, and showed which file and chunk each part of the answer came from. She said it is open source, but a demo project she would not recommend others to start using.
Why she chose Rust: a single portable binary, lower memory use and better CPU use. The slide notes that OpenAI uses Rust for its Codex CLI.
The building blocks she walked through (I followed the first four on the slides; the recording of this talk is partial):
- Parsing with Tree-sitter. Instead of splitting files by line count, a parser turns the code into an AST, which she described as a family tree with the whole codebase as the root and a semicolon as the smallest branch. Tree-sitter has grammars for many languages, so chunks follow functions and structs rather than arbitrary lines.
- Embeddings. Each chunk is converted into a vector of numbers by an embedding model, which is what lets a search for “apple” return pictures of apples without the computer understanding apples. She used a grocery website’s poor search as the running joke.
- A vector index that is loaded from disk and searched by similarity, with Rust libraries such as Candle, Hugging Face’s Rust machine learning framework, doing the model work.
- HyDE (Hypothetical Document Embedding). Before the chunks go to the LLM, the tool asks the model to write a fake answer document and searches with that, because an imagined answer is often closer in embedding space to the real code than the raw question is. She was careful to say the fake document is not the right answer.
The last slide invited the audience to try the Tree-sitter playground on the project’s website, which was also where the live demo slide pointed.
My take: this is the retrieval side of every AI coding assistant, and it is worth building once to see why they sometimes miss context. Syntax-aware chunking explains a lot of the difference between an assistant that finds the right function and one that returns a random slice of a file.
What I took from the evening
Both talks were about the same thing from different ends: who the tooling is for and how much friction it hides. An OSPO removes the friction between a company and the open source it depends on. A code search tool removes the friction between a developer and a codebase they have not read yet.
