DEV Community: Sangkyoon Nam

There Are Votes in Open Source Too

Sangkyoon Nam — Thu, 29 Oct 2026 15:05:00 +0000

I started taking part in open source seriously in the second half of this year. It hasn’t been long, but I knew which areas I cared about, so I read a lot of issues and sent a fair number of PRs. Then in October I got an email inviting me to vote in the OpenTelemetry Governance Committee election. That was when I learned that an open source project, which is neither a company nor a country, holds elections, and that I had a vote even though I had only just started, because I had kept showing up.

The invitation I got on October 22. It calls on people who made more than 20 contributions on GitHub in the past year, counting comments, code reviews and PRs.

Once I looked, open source turned out to have far more votes than I expected, and in that one month I encountered three kinds: a vote on a new committer, a vote on whether to ship a release, and an election for the people who run the project. I only saw the committer vote through its result announcement. I cast a ballot in the other two, and the Governance Committee election was the first time I had voted in one.

#The vote that makes a committer

In Apache Software Foundation projects such as Flink, a committer is someone with the right to merge code directly, and who becomes one is also decided by vote. That vote happens out of sight, though. Under the Flink bylaws, the Project Management Committee (PMC) votes on a private mailing list for at least three days. It passes with three or more yes votes from active PMC members and no justified objection from any of them. One such objection is enough to act as a veto.

From the outside, all you see is the result. On October 21 an [ANNOUNCE] email about a new committer arrived on the Flink dev mailing list, and people replied with congratulations one after another. I looked at how the earlier replies were written and sent a short one with my name.

The new committer announcement on October 21 and the congratulations I sent early the next morning.

#The vote that ships a release

The vote on whether to ship a release happens in the open. The release manager uploads a release candidate, the build to be checked before the official release, and sends an email whose subject starts with [VOTE] to the dev mailing list. People download the candidate, check it themselves and reply with +1 or -1. The Flink bylaws keep the vote open for at least three days, and only the votes of active PMC members count toward the result. These are called binding votes. A release passes with at least three binding yes votes and more binding yes than binding no, and others can also vote and report what they verified.

On October 21, while checking things ahead of the Flink Agents 0.4 release, I found and fixed a bug where Java chat calls failed in the build made with JDK 17. On the 27th I checked the signatures and checksums of the first release candidate, compared the source against the tag and built it myself, and I also checked whether the classes my fix needed were in the release files. Then on the 28th I found that the vote email itself had landed in my spam folder.

In my reply I gave a +1 marked as non-binding, meaning it doesn’t count toward the result, listed what I had checked, and said I had not run an end-to-end functional test. I had also found a case where the state of in-flight work was not restored when upgrading from the previous version, but since the problem was not new in this release, I did not raise it as a blocker. I suggested adding a line to the upgrade notes and said I would try to fix it in the next version.

The vote passed with no objections. The result email listed seven yes votes, four of them binding, and my name was on the non-binding side.

The result email for the first Flink Agents 0.4.0 release candidate, received on October 29.

#The vote that picks the Governance Committee

OpenTelemetry’s Governance Committee reviews proposals for new projects, sets priorities and maintains the public roadmap, and the vote for its members was the most election-like of the three. I hadn’t applied for voting rights, either. Anyone with 20 or more contributions to the OpenTelemetry GitHub organization in the past year, counting PRs, issues and comments, gets one. Approvers, who review and approve contributions in their area, and maintainers, who set the technical direction of subprojects, also get a vote. The list is generated automatically, and contributors who fall short can ask for an exception.

The public voter list as of October 21 had 837 accounts, and my username was on it. The count next to it said 29 contributions.

All ten candidates nominated themselves. Self-nomination alone was not enough: each needed endorsement comments from voters at two other companies, and a cap keeps people from one company from filling the committee. During the election, one candidate even messaged me directly to ask what I thought.

Voting ran on an online system called Helios from 9 p.m. on October 26 to 8:59 p.m. on October 29, Korea time.

We could pick up to four candidates for four seats, and by a few hours before the deadline I had read all ten platforms. I had expected governance to mean rules and votes, but the platforms ranged much wider, from install packages and the demo app to moderation policy, events and relations with neighboring projects.

AI stood out first. By my count, six of the ten candidates mentioned AI or agents in their bios or platforms, and by my reading five promised to protect maintainers’ time. Several platforms promised to help end users adopt OpenTelemetry, and a candidate who works at the American Red Cross wrote that OpenTelemetry is a core part of the blood services that supply roughly 40% of the US blood supply.

What stayed with me longest was what the candidates said about code review. One candidate wrote that monthly PRs in the group they lead nearly quadrupled this summer and review could not keep up, and another, who put maintainer burnout on the first line, proposed cutting repetitive work with shared tools and automated checks.

#After the vote

The official results for the OpenTelemetry Governance Committee election went up on October 29 in the US, and I saw them on the morning of the 30th, Korea time. 41% of eligible voters cast a ballot, and the top four vote-getters won new terms. That doesn’t mean seats simply go in order of votes. The charter allows at most two committee members from the same company at any time, and the cap counts members whose terms are still running. A candidate over the cap is skipped even with more votes, and the next candidate in line takes the seat. This time the top four came from four different companies, and none of those companies matched the companies of members whose terms run through 2027, so the seats went straight by vote count.

Whoever won, the review problem in those platforms is something many open source projects share right now. A post on the Kubernetes blog in June made the same point: AI has made generating code fast, but there has been very little improvement in maintaining code bases. In OpenTelemetry, one candidate wrote that review can’t keep pace with the growth in PRs, and the project’s generative AI policy calls maintainer and approver time a very scarce resource. The policy doesn’t ban AI. It says AI can be a useful tool for writing code, docs and tests when used well, and asks contributors to share their own thinking, even in imperfect English, rather than just passing along what a model generated.

I use AI to contribute too. It makes writing issues in English and reading large, unfamiliar codebases much easier. When I open a PR, I write in the description what I actually ran and what I couldn’t verify, and splitting my release vote reply into what I checked and what I didn’t came from the same habit. Reading the platforms made me think this habit matters even more in open source. At a company you share context with your reviewers and can ask the person next to you, but an open source reviewer gives their own time to read a PR from someone they’ve never met. So the code and the PR description have to explain the intent of the change on their own, and they have to be written for the reviewer from the start.

#References

Flink Bylaws: Defines who votes, for how long and what it takes to pass, for release votes and committer votes.
2026 OpenTelemetry Governance Committee candidates: Collects the bios and platforms the ten candidates wrote themselves.
OpenTelemetry governance charter: Defines the committee’s role, voter eligibility, endorsement requirements for candidates and the per-company cap.
Open source maintainership in the age of AI: Describes how the Kubernetes community has changed its policies and review practices as AI-driven contributions grew.
OpenTelemetry generative AI contribution policy: Sets out maintainer discretion and contributor responsibility for contributions made with AI.

I write about building and leading large-scale platforms, from ads and CRM to AI agents, at Namsang Labs Tech Blog.

ObservabilityCON 2026 Keynote, Grafana Has Started Opening PRs

Sangkyoon Nam — Tue, 20 Oct 2026 15:05:00 +0000

1:15 into the keynote recording. Source: Grafana on YouTube

The company best known for dashboards spent an hour barely talking about dashboards. That’s my takeaway from watching the recording of the ObservabilityCON 2026 keynote, held October 20 at Pier 27 in San Francisco. What held my attention was the demo where an agent investigates an incident and opens a fix PR, and the fact that the instrumentation Grafana builds itself is now built inside OpenTelemetry.

#Agents instead of dashboards

Co-founder Raj Dutt introduced the company with numbers. A remote company of 1,700 people spread across more than 40 countries had passed 10,000 paying customers and $600M in annualized revenue, he said. He spent more time, though, on the claim that we’re at the start of a shift bigger than the mainframe or the cloud.

The edge he pointed to is that Grafana, Prometheus and Loki are open source. The stack runs monitoring at a huge number of companies worldwide, and the internet is full of docs and posts on how to run it. That, in his telling, is why frontier models know this stack better than proprietary vendors’ products. So when Assistant went GA earlier this year, it became a usable tool much faster than they expected, and that surprised even them. Public knowledge is training data. For an open source company in the AI era, I can’t think of a more convincing story, and it matched what I’ve felt contributing to OpenTelemetry recently.

The back half of the keynote was about Assistant taking over the work from watching to fixing. Watchers spend tokens during calibration, then run lightweight checks against the telemetry they selected. Deploy a new feature, let a watcher run for a few weeks, and it learns what normal looks like and alerts you when the feature drifts from it. In Investigations, one agent forms hypotheses while other agents concurrently try to disprove them. The presenter said only that letting the agents fight raises quality. My read is that the design targets a model’s habit of committing to one plausible cause too early. Managed Sandboxes take the investigation’s findings, change the code in your repository and open a PR. In the demo, Assistant stepped into a GitHub CI stage and commented that the PR apparently would break an SLO, and once an incident investigation finished it produced a fix PR from the result. They said they run a loop of their own that prepares a PR every Monday to cut CPU usage at the hotspots profiling found.

Slide at 49:05 of the keynote recording. Source: Grafana on YouTube

I was more interested in the controls on code changes than in the fixing itself. Each task gets its own MicroVM, and policy decides which networks it can reach, whether it may push branches, and when it creates a PR. Pages, which builds a screen from a single sentence, offers a different safeguard. You can inspect the queries behind its output, and the presenter added that the model can make things up, so trust but verify. The Pages demo had its moment when zooming out wouldn’t work and two people stood there briefly flustered.

Grafana has accepted OpenTelemetry data for years. The instrumentation announced here is OpenTelemetry on the producing side as well. Agent Observability went GA with OpenTelemetry instrumentation support. This is what the keynote called observability for AI, and the OpenTelemetry GenAI semantic conventions I’ve been working on lately are the spec for exactly this. Instead of a proprietary agent, Mobile Observability adds iOS and Android support directly to the upstream OpenTelemetry SDKs from the start. The presenter who then ran the Android demo also said Grafana is now the second largest contributor to OpenTelemetry. Logs you’d rather not throw away get shipped to your own bucket in OpenTelemetry format too.

Slide at 27:20 of the keynote recording. Source: Grafana on YouTube

Still, if my team adopts agent operations, the order has to start with context, not PRs. The model knows the software stack but not our architecture, and without context it burns tokens re-deriving the structure on every question. Grafana’s Knowledge Graph is that context. It pulls how infrastructure, runtimes and applications connect out of telemetry, automatically and continuously. The graph is GA, and the gcx CLI and an MCP server let an outside agent like Claude Code read the same graph. The 25% token reduction on the slide comes from Grafana’s own measurement, the median over the pairs that reached the same conclusion out of 553 pairs where an agent with the graph and one without investigated the same alert separately. What we’d check first on our side is whether the service name carries the same value on every signal, and whether calls between services connect in traces. If names disagree, the graph can count one service as two, and if calls break, there’s less ground for tying a metric anomaly and a log error to the same incident. The agent then fills that gap with inference, and a Watcher on a sloppily instrumented system is likely to learn noise rather than normal.

Slide at 22:10 of the keynote recording. Source: Grafana on YouTube

I only run self-managed Grafana, so I checked whether any of this applies to us. The features in this keynote, from Assistant through Watchers and Managed Sandboxes to Pages, need a Grafana Cloud account. You can use Assistant on self-managed Grafana, but it has to connect to a Grafana Cloud stack. Investigations and Grafana Cloud MCP connections stay off in self-managed even with a Cloud stack attached. What self-managed does get is Loki full-text search and the OpenTelemetry SDKs, and they said the Loki side will reach an open source release shortly. For someone who has held out on self-managed, this is the first time there’s a reason to use the cloud. I haven’t used Assistant yet, so this judgment rests on the keynote alone. I plan to verify it with a PoC when I get the chance. The baseline is the record a human left investigating the same incident, and I’ll look at whether it got the cause right and whether the fix PR was mergeable without edits. (We could also build this structure ourselves, of course, inside the agent harness we’ve been putting together.) Either way, the direction is clear. Observability tools are moving from only showing you things to resolving incidents. Grafana starting to open PRs is what that means. And then telemetry is no longer a record you keep. Which telemetry you send becomes the input that decides what the agent changes and how.

#Two announcements outside the main thread

The official guide sorts everything into GA, public preview and private preview, so this section adds just two things the main thread didn’t cover. If you’re short on time, I’d start at 32 minutes into the video.

One is user-side observability, which Grafana files under digital experience monitoring. Frontend Observability grew Session Replay and Critical User Journeys, and Mobile Observability landed next to it in private preview. The presenter said Mobile has been one of their most requested features.

The other is cost, and the message was that they’d absorb the telemetry explosion with technology rather than price. The evidence was running entire regions inside the customer’s cloud account, a bare-metal cluster being built in Ireland, and Mimir’s 10 billion active series, up tenfold in a year. Loki full-text search went GA on indexing technology they acquired in April, with average queries 5x faster and 75% less data scanned, they said. That it comes at no additional cost is in the official guide. Sampling policies get pushed down to Alloy and OpenTelemetry collectors so data you’d drop is dropped before it’s sent. For now that applies to logs only, with other signals to follow, they said.

Slide at 17:10 of the keynote recording. Source: Grafana on YouTube

The event is still underway in US time. Once the session recordings are up, I’ll go through them and add the ones worth watching here.

#References

ObservabilityCON 2026 Keynote (YouTube, Grafana). The one-hour keynote in which eight presenters, Raj Dutt and Tom Wilkie among them, walk through cloud economics, context, agent operations and Pages in turn.
ObservabilityCON 2026: A guide to all the announcements from Grafana Labs. The official guide that sorts the announced features into GA, public preview and private preview.
Grafana Labs Charts the Path to Agentic Operations (press release, Oct 20, 2026). The press release announcing OpenTelemetry support in Agent Observability, Watchers going GA, and the public previews of Pages and Managed Sandboxes.
Grafana Assistant for self-managed Grafana. The official doc on what it takes to use Assistant on self-managed Grafana.
Why observability is the key to trusting your AI agents. The session that treats agent sessions as a signal to view alongside metrics, logs, traces and profiles. Worth watching right after the keynote once the recording is up.

I write about building and leading large-scale platforms, from ads and CRM to AI agents, at Namsang Labs Tech Blog.