Attendees & Representation

TAC Members and Project representatives should mark their attendance below 

Agenda

• Check Action Items & Topic Requests (Backlog)

• F2F Developer Events follow up

• Any Other Topics

• Cancellation Notice and/or documented in the meeting minutes.

• How is AI impacting the consumption model of the LFN Projects?

  • Request to assign a contact person from each project to jointly discuss how to handle Agentic AI consumption of the code

• LFN Vulnerability Reporting

• Archiving of Anuket Project.

Face-to-Face Event Planning

Discussion continued on how to structure the next developer face-to-face event so that organizations have a concrete reason to fund travel.

Background presented on the call:

• The historical purpose of the face-to-face is to get developers in the same room. Issues that take several meetings or long mailing list threads to resolve tend to get settled quickly in person, and active contribution measurably increases after these events.

• Events have typically been scheduled near the point where communities are planning their next release.

• With tighter travel budgets, the framing needs to shift from "it would be good to attend" to a tangible deliverable that justifies the spend.

Ideas raised as starting points: structured contributor training for upstream work, hands-on labs with defined deliverables, on-site certification, and architecture working sessions. The common thread is work that requires being in the same room and produces something at the end.

Tony Hansen noted from his standards experience that with three meetings a year, roughly the same amount of work got done in a single meeting week as in the four months between meetings.

Ravi Sharma noted that the outcome needs to be identified first, since organizations approve budget based on the benefit to them.

Timing was flagged as the main constraint. Companies begin 2027 budget planning within the next one to two months, with budgets typically finalized between September and November. The TAC needs an answer early enough to bring a proposal to the Governing Board, and for board members to take it back to their own budget teams.

Note on the Previous Meeting Cancellation

The cancellation notice for the previous TAC meeting did not reach everyone before the scheduled time. The cause was a defect in the LF meeting platform that affected cancellations. LF IT reports the issue has been resolved. The Linux Foundation takes responsibility for the miss.

AI Impact on the Consumption Model of LFN Projects

This was the main discussion topic. The focus is on how AI agents discover and consume LFN project code, rather than on how contributors use AI to write code.

Framing. Ranny Haiby reported that roughly 60 percent of traffic to LFN web properties now comes from LLM scrapers. Software selection increasingly happens when a developer gives an abstract task to a coding agent and lets the agent choose the technology. Where the audience used to be human architects reading blog posts, white papers, and newsletters, the audience now includes coding agents. Most LFN projects are components inside a larger system, so the practical risk is that agents assemble solutions without selecting LFN projects at all. Communities that are not already working on discoverability and consumability for AI agents should treat this as urgent.

Available mechanisms. Muddasar Ahmed asked whether skills and MCP servers should be on an LF roadmap. The response was that the tools already exist, including MCP, AGENTS.md, and A2A, but there is no single approach that fits every project. Each community has to decide which mechanisms suit its technology and then do the work to apply them. This is ongoing effort rather than a one-time task, since the tooling will keep changing.

AI SEO / answer engine optimization. Sunny Singh raised AEO as the relevant discipline, including getting MCP servers listed in the popular registries that agentic tools query. Ranny noted he had previously shared an LF presentation on AEO and offered to reshare it. Practical guidance discussed: state plainly what the project does, how it is used, and what it is relevant for, and cut marketing fluff from project sites. The same changes help human readers.

Counterpoint on current agent capability. Douglas Knisely observed that coding agents are already effective at finding, installing, configuring, and using open source projects from existing source and documentation, and cited a reported NVIDIA experiment in which a coding agent built a full stack RAN over about two weeks, pulling in reference implementations from open source projects to test its own components. His point was that well-documented projects may already be in reasonable shape, and that the gap is most likely in projects with weak documentation. He suggested that pre-built images and clear install and setup instructions raise the chance an agent selects a project.

Ranny agreed that existing documentation, discussions, and code examples are a reasonable starting point, but noted that LFN projects are niche relative to widely used technologies, so there is proportionally less material in any training corpus and proactive work is still needed.

Attribution concern. Muddasar Ahmed raised the question of attribution when models assimilate knowledge from LF repositories and regenerate equivalent code without credit to the originating project. Douglas Knisely noted this is a problem shared by creators generally and that open source is oriented toward use rather than credit. No resolution was reached, and the TAC agreed to focus on what it can control.

Internal opportunity. Olaf Renner noted that LFN has a candidate project working on multi-agent closed-loop automation for 5G networks, and that there is an opportunity to experiment with agentic systems across LFN projects, not only to be discovered from outside.

Suggested self-assessment. Two tests were proposed for communities to run on themselves:

1. Ask an LLM for an overview of the project and see how much depth comes back beyond a few surface bullets.

2. Describe a generic problem in the project's domain, without naming LFN or the project, and ask for a detailed system design. If LFN projects are selected, the project is positioned well. If not, the community needs to determine why.

Communication to the wider community It was confirmed that every project TSC has a mailing list, and that a combined list exists for low-volume, high-importance messages. The TAC agreed that this topic warrants a message to all project TSC lists rather than being raised only on the call.

Reminder: Vulnerability Reporting

Casey Cain reminded projects to review their vulnerability reporting process. A list of project vulnerability reporting contacts is maintained on the LFN wiki, and not every project entry is current. Each project should confirm that it has a vulnerability contact, that the address is functional, and that the people on the list are still active in the community. The wiki link was posted in the Zoom chat.

Anuket Archival Request

Sridhar Rao presented a resolution approved by the Anuket TSC requesting that the Anuket project be archived, and asking the TAC for guidance on the sub-projects that remain active. The resolution text was posted in the chat. Olaf Renner confirmed the request covers the specification track.

The TSC's position is that the project has reached a stage where no further work is expected. The open question is the disposition of the Functest and Releng sub-projects. Options discussed: leave them in place with Anuket remaining active for those two sub-projects only, move them to another project, or bring them forward independently.

Points raised in discussion:

• Muddasar Ahmed noted that LFN has a documented project lifecycle and archival process that took roughly a year to refine.

• Casey Cain confirmed that archival is the TSC's decision to make, with notification to the TAC, the community, and the mailing lists. LFN governance does not currently define a process for transferring or forking sub-projects into other projects. Maintenance mode is also an available lifecycle state if the community prefers it to archival.

• Muddasar Ahmed suggested that the cleanest path for Functest and Releng is to apply as a sandbox or incubation project on their own merits, with promotion available if community support materializes.

• Sridhar Rao reported that Functest currently has two contributors and no active TSC involvement.

• Olaf Renner noted that Functest is still used downstream by Sylva, and that a different host project may be a better fit. Where the sub-projects land is a discussion for the projects themselves.

• On the mechanics of archival: repositories remain publicly available indefinitely. After a defined period, currently set at one year, repositories are locked so that further contribution requires a fork, since no maintainers remain to review pull requests.

The TAC asked that the request be circulated by email before any action is taken, including to downstream consumers outside LFN where they are known, so that anyone still consuming Anuket or its sub-projects has the opportunity to volunteer to fork or maintain the code.