I spent June 17 at the Linux Foundation's Open Source Summit India 2026 in Mumbai, notebooks and phone camera at the ready. This is a writeup of every session I attended, with the ideas that actually landed, the slides I could catch, and my honest reactions.
The full schedule is at ossindia2026.sched.com. Session recordings are being posted to the Linux Foundation YouTube channel.
Keynote 1: The Moat Moved from Code to Context
Manish Dixit, Linux Foundation
The talk opened with a number that sets the stakes: $42.8B in software value lives in CNCF projects alone (COCOMO estimate). India is the second-largest open source contributor globally, and the software underpinning JioHotstar's 65M+ concurrent streams, Zoho's 130M+ users, and 650M+ daily UPI transactions is built on it.
The central argument was uncomfortable but freeing: AI has made writing code nearly free. The value moved elsewhere.
The Linux Foundation built their own MCP server, LFX Skills, to help maintainers ship faster across organizations. AGENTS.md specification files are now adopted by 60k+ projects as a standard way of giving AI agents rules for a repo. A PR is nearly free to generate. Reviewing one still costs a human.
The talk laid out what it called "the ladder":
| Role | AI's ability |
|---|---|
| Contributor | Can be replaced |
| Reviewer | Needs experience |
| Maintainer | Needs community trust - AI can't fake this |
| TSC / Governance | Reshaping the future of an industry |
The provocation: if you're early in your career and only moving code, the floor is dropping. The ceiling for people with judgement, domain depth, and earned trust is going up. The talk pulled in India-specific proof: Zerodha's $1M/yr FLOSS fund, Infosys donating two AI frameworks to LF Networking, Juspay's Hyperswitch, and TCS/Wipro/HCLTech among the top global LF contributors.
"Consume. Contribute. Fund. Pick at least two."
My takeaway was personal: resume the Contributor and Reviewer chain on LFX and GSSoC. github.com/linuxfoundation and KubeCon + CloudNativeCon India are coming up soon.
Keynote 2: Accelerating Innovation Through Open Source
Aayush Bhatnagar, CTDO, Jio Platforms
A look inside how one of India's largest tech organizations runs its open source operation. In 2016, the entire IT industry was VM-based; containerization was not mainstream. The Jio team was contributing to ONAP (Open Networking Automation Platform) at that point, and that early investment has paid off at national scale.
Jio now contributes to OpenCU and OpenDU through the LF, as part of ongoing 6G research.
The session walked through Jio's internal Linux team and their 5.1 Linux stack: Containerized Network Functions (CNFs), RHEL + UBI (Universal Base Images), and an automation pipeline that uses Jio MANO + Ansible + OpenShift to manage CNF lifecycle across Edge, RAN, Transport, and Core.
The key insight here wasn't the technology, it was the scale at which they operate it and the degree to which open source is load-bearing infrastructure - not a hobby or a PR strategy.
Keynote 3: Cut Database Costs, Fund Innovation with Valkey
Roberto Luna-Rojas, Sr. Developer Advocate, Valkey OSS, AWS
Valkey is an open source, high-performance key/value data store - the community-maintained fork that emerged after Redis's license change.
The pitch: every dollar wasted on redundant database queries is a dollar not going toward model inference, embeddings, or training. Valkey's benchmarks across MySQL, MariaDB, and PostgreSQL show dramatic reductions in response times and cost by caching aggressively.
The more interesting angle was semantic caching for LLM workloads. Two queries that are semantically identical:
- "How do I return this item?"
- "What is the return policy?"
...will both hit your inference endpoint and both get billed, even though the answer is the same. Semantic caching intercepts the second call. For production AI applications at scale, this isn't a micro-optimization, it's a budget line.
Keynote 4: Open By Design - Governed AI, Trusted Outcomes
Geeta Gurnani, Field CTO, IBM Technology India & South Asia
RedHat, in partnership with IBM, announced Project Lightwell during this talk - an AI governance initiative.
The framing: AI acceleration is both powerful and dangerous because the trust gap is widening. Organizations are adopting AI-first business models without the governance scaffolding, and trust erodes because:
- AI decisions are opaque - no auditability, no traceability
- Hallucinations are real and public
- The technology is new enough that people don't have cultural frameworks for it yet
The governance stack she outlined:
Data → Models → Training → Deployment → Monitoring → Governance
When any of those layers are hidden, trust collapses. IBM's AI Risk Atlas was introduced as a framework for mapping risk across this lifecycle - worth looking into if you're building agentic systems.
India-specific note: the EU has the EU AI Act, Singapore has the Singapore AI Act. India is still developing its digital governance framework. That gap is both a risk and an opportunity.
Keynote 5: Rust and Linux - How Rust Will Help Linux Succeed
Greg Kroah-Hartman, Linux Kernel Maintainer & Fellow, The Linux Foundation
Greg is the second biggest Linux kernel maintainer after Linus Torvalds. He maintains the stable kernel branch and a wide variety of subsystems.
The numbers: the Linux kernel today has 36,000,000 lines of C and 113,000 lines of Rust (as of kernel 7.1-rc3). The migration is happening carefully, gradually, with full awareness that both languages need to coexist for a long time.
Why Rust matters for the kernel:
- C allocation errors, scoped lock issues, and pointer bugs are a major source of CVEs
- Rust catches a huge majority of these at compile time, not runtime
- The
?operator in Rust does a lot of this work automatically - Mutex locks and other synchronization primitives become much safer with Rust's ownership model
"Over 80% of current CVEs would be impossible if Linux was written in Rust."
The practical toolchain: GCC, RustToC, and GCC-Rust compilers are all crucial for testbenches. The migration isn't a rewrite - it's a gradual ratchet, where new code is written in Rust and existing C code is migrated carefully where it's highest-risk.
What came through clearly: the people maintaining the Linux kernel take security seriously at a level most application developers don't encounter, and Rust gives them a tool to encode that seriousness into the language itself rather than hoping developers remember the rules.
Session 205: Governing the Ungovernable - Security and Compliance for AI Agents in OSS
Ronit Raj, GitMesh
A talk about a problem that's becoming urgent fast: what happens when an AI agent has access to your repository and does something you didn't intend?
The core issues:
- Agents are vulnerable to prompt injection from untrusted sources (issues, PR comments, web search results, user-submitted content)
- When agents push code, open PRs, or make changes autonomously, mistakes are hard to undo
- Most "safety" approaches are just filters - not enforced constraints
The key insight:
"You cannot just give agents rules. Restrictions must be enforced around the agent."
The practical approach he walked through:
- Use YAML policy files and AGENTS.md to declare constraints explicitly
- Log everything - look for DENY lines in logs, they're your signal
- Gate specific actions that require human approval:
- Merging to main
- CI/workflow changes
- Access to secrets
- Releases and advisories
GitMesh is building tooling around this. The broader principle: treat agent permissions like you treat secrets - explicit, scoped, and audited.
Ballroom 3: Secure by Default - AI-Augmented, OSS-Powered CI/CD
Jenisten Xavier, Full Creative
A practical walkthrough of a reusable CI/CD pipeline built entirely from open source security tools. The stack:
Secret scanning: Gitleaks scans for credentials committed to repos.
Dependency CVEs: Google's OSV-Scanner reads lockfiles and matches them against the OSV.dev open vulnerability database.
SAST + coverage: SonarQube Community Edition, self-hosted. Static analysis for bugs, smells, and vulnerabilities, plus test coverage ingestion and quality gate enforcement.
SBOM generation: CycloneDX via cdxgen generates a machine-readable inventory of every dependency including transitive ones. The practical value:
"When the next Log4Shell drops, you answer 'Are we affected?' in seconds, not days."
SBOM management: OWASP Dependency-Track as the SBOM home.
Release flow:
-
semantic-releaseanalyses commits and decides the version - Image built locally only (not pushed)
- Trivy scans the exact image - HIGH/CRITICAL findings abort the release
- Only a clean image goes to GHCR
-
cosignsigns by digest, keyless via Sigstore
The whole pipeline is reproducible and the tools are all open source. No vendor lock-in at any layer.
Ballroom 2: Don't Trash It, Hack It - Reverse Engineering ISP Routers
Dheeraj Reddy Jonnalagadda, Pixxel
The most hands-on talk of the day, and honestly one of the most entertaining. The premise: ISP-provided routers are opaque black boxes running outdated embedded Linux, and you can take them apart.
The workflow:
- Physical UART access to get a shell or bypass login
- Interrupt U-Boot timeout to get into the bootloader
- Use
init=/bin/shfor root access if the filesystem allows it - Check
dffor filesystem types - if read-only, you know the constraints - Explore
/etc/passwdfor the shell being used - Use
objdumpto examine.rodatasections
objdump -s -j .rodata cli | grep
Sometimes exposes hardcoded passwords directly.
The deep-dive covered MIPS architecture specifically - how the Global Offset Table (GOT) works, how $gp register calculations lead to the right memory slot, and how gdbserver over telnet lets you set breakpoints and read register state to extract live password values.
The payoff: once you have root, you can install dnsmasq and turn the router into a network-wide ad blocker. The session wasn't about breaking things - it was about understanding and reclaiming hardware you own.
Tools used: gdbserver, objdump, ImHex, Ghidra.
Session 203: But It Builds on My Machine - Deterministic OCI Images with Nix
Benjamin Philip, VTU Student, Bengaluru
Docker guarantees reproducible image replication, not reproducible images. The distinction matters: you can reliably run the same image everywhere, but you can't guarantee that building the same Dockerfile twice produces the same image.
Nix's value proposition: structural reproducibility from day one. Packages are isolated during build, have strict hashing, and all dependencies are bundled. Nix doesn't move on until the previous step is fundamentally correct and guaranteed.
Three approaches for building OCI images with Nix:
NixOS base in build stage: Use NixOS for building, copy results to a scratch base. Minor improvement over standard Docker-driven package development.
pkgs.dockerTools.buildLayeredImage: Splits each dependency into its own layer, giving significantly better caching. Downside: can hit Docker's 125-layer limit.
nix2container: Fine-grained control over layer creation, addresses performance issues in pkgs.dockerTools, but adds complexity.
The caveats are real: Nix's store is not FHS (Filesystem Hierarchy Standard) compliant, the learning curve is steep, the community is small, and adoption may require significant workflow changes. The honest question to ask yourself:
- Does bit-wise reproducibility actually matter for your use case?
- Do you have the resources to maintain a Nix stack?
- How well supported are your ecosystems in nixpkgs?
The QnA was excellent - the framing that stuck was: Nix structurally enforces correctness at each step, while Docker scripts can silently skip failures or produce subtly different outputs across environments.
Session 204: Oops, My AI Agent Just Deleted All My Email - Locking Down Agents with Signed Policies
Rahul Vishwakarma, Highlevel
The opening scenario was specific enough to be uncomfortable: a developer's AI coding agent was asked to refactor a module. Instead, it read .env files, ran git push --force on main, and made 300 API calls costing $47. The agent worked exactly as designed. There were just no guardrails with teeth.
aflock is an open source framework built on Witness and in-toto that treats agent permissions like a lockfile treats dependencies - signed, immutable, and verifiable.
The .aflock policy is a signed JSON document specifying all constraints:
{
"tools": {
"allow": ["Read", "Edit", "Bash", "Glob", "Grep"],
"deny": ["Task"],
"requireApproval": ["Bash:rm -rf*"]
},
"agents": {
"scoping": {
"repoAllow": ["org/repo"],
"branchDeny": ["main"],
"pathsDeny": [".env", "**/secrets/**", ".github/workflows/**"]
},
"guardrails": {
"requireHumanApproval": ["merge_to_main", "release", "workflow_change"],
"logAllToolCalls": true
},
"context": {
"untrustedInputs": ["issues", "PR_comments", "web"],
"promptInjection": "treat_as_untrusted"
}
}
}
Identity is computed as:
identity = SHA256(model | env | tools | policyDigest | parent)
Two integration modes: hooks (wrap Claude Code's native tools) or MCP (run aflock as a server over a Unix socket). In the live demo, the policy blocked the agent from printing .env contents.
The attestation model is what makes this verifiable: every action produces a signed receipt with WHO, WHAT, WHEN, and PROOF. This isn't just logging - it's cryptographic proof of what the agent did and didn't do.
Also see: aflock-ai/rookery
Jasmine Hall 2: Confidently Wrong - When AI Cannot Catch Its Own Bugs
Shailja Thakur, IBM Research, Bangalore
This was one of the talks I was most glad I caught. The problem statement:
AI systems handle complex reasoning with fluency but consistently fail at simple logic - arithmetic, timezone conversions, unit mismatches - and do so confidently. The deeper problem: when AI agents use AI-generated content as input, the generator and verifier share the same training distribution and often the same blind spots.
A model that writes a wrong timezone conversion will confidently verify it as correct.
The failure matrix:
| Verifier Accepts | Verifier Rejects | |
|---|---|---|
| Answer Correct | Ideal | False alarm |
| Answer Wrong | Silent Failure | Caught |
The silent failure cell is the dangerous one. Wrong outputs accepted by the verifier get passed downstream as context. They're not caught - they're promoted.
The experimental result: asking a different model to verify doesn't fix the problem. The correlated failure modes persist because the models were trained on similar data distributions.
What does work: deterministic oracles. A rule-based, domain-specific validator that doesn't share the model's blind spots. If you're computing timezone conversions, a deterministic function is better than asking the model to check its own work.
The agent amplification angle was particularly striking: in a Plan → Generate → Test → Review → Deploy pipeline, a wrong answer that passes the Test step gets passed to Review as trusted context. By Deploy, it's been laundered. "Wrong" became "context."
The implication for anyone building multi-agent systems: verification layers need to be architecturally separate from generation layers, not just prompting the same model again.
Jasmine Hall 2: Writing for Machines - Surviving AI Slop and Becoming a Context Engineer
Kaushlendra Pratap Singh & Shaheem Azmal M MD, Siemens
The opening framing hit: open source is currently the battleground for a transition no one fully planned for. AI slop - PRs that look correct, pass CI, and introduce subtle bugs or unsafe patterns - is already a real operational problem for maintainers.
The central reframe: the real IP of a project is no longer the code. It's the context.
Code is a commodity now. You're a reviewer now. Think of it as managing a team of very fast, eager, zero-context interns. They produce volume. You provide judgement.
The new assets:
- Constraints
- Decisions
- Conventions
- Specs
Three anti-patterns killing open source AI PRs:
- Functionality Flickering - same prompt produces multiple different outputs, creating inconsistency
- The Butterfly Effect - a small task (rename a variable) triggers huge unintended changelogs because the agent didn't know the scope
-
Coverage Traps - test coverage jumps dramatically, but the agent is just writing
assert True. The numbers look good. The tests test nothing.
The solution: Context Engineering
The AGENTS.md file is a team artifact, not a personal preference. It explains dependencies, ground-zero rules, and constraints to any AI agent about to execute a task. The frame they used:
"Maintainers can't outrun AI slop by reviewing harder. They outrun it by shaping the AIs that write the PRs."
The spec file becomes the source of truth - not the code. Code is disposable. The spec is not.
AI-adapted TDD:
Old TDD: human writes a test, assumptions are consistent, test validates the spec.
AI TDD: the spec contains test cases written by humans first. The AI implements code and tests from the spec. You're testing intent, not just coverage.
Their final frame: if you've defined the context, built the harness, and set up the feedback loop - congratulations, you are now a Context Engineer.
Closing thoughts
It was a full day. Here's what I'm taking away:
The open source contributor ladder matters more now, not less. The argument from Keynote 1 has stuck with me: AI can be a contributor, but it can't earn community trust. If you're building a career in this space, being visible and useful to real projects is a moat that AI can't replicate.
Agent security is a real engineering problem, right now. Aflock, GitMesh's policy approach, and the AI governance keynote are all pointing at the same gap: we're deploying agentic systems without the accountability infrastructure that production systems need. Signed policies, attestations, and deterministic validation layers are all part of what "production-ready AI" is going to mean.
Silent failures are the most dangerous kind. Shailja's talk was a reminder that confidence and correctness are not the same thing. If you're building AI into your pipeline, design the failure modes deliberately. Assume the model is wrong before assuming it's right.
India's open source story is not a footnote. UPI, Zoho, JioHotstar, Juspay, Zerodha - the infrastructure running India's digital economy sits on open source, and Indian engineers are increasingly the ones maintaining it. That's something worth paying attention to.
Attended June 17, 2026. Full schedule at ossindia2026.sched.com. Session recordings on the Linux Foundation YouTube channel.
Images are from my phone during the sessions - apologies for any blurriness on the keynote slides.
Top comments (0)