Inaugration & Opening Plenary (Others)

• Till Kamppeter (OpenPrinting)
• Aveek Basu

Fireside Chat: Kate Stewart on Zephyr (Community)

• Kate Stewart

Room: Room 1 TBD

Demystifying Linux Kernel Initialization (Development/Coding)

• Shuah Khan (The Linux Foundation)

Room: Room 1 If you ever wondered what happens between the time you power up your laptop and when you get back with that steaming cup of your favorite beverage? This talk will take the lid off and demystify the Linux kernel boot process. In addition, it covers how to enable KNL (kernel start-up parameter) initcall_debug to allow trace init_calls as they are executed to get insight into the early boot sequence. Learning how to enable early debugging comes in handy when you are faced with a boot problem during boot, performance regressions during boot resulting in longer boot times, and a variety of other problems.

How to start your Open Source journey? (Community)

• Till Kamppeter (OpenPrinting)
• Aveek Basu

Room: Room 1 Open Source is more than just code—it’s a global movement built on collaboration, transparency, and shared growth. For newcomers, however, the first step can feel overwhelming: Which project should I choose? Do I need to be an expert? How do I make my contributions count? This talk will demystify the process of getting started with Open Source. We’ll cover the essentials—from understanding community culture and finding beginner-friendly projects to making your first contribution and building a sustainable journey. Whether you’re a student, professional, or hobbyist, you’ll learn practical strategies for identifying opportunities, collaborating effectively, and showcasing your work. By the end of this session, you’ll walk away with a clear roadmap, actionable resources, and the confidence to take your first (or next) step in the world of Open Source.

Everything Was Fine Until the Conference Started (Zephyr)

• Akarshan Kapoor (Indian Institute of Technology, Mandi, India)

Room: Room 1 On paper, conference streaming is easy: put some video into a browser and send it to YouTube. That version worked perfectly, right up until we added three rooms, remote speakers, screen sharing, twelve stream keys, and people waiting for the event to start. This talk is about the system we built around VDO.Ninja to handle the resulting mess. One server runs three independent room pipelines, mixes speakers and slides, and routes each room to the right YouTube event. More importantly, it tries very hard to stop an operator from streaming Room 2 into Room 1’s keynote. We will look at the decisions that mattered once the prototype met production: isolating rooms, keeping secrets out of logs, preventing conflicting services, restarting failed components, and checking the entire pipeline before somebody says, “We are live.” or "Why is it not streaming?" There is some FFmpeg, some systemd, and a healthy amount of defensive Bash. The video encoding was the easy part. Making the setup boring enough to operate during a real conference was the actual job.

Risk aware Open Source Software Contribution (Security)

• S. Venkatesan

Room: Room 2 Abstract: The use of Open Source Software in cybersecurity is increasing because its source code is transparent and can be reviewed by the public. Anyone can propose contributions to many open source projects, however, these contributions are reviewed and validated by the project maintainers before being incorporated into the official codebase. The open source softwares is used by individuals as well as the small, medium and large scale organizations. The security bug in a software will affect every user and increase the risk to the confidentiality, integrity, and availability of their systems and data. Therefore, this becomes the easiest attack vector for the attacker to compromise millions of users in a single attack or update instead of attempting to compromise every user individually. An attack may involve unauthorized modification of the software or the submission of malicious or vulnerable code as a contribution. Although all code contributions are reviewed and verified before being incorporated into the official codebase, there is still a possibility that malicious code or subtle vulnerabilities may escape detection and be included in the software. There are incidents where contributors intentionally or unknowingly left the software with bugs. The impact of such a scenario can be significant because open source software is widely used. Therefore, contributors should understand the potential impact of their changes and contribute to open source projects responsibly and ethically to mitigate the security risk. Also, when using LLM for the code generation, contributors need to analyse the code in detail to identify security vulnerabilities, logical errors, and other defects, reducing the burden on project maintainers and improving the overall security of the software

OpenPrinting - Q&A (OpenPrinting)

• Till Kamppeter (OpenPrinting)
• Ayush Singh
• Uddhav Phatak
• Omkar Nanajkar
• Aveek Basu

Room: Room 1 Now, after Till has given you an overview about OpenPrinting, you probably have many questions, for example: - How to get started as contributor to OpenPrinting? - What can I do if I am not a coder? - How do I get printing into my apps? - How do I design a driver for a non-IPP legacy/specialty printer? - How do I report issues? - ... Till, Aveek, Uddhav, Omkar, and Ayush (and perhaps other people from OpenPrinting) will answer your questions. [More about OpenPrinting ...][1] [1]: https://openprinting.github.io/OpenPrinting-News-25-years-of-working-full-time-for-printing-with-free-open-source-software/

All about The Linux Foundation

• Sridhar Rao (The Linux Foundation)

Room: Room 1

One Micro-Commit at a Time: Migrating Legacy GNOME Apps to GTK4 (Development/Coding)

• Divyanshu Rajput (GNOME Foundation)

Room: Room 2 When I first opened the codebase of GNOME Gitg to help with its GTK4 migration, I was staring at thousands of lines of deprecated API calls, removed widget types, and a build system that refused to cooperate. The natural instinct was to rewrite everything at once. But that approach gets your merge requests ignored and your motivation burned out fast. Instead, I adopted a strategy of micro-contributions: tiny, focused merge requests of 10 to 15 lines, each addressing exactly one deprecated API. Over five months, this approach let me systematically modernize the application while keeping the maintainers happy and the codebase stable. This talk is a practical field report from that ongoing migration. I will walk through real code diffs, share the specific GTK4 pitfalls I encountered, and demonstrate why small, consistent contributions are far more effective than heroic rewrites when modernizing legacy desktop applications. **What the Audience Will Learn:** * **The Micro-MR Strategy:** How to decompose a massive migration into reviewable, self-contained merge requests that maintainers approve quickly. * **GTK4 Migration Patterns:** Concrete before/after code examples (migrating Gtk.main() to GLib.MainLoop, replacing Gdk.Screen with Gdk.Display, removing deprecated container packing). * **Upstream Collaboration:** How to communicate with maintainers and build trust as an outside contributor.

Debugging Distributed AI Benchmarks: Lessons from KubeEdge Ianvs (Development/Coding)

• Abhishek Kumar (The Linux Foundation)

Room: Room 2 KubeEdge Ianvs is a CNCF distributed AI benchmarking toolkit used to test machine learning workloads across edge computing environments. As an LFX Mentee with CNCF, I spent four months working through a problem that doesn't get talked about enough in AI tooling: benchmarks that work on one machine and silently break on another. The core issues weren't algorithmic — they were dependency drift across distributed AI examples, Python version inconsistencies that only showed up across different environments, and runtime configurations that worked by accident rather than by design. Fixing them meant tracing failures back through dependency chains, reproducing environment-specific bugs that didn't show up locally, and rebuilding configurations so they'd actually hold up across setups instead of just working on the maintainer's machine. This talk covers what those bugs actually looked like, how I diagnosed them without access to every environment they failed in, and what it taught me about writing benchmarking code that's reliable across machines — not just correct on one. I'll also talk about what it's like mentoring under CNCF: how LFX mentorship actually works, what maintainers expect from contributors, and how to get unstuck when a bug only reproduces in someone else's environment. No prior Kubernetes or CNCF background required, though basic familiarity with distributed systems concepts will help. What you'll leave with: 1.A real example of environment-specific bugs in distributed AI tooling and how to track them down 2.Practical lessons on writing benchmark code that survives different setups, not just your own 3.A picture of how CNCF/LFX mentorships work, for students considering applying

How I Went From Contributing to Open Source at 16 to Being an Org Member at 17, and How You Can Be One Too (Community)

• Ayush More (Sherlocks.ai)

Room: Room 2 This is a story about rejection, persistence, and what it actually takes to go from your first open source PR to becoming a trusted contributor. I started contributing to CNCF projects at 16, beginning with Meshery where I learned the fundamentals of open source culture. I then tried contributing to Backstage, which did not click for me due to its complexity, and learned an important lesson about finding the right project fit instead of forcing it. Everything changed when I found PipeCD, a CD focused CNCF project. I went all in, contributed consistently over months, and eventually became an org member at 17. Along the way open source gave me a lot back, a Linux Foundation travel fund scholarship to Europe, the Dan Kohn Scholarship for KubeCon India, and a Linux Foundation Lift scholarship. I was even shortlisted for an LFX Mentorship and the only thing that stopped me was an age restriction. This talk will walk through the real journey, the setbacks included, and break it down into a practical, repeatable playbook anyone can actually use. How to pick the right project. Why starting with documentation and small fixes matters more than people think. How to build trust with maintainers over time instead of trying to rush it. And the common mistakes first timers make like spamming PRs or over tagging maintainers. This talk is for students, early career engineers, or anyone who has wanted to get into open source but did not know where to start. It directly speaks to building contribution pathways for newcomers, a core focus of the open source community track.

Code That Saves Lives: Open Source in Computational Cancer Genomics (Community)

• Rishi Prasad Sulakhe

Room: Room 2 cBioPortal for Cancer Genomics is an open-source platform used by cancer researchers at 100+ institutions worldwide to explore mutation data. When you contribute here, your pull request isn't just a commit — it's a tool an oncology researcher might use tomorrow to understand a real tumor. This talk is a fast walkthrough of two features I built as a GSoC 2025 contributor to bring Variant Allele Frequency (VAF) a metric that reveals whether a mutation is a dominant tumor driver or a minor subclonal eventinto cBioPortal's core views: cohort-level box plots on the Plots tab, and a new heatmap track in OncoPrint, cBioPortal's flagship visualization used across thousands of studies. The bigger point: open, community-reviewed code sitting directly in the path of cancer research gets better precisely because anyone can read it, question it, and improve it. I'll close with what it actually looks like to go from a first small PR to a merged, mentor-reviewed feature and why bio/health is a great place for open-source contributors to make code that matters.

How to be human when contributing to open source (Development/Coding)

• Kevin Aleman

Room: Room 2 AI has made contributing to open source easier than ever. It has also made it harder than ever. Anyone can now generate pull requests, issues, and vulnerability reports in minutes, but maintainer capacity hasn't grown and review cost hasn't dropped. The result is a flood of low-signal contributions that is exhausting maintainers, as projects like curl have publicly documented, and drowning out the contributors who actually do good work. This talk explores the new economics of open source contribution: when producing code costs almost nothing, the scarce resource becomes trust. Drawing on real experience maintaining a large open source project (hundreds of issues triaged monthly, AI-generated PRs that look correct until they aren't), I'll show why reputation is now the thing that scales, and how contributors can build it deliberately. Attendees will leave with practical strategies: how to use LLMs as a tool rather than a substitute for understanding, why review cost asymmetry should shape how and when you submit, what makes a contribution cheap to review, and how to avoid becoming an accidental denial-of-service attack on the maintainers you're trying to help. Whether you're a first-time contributor or a maintainer setting policy, this talk offers a grounded look at how to keep open source human in the era of infinite code generation.

Mechanistic Interpretability: Inside the Mind of AI (Artificial Intelligence, Machine Learning, Data Science)

• Pranav Mamane Mamane (iit2025021@iiita.ac.in)

Room: Room 2 Artificial intelligence systems can do more and more intricate tasks, but still, the inside stuff behind why they behave the way they do can be hard to get a grip on. And really, if humans built AI, how could we not know the way it works ? The basic point is the difference between making a learning system, versus directly programming the internal computations it ends up forming. In this talk we’re looking at Mechanistic Interpretability (MI)—a kinda emerging method that tries to reverse-engineer neural networks by pushing their behavior back toward internal representations, features, circuits, and computations. Along the way there’s a neat tie-in to neuroscience too: instead of treating intelligence as something we only infer from behavior, could we understand it by finding the hidden mechanisms that actually generate it ? Then we’ll shift to why it matters for AI safety and security. Like, if we had a clearer view of model internals, would that give us a better perspective for examining hidden capabilities, deceptive conduct, instruction conflicts, or other weird behaviors that might not show up just from the outputs alone Finally, we’ll cover the current limits of MI, and why understanding more and more capable AI systems may end up being one of those defining scientific , and security challenges for the future, even if that sounds a bit far off right now.

Open source GPU drivers will boost the RISC-V SoC market (Sponsor's presentation)

• Iulian Arcus (DeepComputing)

Room: Room 2 Talk from **DeepComputing** Embedded class SoCs have a major problem: no one can afford to keep the GPU drivers up to date with the Linux Direct Rendering Manager API. SoC manufacturers invest their sales revenue into the next generation, not support. GPU IP designers also charge for driver support. No one is willing to pay. The result? Hardware exposed to the internet with either no working GPU drivers or an old Linux version with no backports for security. Millions of devices with security vulnerabilities. RISC-V is in a unique position to fix this: the RVV specification allows executing parallel workloads such as graphics rendering on the CPU efficiently, thanks to the focus on AI. The project takes the existing software renderer in Mesa3D and proposes how the driver can be modified to take advantage of RVV and IME extensions. This will enable embedded RISC-V SoC devices with RVA23 to live securely on the internet.

Printing Without Linux: Bringing CUPS to Zephyr RTOS (Zephyr)

• Omkar Nanajkar

Room: Room 2 Hello contributors! This talk is about how I got introduced to Zephyr RTOS and my journey as a contributor with OpenPrinting. I will dive into my Google Summer of Code (GSoC) project, sharing how OpenPrinting and Zephyr actually work together under the hood. I'll share the real story of how I got selected by OpenPrinting and how I spent my summer working closely with printers. We will explore how things like the Internet Printing Protocol (IPP) and mDNS operate in an embedded environment, the unexpected challenges I faced along the way, and exactly how I overcame them. If you are curious about Zephyr, passionate about open source printing, or eager to see how these two worlds connect, I look forward to meeting you at the talk!

Hands On Workshop on Open Source EDA Tool eSim (Development/Coding)

• Sumanto Kar (IIT BOMBAY)

Room: Room 3 This hands-on workshop introduces participants to eSim(https://esim.fossee.in), an open-source Electronic Design Automation (EDA) tool developed under the FOSSEE(https://fossee.in) (Free/Libre and Open Source Software for Education) Project at IIT Bombay. eSim provides an integrated environment for schematic capture, SPICE-based circuit simulation, waveform analysis, and PCB design by combining powerful open-source tools such as KiCad, Ngspice, GHDL, and KiCad's PCB editor. Designed for students, educators, researchers, and engineers, the workshop offers practical experience in designing, simulating, and validating both analog and digital electronic circuits. Participants will gain familiarity with the complete design workflow, from creating schematics and running simulations to analyzing results and preparing PCB layouts. The session will also highlight the advantages of adopting open-source EDA tools in education, research, and product development. In addition to the core eSim workflow, the workshop will provide an overview of how eSim integrates with the broader open-source silicon ecosystem, including interoperability with open-source digital design flows such as the OpenROAD Flow Scripts (ORFS) and IHP PDK. By the end of the workshop, participants will have developed practical skills that enable them to confidently use eSim for circuit design projects and serve as a foundation for exploring open-source ASIC and VLSI design workflows.

From Zero to Your First Zephyr Program (Zephyr)

• amit kumar (Chitkara university Punjab)
• Omkar Nanajkar
• Akarshan Kapoor (Indian Institute of Technology, Mandi, India)

Room: Room 3 This workshop introduces participants to the Zephyr Real-Time Operating System (RTOS) and its key advantages for modern embedded-system development. Participants will set up and configure the Zephyr development environment, gain practical familiarity with the West build tool, and learn the complete workflow for building, flashing, and executing a Zephyr application on supported hardware. Through a hands-on GPIO programming exercise, attendees will also use Zephyr’s GPIO API to control an LED, establishing a foundation for developing reliable, portable, and scalable embedded applications using Zephyr RTOS.

From Zero to Open Source: The Roadmap Every Beginner Wishes They Had (Community)

• Aman Mishra
• Saksham Tiwari
• Ayush Singh
• Shivam Gupta

Room: Room 1 Every year, thousands of students discover open source with excitement, only to abandon their journey after facing confusing documentation, unfamiliar tools, large codebases, or the fear of making mistakes. The biggest challenge isn’t writing code it’s knowing where to begin. This session presents a practical roadmap designed to help beginners confidently navigate their first steps into the open-source world. Drawing from real experiences, we will break down the contribution journey into clear, achievable milestones from setting up Git and GitHub, choosing the right project, understanding repository structures, and finding meaningful beginner-friendly issues, to submitting a first pull request and collaborating effectively with maintainers. Using OpenPrinting as a real-world example, attendees will see how consistent learning, curiosity, and community engagement can transform a complete beginner into a valuable contributor. Rather than focusing on complex tools or advanced programming concepts, the session emphasizes mindset, communication, problem-solving, and the habits that lead to long-term success in open source. Whether you’re a student taking your first steps, an aspiring contributor unsure where to start, or someone who has attempted open source but felt overwhelmed, this talk provides a clear roadmap that removes the uncertainty from the journey. Attendees will leave with actionable strategies, practical resources, and the confidence to make their first contribution while understanding that every experienced contributor once started from zero.

The 't' Build Playbook: A Practical Guide to Migrating to Free-Threaded Python (Development/Coding)

• Swaraj Pande (Software Engineer (L2) @ Red Hat)

Room: Room 2 With **PEP 779**, Python 3.14 marks free-threaded Python as **supported and no longer experimental**. The exploration phase is over - **it's migration time**. As per PEP 703, the GIL will be disabled by default by 2028-2030, making migration planning urgent. This talk covers how to **practically migrate** existing codebases to the free-threaded build. We will explore **best practices** for auditing C-extensions, transitioning from **multiprocessing to threading**, and thread-safe CI pipelines. We will **dive deep into the traps** developers miss - implicit atomicity loss, false sharing, and single-thread regressions - alongside **real production migration stories**. Ideal for Python developers maintaining production codebases and library authors preparing for the free-threaded future.

The Lean UbuCon Playbook (Community)

• Bhavanishankar Ravindra (Private Entrepreneur/Ubuntu developer)

Room: Room 1 Open source communities often believe that successful conferences require large budgets, dedicated staff, expensive event platforms, and corporate infrastructure. My experience with UbuCon India 2025 demonstrated the opposite. This talk presents a practical framework for organizing a community-driven conference using a lean operational model built around volunteers, open source tools, local partnerships, and transparent processes. I will share lessons learned from planning and executing UbuCon India 2025, including venue selection, sponsorship strategies, volunteer coordination, speaker management, community outreach, accessibility considerations, content curation, and event operations. The session will focus on actionable techniques that other open source communities can immediately adopt to launch regional conferences without significant financial resources. Attendees will leave with a reusable blueprint, checklists, and operational principles that reduce complexity while maximizing community impact. Whether you are organizing an Ubuntu event, Linux User Group gathering, FOSS conference, or developer community meetup, this talk demonstrates how sustainable community events can be built through people, process, and open collaboration rather than budget alone.

From LFX Mentee to Mentor: Lessons from Building Production Open Source (Community)

• Akarsh Sahlot

Room: Room 2 From LFX Mentee to Mentor: Lessons from Building Production Open Source Open source isn't just about getting your first pull request merged—it's about continuously learning, contributing, and eventually helping others grow. In this talk, I'll share my journey from being selected as an LFX Mentee, becoming a Linux Foundation Mentor, and contributing to projects like Google Summer of Code (CERN HSF) and Code for GovTech (C4GT). Along the way, I'll discuss the technical and collaborative skills required to work on production-grade open-source software. We'll cover: Getting started with Linux Foundation Mentorship Understanding large production codebases Writing production-quality backend code Code reviews, testing, and release engineering Fixing race conditions and improving system reliability Becoming a maintainer and eventually mentoring new contributors What mentors actually look for in pull requests Lessons from collaborating with global open-source communities How open source can accelerate your engineering career Rather than focusing only on acceptance into mentorship programs, this talk highlights the journey of taking ownership, contributing consistently, and giving back to the community by mentoring others.

Serving LLMs your way: A tour of CNCF KServe's deployment models (Artificial Intelligence, Machine Learning, Data Science)

• Atharva Mhaske

Room: Room 2 Running open source models locally or self-hosting is the new moat. Today, in this rapidly moving AI age, data sovereignty is becoming more important. We don't want some vendor locking us in and getting access to our organisation's critical internal data. Most organisations are moving away from giant providers who provide closed models like a black box, and we have to pay huge bucks every month without even having track of usage and other metrics. As API pricing keeps moving up and up, a few teams have already moved on to self-hosting LLMs and fine-tuning them in a way that aligns with organisational outcomes. This has led to huge demand for a new type of engineer called an "Inference Engineer." Unlike Infra Engineers, Inference Engineers handle the full deployment and serving lifecycle of LLMs and manage day-2 operations, just as traditional systems used to have. In this talk, I will unpack how this shift is happening, as open weight models are giving good competition to frontier models, while GPUs are also becoming more accessible. I will also show how projects like KServe from the CNCF ecosystem have removed friction and give your team a level of abstraction. I will then bring it back to the how by using KServe's deployment modes like Raw Deployment, Serverless, and the newer disaggregated LLM Inference Service as the infrastructure layer that makes running your models practical, not just possible. I will also cover milestones and recent updates in the KServe project, its production adapters, and how they have evolved. This is not going to be a deep technical talk, but I feel everyone should get familiar with running some SLMs on local machines and playing with them. If you are new to serving LLMs locally or have thought that it is not ideal to self-host and serve them in production at scale, this talk will give you an overview of how deploying models is different from deploying traditional services with the help of Kubernetes. I'll pinpoint some of the trade-offs and gotchas that I learned the hard way, and I'll be open for some Q&A.

From Voice Memo to PDF: Building FireForm's AI Pipeline at UN-OICT (Artificial Intelligence, Machine Learning, Data Science)

• Abhishek Kumar (The Linux Foundation)

Room: Room 2 FireForm is a UN-OICT official Digital Public Good , that lets first responders generate every agency's required PDF reports from a single voice memo — no manual form-filling, no duplicate data entry across departments. I'm building this as a GSoC 2026 contributor, selected from over 200 applicants for one of two spots. The pipeline has three core pieces: OpenAI Whisper handles local voice transcription with preprocessing and abbreviation normalization (fire department jargon doesn't transcribe cleanly out of the box). Pydantic validation with retry logic, layered on Ollama and Mistral 7B, catches and corrects extraction errors instead of letting them fail silently. A YAML-driven multi-agency PDF system lets a new fire department onboard by writing a config file, not code. This talk walks through how each piece works, the specific failure modes you hit when LLM output feeds directly into structured, agency-specific documents, and what it's actually like contributing to an active open source project as a GSoC contributor — how to get useful context fast in an unfamiliar codebase, when to ask maintainers versus dig in yourself, and what it takes to get a contribution merged into production software used by real fire departments. No ML background required. This is a talk about engineering discipline around LLMs in production, not model architecture. What you'll leave with: - A concrete look at how voice-to-structured-document pipelines are built - Specific failure patterns when LLM output needs to be reliable, not just plausible - A realistic picture of what GSoC contribution work looks like, for students considering applying

From Paper to Working System: Reproducing AI Research When the Weights Aren’t There (Artificial Intelligence, Machine Learning, Data Science)

• Divyanshi Sharma (Indian Institute of Technology, Madras (IIT MADRAS))
• Atul Saxena (Indian Institute of Technology Madras (IIT Madras))

Room: Room 1 Reproducing modern AI research often sounds straightforward: read the paper, clone the repository, download the checkpoint, and run the experiments. In practice, that is often where the problems begin. What happens when the model weights are missing? When the training configuration in the paper does not quite match the repository? When the dataset format has changed, dependencies no longer work, or your reproduced results differ from what was reported? In this talk, I’ll walk through the practical process of turning an AI research paper into a working, reproducible system, using my experience reproducing vision-language-action models as a running example. In one project, official trained weights were not available, so I had to train ACoT-VLA and π0.5 from scratch using the AgiBot challenge dataset and reconstruct the surrounding training and evaluation workflow. I’ll cover the parts of reproduction that papers often leave implicit: understanding an unfamiliar research codebase, reconstructing configurations, preparing datasets, debugging training instability and GPU memory problems, validating intermediate results, and distinguishing an implementation bug from an undocumented research assumption. I’ll also discuss reproducibility from an open-source engineering perspective: environment pinning, checkpoints, experiment metadata, deterministic evaluation, useful failure logs, and how researchers can structure repositories so another person can realistically reproduce their work months later. The goal is not to present another model architecture. It is to share a practical workflow for going from “this paper looks interesting” to “I can actually run, test, modify, and trust this system.” Attendees should leave with a repeatable approach for reproducing unfamiliar AI projects and a better sense of where ML reproducibility usually breaks in the real world.

Defense-by-Deception: Securing Web Authentication Endpoints Using Honeypots (Security)

• Sankalp Bansal

Room: Room 2 *"Keep your friends close, but your enemies closer."* That idea is the foundation of **HALT**. HALT is a modular web authentication security framework that I developed during my internship at **DRDO**. Authentication endpoints are one of the most common targets for attacks such as credential stuffing, brute-force attempts, password spraying, automated bots, and reconnaissance. HALT is designed to transform these endpoints from merely being an attack surface into valuable sources of threat intelligence. HALT evaluates every incoming authentication request in real time using request metadata, behavioral indicators, and configurable detection rules. Rather than immediately rejecting suspicious requests, it silently redirects high-risk users to a honeypot environment. This allows attackers to continue interacting with the system while their activity is monitored. These events can be visualized on a SOC dashboard or integrated with external logging and analysis platforms. In this talk, I will present the architecture behind HALT, explain how authentication requests are evaluated and redirected, and demonstrate the complete system in action. The session will show how cyber deception can transform a traditional login endpoint from a passive line of defense into an active source of threat intelligence. Project Repository: [The HALT Project (Github)][1] [1]: https://github.com/sankalp-b1401/the-halt-project

From First Commit to First Merge: Building a Contributor Pipeline for Open Source (Community)

• Ankit kumar Verma (WIKI (IIIT))

Room: Room 2 Getting a student to try open source is relatively easy. Getting them from “I installed the project” to “my first patch was merged” is much harder. Many university-led open-source programs lose contributors somewhere between setting up the development environment, making the first change, understanding the project's workflow, and receiving feedback through code review. The problem is often not motivation. New contributors need a clear path through the technical and social parts of an unfamiliar project. This talk shares what we learned from building that path through WikiClub Tech's Road to Wiki, a structured cohort program under The Open Knowledge Initiatives (OKI) at IIIT Hyderabad. Across two cohort cycles, the program has supported students in making 30+ merged production contributions to Wikimedia projects, including MediaWiki Core, Codex, WikiLambda, Huggle, and Parsoid. Cohort 2 is currently running across 12 partner colleges with 104 selected students, providing a larger test of the model. Rather than presenting a generic onboarding framework, the session will walk through the actual problems we encountered, what failed, what we changed, and what we now use to move students from their first local setup to upstream contribution. The talk will focus on three areas: Where the funnel breaks: Mapping the stages from application and environment setup to first commit, code review, merge, and continued participation, and identifying where students typically get stuck. How the cohort model works: Four practical mechanisms that have helped us improve the journey: a structured curriculum, peer-mentor sign-offs, a four-gate patch review process, and a train-the-trainer model that gradually shifts responsibility from program coordinators to community mentors. What we learned and what we are releasing: A post-mortem of Cohort 1, the changes introduced in Cohort 2, and an open-access CC BY-SA toolkit containing application rubrics, review gates, review matrices, milestones, and operational guidance that other university chapters and open-source communities can adapt. The methodology is also being adapted beyond Wikimedia. We are currently working on an Ubuntu-focused open-source curriculum in collaboration with Canonical's Developer Relations team, giving us an opportunity to test whether the same onboarding principles can work across different technologies and communities. The goal of the session is not to argue that one cohort model will solve open-source onboarding. It is to share a practical, tested framework that maintainers, community organisers, and university programs can adapt to make the path from first commit to first merge clearer and more repeatable.

Viewing Beyond MAD Landscape with my OSS Journey (Others)

• Sankalp Jha

Room: Room 1 I did my Google Summer of Code in 2025, and since then, I have been exploring the landscape of programmable networks. It is not something that is very mainstream tech, but definitely a next huge thing, especially with MAD Landscape , and that's why I am here to understand and talk about it to the people. We have been studying networks and that field, to us gamers and computer geeks, feels like having better ping, faster internet speed, hate latency, yes, we love all that good stuff. But when the same topic becomes a huge data centre, it becomes a crucial yet painful bottleneck, and thus, this field of networking has been on the rise, As mentioned previous i did gsoc in p4lang, based on Stanford California in which I made a custom machine learning framework deployable to little more complex to our NICs we got in our smart devices , it was Intel Tofino ASIC with the capabilities of commercial grade, so yeah i was working there and tackling its hw constraints and finally about to do machine learning inference whether incoming packets are malicous or benign in nature. Anyways, going more into programmable networks, I then switched to eBPF, i.e., extended berkley packet filter, where it provides custom filters at the kernel level, allowing direct daemon-level power, and is used in almost every service root. And as I got my taste there, I met Bill Muligan, a super cool guy from ebpf ecosystem, and since then, I have been contributing to one of Meta's eBPF repositories. And my talk is to motivate the generation to not get swallowed by AI psychosis and loop engineering, but rather find bottlenecks that will be pain and proactively resolve them, or rather RETHINK THEM(lakebed by Theo)! Yes, rethink how simple file structure works? Rethink why we are in the era of agents; we even take so long to build and deploy things. Why, Products like Jira could easily be out thrown by something build natively for agents?!

Can You Trust the Commit

• Shreya Shree

Room: Room 1 What the development process reveals when the code reveals nothing.

Closing Plenary (Others)

• Aveek Basu
• Till Kamppeter (OpenPrinting)