COSCUP 2026 - Conference for Open Source Coders, Users, and Promoters

這些年，各國政府都對人工智慧（ Artificial Intelligence，AI ）做出包含隱私保護、智慧財產權等諸多原則性指引，但實務上，多數國家都尚未對 Vibe coding 程式碼錯誤、代理型AI（AI Agent）指令錯誤、演算法偏誤、AI幻覺等問題的責任歸屬做好準備。

AI 因人而生，以程式碼為基礎，產出程式碼，為人服務，最終也應服膺於人與程式碼。那在這個嶄新的時代，各國政府是如何看待 AI 與人的關係，以及組成 AI 和 AI 產生的程式碼，在這場講座，我們將邀請各方專家學者為我們講述，也彼此辯論。

入職第五天，我拿到了 Claude Code ，開始試著和 AI 同事協作。
第八天，我決定為 AI 寫文件——不是以往的 README.md，是專門餵給 AI 讀的 LLM.md。
第十四天，我把第一個 PR 送出去，同事一看大量的新增檔案，當場傻眼。沒想到幾天後換我審他的 PR 的時候，發現他也開始寫 LLM.md，不只如此，他還寫了一份「文件的文件」，把整套做法立成規範。
這場分享，想講的就是這六十天裡發生的真實故事，以及我們意外發展出的「雙軌文件」玩法：
一份 README 給人類看，另一份 LLM.md 給 AI 看。兩份文件重視的內容完全不一樣。
從這個起點出發，我們一路延伸到架構規範、流程文件、設計 token 系統，慢慢拼出一套團隊能複製的方法論。

我會分享以下幾件事：
- 為什麼 AI 需要跟人類不一樣的文件？
- 雙軌文件怎麼設計、怎麼演化？
- 個人小習慣是如何變成團隊規範的？
- 以及這套做法真正的代價與限制

實踐來自一個 Kotlin / Android 團隊，但核心概念適用於任何 JVM 專案。

無論你是正準備把 AI 工具引入團隊，還是單純對「人跟 AI 一起寫程式」時的工程實踐感興趣，都歡迎來聽聽這段狂踩油門的經歷。

MySQL自前年四月將版本發行方式改為長期支持版(LTS)和創新版併行,並且推出了它的第一個LTS版,經過兩年MySQL 9.x創新版的累積新技和新功能,在今年4月推出了它的第二個LTS版 - MySQL 9.7,這個版本將享有8年的支援週期,這段期間9.7將持續提供更新版,而不會加新功能以保證應用系統在更新版之間的相容性,這追求系統穩定性的使用者而言,MySQL 9.7將是一個重要的里程碑-您可以安心的在8年內使用越來越穩定MySQL 9.7.
在這個分享中我將為各位介紹MySQL 9.7帶來的最新功能,以及MySQL長期支持版的使用者能由9.7版得到什麼效益.

MySQL is evolving its development process and community engagement. Oracle is shifting from a model where it primarily defined the roadmap internally and released the results as open source, toward a more open, community-oriented approach.

This session introduces MySQL’s Community Engagement Strategy and Community Roadmap, explaining how Oracle is working to expand the MySQL ecosystem by making roadmap discussions more transparent and encouraging broader participation from users, developers, DBAs, and contributors.

We will cover how the MySQL community can engage with the project through public discussions, feedback on bugs and feature requests. Attendees will learn how they can help shape the future of MySQL—not only as users of the database, but as active participants in its ongoing evolution.

從 DeepSeek 在 2025 年春節橫空出世以來，有關開源人工智慧的討論正式從技術與開源社群進入公眾視野。然而開源社群與人工智慧的發展其實比 DeepSeek 引發的討論更加深遠。有許多現在人工智慧技術仰賴的訓練架構以開源釋出，甚至開源社群與自由軟體的起源也與 MIT 的人工智慧實驗室相關。近期，開源人工智慧又因為主權 AI 的討論，而成為不同國家關注的焦點。在這樣的背景下，本議程將會聚焦在開源人工智慧的定義、風險討論與各國政策比較上。

首先，開源人工智慧所涵蓋的人工智慧技術究竟為何？只要公開模型程式碼，就可以稱作開源人工智慧了嗎？人工智慧的資料權重，甚至訓練的資料集是否要一併公開，才能算是開源人工智慧？各家大廠所宣稱的開源人工智慧真的是開源嗎？
其次，開源人工智慧由於其容易散布的特性，相較於閉源的人工智慧是否會產生新的風險？抑或是開源所帶來的透明度反而可以作為風險管理的手段與工具？
再者，各國對於開源人工智慧的態度為何？歐盟在《人工智慧法》中，明確規定以免費與開源方式釋出的人工智慧組件，可以不受該法規範。然而該豁免是否有例外與限制？美國政府對於開源人工智慧的態度為何，特別是在中美競爭逐漸蔓延到科技上的競逐，而中國在多款開源人工智慧模型的釋出均佔有主導地位時，美國會如何應對？新加坡對於開源人工智慧的政策又是如何？
以及最後，台灣可以從這些討論中，獲得什麼啟發呢？

實際導入 AI Agent 後，用起來常會發現：跑程式碼風格檢查、靜態分析、執行自動化流程等這些重複出現的開發任務，每次還是要靠自己下 Prompt。即便大型語言模型越來越能理解開發者的意圖，團隊的開發知識卻難以穩定、可攜帶且低成本地傳遞給 Agent。

這場分享將從開發者與 AI 協作的演進談起，說明為什麼 Agent Skill 會成為下一個值得 Kotlin 工程師投入的 Agent 協作工具鏈。Skill 可以把重複的流程、工具使用方式與團隊慣例，打包成可重複使用的能力，讓 Agent 在需要時才載入相關知識，減少 Token 浪費，也降低每次都重新教 AI 的成本。

接著，將以 Kotlin 開發者熟悉的情境，介紹 Skill 的基本架構設計、不同 Agent 與開發環境中的套用範圍和管理差異，並討論 Kotlin 開發生態中，有哪些開發知識及情境適合整理成 Skill。最後，會分享如何透過開源工具，讓 Skill 不再綁死在單一提供商、機器或專案，最大化 Skill 帶來的效益。

本演講將以講者親身與會經驗，系統性分享 UN Open Source Week 2026 中，聯合國和全球專家學者如何看待開放原始碼對於發展人工智慧與新興技術的助益。內容預計包含開放原始碼 × 人工智慧的國際共識、跨境協作治理框架、開源硬體與基礎建設趨勢、以及開放代理（Open Agents）的透明度與問責機制。同時，該大會預計也將為「數位合作的開放性」提出的普惠創新政策路徑——可謂是開放文化在數位時代的集大成。

當大家談到 RAG（Retrieval-Augmented Generation），第一個想到的儲存層往往是 Pinecone、Qdrant、Milvus，或是 PostgreSQL + pgvector。但是在絕大多數企業既有的 stack 裡，MySQL 才是那個「明明就在那裡、卻幾乎沒有人在 RAG 選型討論中提到」的角色。
MySQL 9.0 已經正式加入 VECTOR 資料型別。那麼問題來了：在不另外搬一座資料庫的前提下，到底能不能用 MySQL 把一個可運作的 RAG 系統做出來？做得起來、又能撐多久？
本場次以一個從零打造、完整開源的 demo 專案為主軸，帶聽眾一步步在 MySQL 9.x 上構建 RAG 系統：從 schema 設計、embedding 寫入、Top-K 相似度查詢，到串接 LLM 完成問答。途中會深入 VECTOR 型別的內部儲存方式、可用函式，以及目前最關鍵的限制——社群版尚未提供原生 ANN 索引。
接著，我們把同一份資料、同一組查詢搬到 PostgreSQL pgvector 上做對照組 benchmark，誠實呈現兩者在 latency、recall、開發體驗、維運成本上的差距。最後提出一個務實的選型決策框架：什麼情境下「在 MySQL 上做 RAG」是合理的工程選擇，什麼情境下應該果斷換工具。
所有 demo 程式碼、SQL schema、benchmark 腳本與投影片都會以 Apache-2.0 / CC BY-SA 授權公開於 GitHub，現場聽眾可以即時在自己的環境重現。

隨著大型語言模型（LLM）驅動的 Agents 逐漸走入自動化工作流，從履歷篩選、客服對話到商業決策等，Agent 的自主性在提升效率的同時，也悄然埋下了不同的偏見與歧視的風險。由於 Agent 具備推理與調用外部工具的能力，其偏見往往比單純的 LLM 更加隱蔽且具備行動力，如何有效地評估這些智慧體，成為構建可信 AI 的關鍵挑戰。

在此次將分享深入探討一套開源的 Agents 偏見檢測工具。我們將從技術角度解構 Agent 產生偏見的根源，並介紹如何透過自訂的知識庫與資料集來建立自動化基準測試，對 Agent 在特定情境下的是否有偏見的行為進行量化評估。

本次分享的核心內容包括：
- 偏見識別維度： 定義 Agent 在應用情境中的偏見樣態與基準調整。
- 評測工具架構： 介紹如何利用開源框架建構自動化測試腳本，模擬多樣化用戶輸入以誘發潛在偏見。
- 實戰案例分析： 展示該工具在實際場景（如徵才 Agent 或決策輔助 Agent）中的檢測成果。
- 緩解策略： 探討如何透過 Prompt Engineering 或約束層（Guardrails）在開發階段降低偏見風險。

我們希望透過開源工具，賦予開發者主動監測與修正 Agent 行為的能力。這不僅是一場技術分享，更是呼籲開源社群共同參與，為 AI 時代建立一道公平與透明的防火牆。

OCI 機制的信任度： OCI 新推出的「兩階段控制升級」與「近乎零停機維護」，在營運環境（Production）實際開刀時，大家敢不敢完全信任它的自動化？

How can open source strengthening democracy in practice?
This talk shares insights from CONSUL - a FOSS platform for citizen participation - in how instance implementations can make impact in supporting institutions and citizens worldwide, as well as the challenges of resource constraints, strategic prioritization and sustaining FOSS communities. We’ll also touch on how AI can enhance civic processes while remaining transparent and accountable.

As a concrete example of OSS development originating from the local community and based on Engineer Cafe, we will introduce a case study of a reception system open-sourcing project.

This project includes an "AI avatar" for reception navigation, utilizing modern technologies such as TypeScrip and LangGraph with long-term and short-term memory. We will share insights into the development process and problem-solving which is unique to the local community.

This talk session will be an opportunity to learn about a model case of how locally rooted OSS activities can connect to and contribute to the global ecosystem.
For the diverse participants of COSCUP, this will provide hints for their own local community activities and OSS development, as well as a platform for concrete interaction with Fukuoka OSS community.

市面上的 e-paper 模組大多依賴廠商提供的 SPI userspace 函式庫，且大多都是MCU的應用，無法與 Linux 標準顯示堆疊整合。更關鍵的是，這些模組的硬體設計和機構細節往往不透明，開發者只能被動接受。
open-ep 是一個「從硬體到內核全面開源」的社群。我們的 PixPaper 系列產品：

1. 硬體與機構自主設計
   - PCB layout、connector 選型、機構設計全部由社群完成，不依賴 ODM
2. DRM driver upstream
   - 已進入 mainline Linux kernel，並獲得 LWN.net 報導
   - 因為upstream審核很耗時, 我們也有在vendor kernel實做DRM driver
3. 多 OS 生態支援
   - 針對ARM Yocto BSP、Android AOSP、Ubuntu OS, freeRTOS 等不同系統特性擴充應用場景
4. 資安問題納入考慮
   - 加入BSP的應用，我們還是會考慮到SBOM的建置與CVE漏洞修補，以符合不同國家(如歐盟CRA)的軟體資安標準

軟體這不只是「把 driver 推進 kernel」，而是完整展示一個小規模社群如何：

從電路設計開始就考慮 mainline 相容性
與 kernel maintainer 溝通，讓 patch 順利進入 upstream
平衡「賣產品維持營運」與「推動開源標準化」的雙重目標
透過 COSCUP、UBUCON ASIA, OSPN Japan等技術社群建立信任

我們相信，硬體開源不只是「公開 schematic」，而是從設計階段就融入開源生態的思維。open-ep 想證明，即使是資源有限、需要自願貢獻者幫忙的社群，也能對 mainline Linux 和產業標準做出實質貢獻。

如果 AI agent 可以查支付資料、追金流、判讀客服案件，我們要如何知道它沒有帶著不可見的模型過濾、資料權限漏洞或不可稽核 workflow 在做決定？

本講分享 OEN 將 agents 導入 production payment infrastructure 的工程經驗：先用 Taiwan Sovereignty Benchmark 審計中文模型在台灣主權問題上的回答、過濾與 system prompt bypass；再用 payment-mcp + payment-skills 把 payment data access 與 charge lookup、phone trail、Twilio/SMS、payout failure diagnosis 等流程變成 scoped、logged、可 review、可 fork 的 artifacts。最後連回台灣 AI 資料利用法制：支持善意、可稽核、非替代市場的創新，但避免授權制度成為新資料壟斷。

Android 的圖形顯示架構主要是針對 HDMI、eDP、MIPI-DSI 等高效能顯示介面所設計。然而，在許多嵌入式系統中，仍然會使用像 SPI 這類較為特殊的顯示介面，而這些介面通常並不在 Android 標準顯示管線的主要支援範圍內。

本次演講將分享一個實際案例：如何在 ARM64 平台上，將一個基於 SPI 介面的自訂顯示驅動程式整合進 Android 14 的圖形顯示架構。該驅動程式是基於 Linux DRM（Direct Rendering Manager）框架實作，用於驅動一個透過 SPI 連接的小尺寸電子紙顯示器。

演講將以 RK3588 平台為實際案例，說明 Linux DRM 子系統與 Android graphics stack 之間的整合流程。我們會解析 SurfaceFlinger、Hardware Composer（HWC3）與 DRM/KMS 之間的互動關係，以及在 Android 系統中導入非標準顯示裝置時可能遇到的各種挑戰。

如果你和我一樣同時訂閱了 Claude Code、Gemini、Codex, 不同任務想用不同的 Agent CLI,但每次切換就要手動搬運專案上下文、複製程式碼、重新解釋需求, 工作流支離破碎。訂閱費繳得不少,實際使用體驗卻像在三個分身之間當客服。
後來發現了 Spring AI Agent Client 這個 Spring AI Community 在 2025 才釋出的新專案，可以在 Java 端統一編排多家 AI Agent 的方案，它把 Claude Code、Gemini、Codex、Amazon Q 等 CLI Agent 抽象成同一套介面,就像當年 ChatClient 統一了各家 LLM API 一樣。
如果你也有類似困擾可以參考看看

電子紙（E-paper）憑藉著超低功耗與護眼特性，在物聯網設備與自造者專案中大受歡迎。然而，開發者往往面臨一個巨大的痛點：「驅動程式極度碎片化」。市面上常見的電子紙模組（如 Waveshare 系列），即使尺寸相同，內部控制晶片與初始化指令也可能完全不同，導致開發者經常需要重複造輪子，難以將程式碼跨型號移植。

本議程將分享如何打造一套跨型號的電子紙通用 API。透過建立完善的硬體抽象層（HAL），開發者只需撰寫一次程式碼，即可無縫適配多款不同型號的電子紙模組，大幅降低開發與維護成本。

此外，本議程的另一大技術亮點是「灰階功能的逆向與實作」。許多平價電子紙模組在官方預設下僅支援純黑白顯示，我們將深入探討電子紙的刷新原理，解析如何透過控制硬體波形（Waveform LUT）或演算法，突破硬體原廠限制，在通用 API 的架構下成功榨出平滑的灰階顯示效果。

這套解決方案目前已實作於 [ESP32 / Arduino / stm32 / Rpi / Rpi pico] 平台，並以 [ C ] 開源。無論你是深受電子紙驅動折磨的 Maker，還是對底層波形控制感興趣的開發者，都能在這場議程中獲得實用的解法與啟發。

當 AI 讓業務端也能快速做出系統時，企業或公民科技社群要怎麼定義邊界、責任與收編機制。
AI 公民開發該鼓勵創新，還是優先納管？
收編還是放生？企業如何面對 AI 自發開發潮
AI 生成系統進企業後，資訊部門是加速器還是防火牆？
公民科技社群的氛圍產物像是美麗煙火，天亮後我們的未來。

ePaper displays are an ideal solution for always-on low power smart home interfaces, offering excellent readability and near zero energy consumption when static. In this session, we show how makers can build their own smart home displays using ESP32 based XIAO modules and the Arduino ecosystem.

Starting from the basics, you will learn how to interface a 4.2" monochrome ePaper display driven by the SSD1680 controller using the open source Seeed GFX Library. The presentation covers hardware comparison of the XIAO ePaper Display breakout boards and explains their differences and typical use cases. The session demonstrates how to render dynamic content such as sensor data, home automation status information, and custom dashboards while optimizing for low power operation. By the end, you will have a practical foundation for building your own battery powered smart home displays suitable for digital signage, room dashboards, and portable information panels.

This talk is suitable for everyone and no previous experience is required. It will be hopefully useful both for engineers and makers who are interested in using ePaper displays in their projects, whether they are just getting started or looking to expand their existing skills.

你有沒有想過，你可以用 Kotlin「發明」一門小語言？

DSL 簡單來說，就是利用各種語法特性，讓你在設計函式、物件、lambda 時，雖然寫的還是合法的 Kotlin，卻能讓使用者感覺像是在使用一門為特定問題量身打造的語言。

本 Workshop 將帶你從零開始，用 Kotlin 打造一個文字冒險遊戲的腳本 DSL。從最樸素的 Builder 出發，一步步引入其他語法，最終設計出一個可讀性極高、可直接描述房間、劇情與選項的 Kotlin DSL。

結束後你不只學到 DSL 怎麼做，更能看懂其他 DSL 背後共同的設計哲學——那些你每天在用的框架，其實都是同一套思路打造的。

【目標聽眾】
本演講適合關心公民科技（Civic Tech）、政府科技（GovTech）、流程自動化，以及對公私協力推動體制數位轉型感興趣的開發者與推廣者。

【痛點與背景】
公部門（特別是偏鄉單位）常面臨人力吃緊的挑戰。臺東縣消防局每年需處理密集的消防安全設備紙本申報、稽核與複查排程，繁瑣且重複的行政負擔極大地排擠了前線搜救與訓練的精力。

【解法與開源實踐】
為了解決此痛點，臺東縣消防局積極導入數位發展部「公民科技試驗場域」計畫，與公民科技團隊度合作，成功開發出「申報自動排程系統」。本專案將原本繁瑣的公務行政流轉化為智慧化自動排程演算法，落實公私協力與開源共好精神。

【議程大綱 (30分鐘)】
- [00-05m] 偏鄉消防的數位痛點：當有限人力遇上每年萬件申報案
- [05-15m] 流程智慧化：自動排程系統的架構設計、法規邏輯轉化與開源協作
- [15-25m] 落地成果與踩坑經驗：Civic Tech 團隊與公部門跨域溝通的淚與笑
- [25-30m] Q&A 與未來展望：如何複製此模式至更多公共服務場域

This session is about speeding up embedded bring-up for the Jaguar EInk Display: colour e-paper on NXP i.MX93 SOC with Yocto / OpenEmbedded customisation, plus a Zephyr-based companion chip for power management—targeting 5+ years operation with the PMU approach for realistic scheduled static signage workloads.

The Linux side display and controller integration are implemented as a Rust userspace application on the Linux image—code people often call a “driver,” but here it is userspace engineering, iterated like any other critical service.

The focus is agentic AI (e.g. Cursor-class agents) and how it changes the loop when you feed it real hardware feedback. I will describe a workflow we relied on: SSH to boards (including remote lab setups), automated deploy of rebuilt artefacts, and webcam capture of what is actually on the panel—fed back into the agent loop so “what we think we programmed” is checked against what appears on hardware. That closes the gap between compile-only optimism and hardware truth.

I will cover partitioning between Linux + Rust app and Zephyr on the PMU at an architectural level (rail sequencing, sleep/wake, responsibilities). PMU application firmware remains closed source; I will not present proprietary files—only the integration surface, debug strategy, and lessons that remain useful when part of the stack is private.

The product direction includes long-life maintenance thinking aligned with UK-CE RED and EU CRA expectations around secure boot and OTA—discussed technically, not as legal advice.

Open artefacts

• meta-dynamicdevices
• eink-power-cli
• esp-eink (older open e-paper reference material)

Audience

Embedded / Linux developers; Rust curiosity helps; deep kernel internals not required.

Outline (30 minutes)

1. Goals and architecture (Linux + eink display rust app + Zephyr PMU)
2. Yocto customisation highlights using Foundries.io stack for secure boot and OTAU
3. Agentic workflow (SSH, deploy, logs)
4. Webcam-in-the-loop verification for panel outcomes
5. Failures and guardrails; Q&A (Open-EP collaboration themes)

Takeaways

• A repeatable pattern for remote hardware feedback loops with agents
• Pointers to public repos

Related

• Prior talk (agentic Yocto-era workflows): Yocto Project Summit 2025.12
• Product framing: etablone

AI 時代下，勞動市場正面臨快速且深刻的職能轉變。然而求職網站的大量非結構化資料，以及分散於各處的政府開放資料，往往使一般公民與社會科學研究者難以即時掌握勞動市場變化。

本議程將分享如何運用開源視覺化自動化工具 n8n，結合大型語言模型（Large Language Model, LLM），打造一套「勞動觀測站」。透過將傳統社會科學研究流程「Public Code」，將展示如何建立一套能夠自動爬梳、整理、分析並視覺化勞動市場趨勢的資料管線（Data Pipeline）。

在此架構中，系統進一步建立自動化風險指標（Automation Risk Index），以量化 AI 對不同年資、職能與產業勞工所帶來的潛在衝擊。這套方法不僅助於即時追蹤各產業的技能漂移（Skill Drift）現象，也能降低公民參與數位政策研究與勞動市場分析的技術門檻，實踐科技賦能社群與開放知識共享的理念。

Many embedded display systems rely on tightly coupled firmware or vendor-specific tooling, making it difficult to integrate with desktop applications or iterate quickly on UI workflows.

In this talk, I will present a practical end-to-end pipeline for streaming images from a host computer to an embedded LCD display, At its core is running open-source Zephyr RTOS. The system uses a custom USB protocol transfers, enabling efficient and flexible communication between a PC-side application (implemented in C#).

I will walk through the system architecture, including USB protocol design, framebuffer handling, and integration with Zephyr’s display API, along with practical development experiences such as debugging, transfer performance, and reliability considerations, and approaches that can also be extended to lower-power display technologies such as e-paper systems.

The talk focuses on reusable design approaches and avoids proprietary implementation details. Attendees will gain a reusable model for building similar host-to-device display pipelines in their own projects.

Software Defined Vehicles (SDVs) mark a significant evolution in the automotive industry, shifting the focus from traditionally hardware-centric designs to software-driven systems. Earlier, automotive systems were built using a hardware-first approach; today, vehicles are increasingly powered by complex, software-based solutions.

Several open-source alliances—such as AGL, ELISA, SOAFEE, Eclipse, COVESA, Autosar, and others—are uniting to accelerate the development of SDVs. In this session, we will provide an overview of these initiatives, explaining how these alliances are shaping the future of automotive technology.

In particular, the AGL SDV Expert Group is at the forefront of this movement, committed to developing common SDV platforms through open-source collaboration. As the leader of this group, the speaker will share the group’s vision, roadmap, and detailed activities, offering a closer look at AGL’s efforts in the SDV space.

This presentation is designed to initiate collaboration between the automotive open-source community and COSCUP attendees, and will be conducted in both English and Chinese.

flutter_gemma started as a thin wrapper over MediaPipe for running Google Gemma on Android and iOS. Today it's a full-fledged platform for on-device AI: 6 platforms (Android, iOS, Web, macOS, Windows, Linux), 2 inference engines, multimodal support, function calling for local agents, and on-device RAG with vector search. The plugin has been featured by Google AI for Developers.
In this talk, we'll walk through the evolution via key engineering decisions. How adding Web platform forced us to rethink file handling and led to sealed classes instead of string URLs. Why we had to spin up a gRPC server in Kotlin with a bundled JVM for desktop — and how to automate the build through Xcode build phases. How the Strategy pattern allowed us to add a second inference engine (LiteRT-LM) without rewriting existing code, and how the Adapter pattern helped reuse the MediaPipe implementation. Why we needed chunk buffering for engines with fundamentally different APIs.
We'll dive deep into on-device RAG: how to build a SQLite VectorStore that works identically on mobile and in the browser via WASM. I'll show real bugs and their fixes — from Web hot restart crashes to iOS Simulator limitations with vision models.
The latest addition is genkit_flutter_gemma — a bridge to Google's Genkit for Dart that enables hybrid AI pipelines. Now you can seamlessly combine on-device inference with cloud-based models in a single Genkit flow: run lightweight tasks locally for speed and privacy, and escalate complex reasoning to the cloud — all orchestrated through one unified pipeline.
Every architectural decision in flutter_gemma is an answer to a specific problem. Minimum theory, maximum code, diagrams, and stories of "how it broke and why it looks like this now".

Automotive Grade Linux (AGL) is a collaborative open source project hosted by the Linux Foundation, building a common Linux-based software platform for automotive systems. This session introduces AGL through its recent evolution. After a brief overview of the project and its community, the talk highlights key updates from the past year to show how AGL is expanding beyond its original scope.

Two initiatives illustrate this direction. SoDeV (Software Defined Vehicle reference platform) explores software-first development through virtualization and hardware abstraction, improving portability and enabling experimentation across environments by leveraging promising open source projects such as Xen, Zephyr, and VirtIO. AGL Assessment Automation (AAA) applies modern open source security and supply-chain practices—originating in the cloud-native ecosystem—to large and complex automotive supply chains, addressing challenges common across embedded systems industries worldwide.

Rather than focusing on industry-specific use cases, the session emphasizes the technical ideas and open source practices behind these efforts, and concludes with a look at where AGL is heading and how developers can get involved.

這幾年大家都在談 Multi-Agent，但從「LangGraph 寫範例」到「真的部署在雲端、用戶端跑得起來」之間，差了一整個 production gap。

這場 talk 會以開源專案 jimmyliao/digest-agent (MIT) 為主軸，分享一個從 Streamlit MVP 升級成 Next.js + ADK Multi-Agent 的完整改造旅程，重點放在架構決策：

1. 為什麼選 Google ADK 而不是自寫 orchestration
2. Gemini Enterprise Agent Platform (GEAP) 跟 Cloud Run 的職責切分

現場會 demo 一個跑在 Gemini Enterprise Agent Engine 上的即時 multi-agent 分析串流。

In this talk Flo will introduce the Eclipse Foundation which has started a Software Defined Vehicle Working Group. Members like Mercedes, Cariad, Bosch, Continental, and many others are already working together on a fully open source and commercially usable SDV Software layer, enabling faster innovation and reusability of base blocks. We will introduce the Eclipse SDV initiative and why this open source approach will help the worldwide car industry to enable the Software Defined Vehicle. We will highlight the achievements of this young initiative as well as critically asking why open source may not be enough to make this worldwide collaboration happen.

Google 推出 Gemma 4 的時候附了 model card 和 safety benchmark，但那些數字是 Google 自己測的。如果你用 OWASP LLM Top 10 的標準，從攻擊者視角重新掃一遍，結果會一樣嗎？
這場議程分享我們在 NVIDIA DGX Spark GB10 和 Mac mini M4（MLX）上對 Gemma 4 26B 進行紅隊掃描的完整過程與結果。我們用 OpenClaw 攻擊鏈逐項測試 OWASP LLM Top 10 的風險項目，包括 Prompt Injection（LLM01：7 項測試通過 5 項）、Visual Prompt Injection（3 項測試確認 2 項弱點），以及其他類別的實測數據。
你會看到的不是理論分析，而是一份有具體 pass/fail 的成績單。我們會拆解每一項測試的攻擊手法、Gemma 4 的實際反應、以及哪些弱點可以用 NemoClaw Guardrail 補強。
這場的目標不是說 Gemma 4 不安全，而是讓每一個用開源模型的開發者知道：model card 上沒寫的風險，你要自己測。我們會開源測試腳本，讓你對任何開源 LLM 跑同樣的弱掃流程。

The SoDeV is an open-source reference Software Defined Vehicle (SDV) platform. It's developed by the Automotive Grade Linux (AGL) SoDev project. It aims to de-fact standard for the SDV platform.
The SoDeV platform is built on a hypervisor-based host environment and hardware decoupled guest VMs with Virt IO infrastructures. The example of those guest VMs are AOSP, AGL In Vehicle Infotainment(IVI), Instrument Cluster (IC), gateway, real-time Linux-based runtime environment and RTOS-based runtime environment.
From our point of view, "reproducible" is a high-priority topic. From the SoDeV developer's point of view, we need a method for the same environment creation to share the common development environment. From the SoDeV user point of view, we need to reproduce the SoDeV platform in our own environment to evaluate, modify and more.
The AGL has a common reproducible integration tool called Yocto. It already has a host and guest co-build method called multiconfig. On the other hand, that requires complex configuration. It's a big barrier for the SoDeV developer and user.
In this session, I'm talking about an idea for how to fix this issue. This talk includes my investigation, trial and consideration. It's common knowledge outside the automotive field. Because the same issue exists in IoT, Industrial and other fields.

Mobile UI development has already moved toward a declarative paradigm, but haptic feedback is still often handled through imperative, platform-specific APIs. On Android, developers need to work with timing and amplitude arrays, while iOS requires a different approach through Core Haptics. As a result, expressing even a simple vibration pattern can quickly become difficult to read, maintain, and reuse across platforms.
In this session, I'll introduce Jindong(진동, Vibration), a declarative haptic feedback library for Compose Multiplatform. Jindong lets developers describe haptic patterns using a Compose-like DSL with concepts such as Haptic, Delay, and Sequence, while the library handles platform-specific execution details for Android and iOS.
We will look at the motivation behind declarative haptics, how Jindong integrates with Compose state and lifecycle, and how this approach can make haptic feedback more expressive, reusable, and aligned with modern Compose development.

Software-Defined Vehicle (SDV) requires multiple domains—such as infotainment, instrument clusters, real-time ADAS functions, and AI features —to coexist safely on a single hardware platform. Achieving this requires strong isolation, making virtualization essential. A traditional software coupled with hardware loses software portability. Hardware decoupling is a crucial aspect in the SDV era.　While multiple approaches exist, this talk focuses on hypervisors, with Xen emerging as a key technology for isolation and hardware decoupling.
However, automotive hypervisors have traditionally relied on commercial solutions, and applying an open-source hypervisor like Xen introduces challenges—especially on ARM platforms. These include BSP dependencies, complex boot flows, Device Tree configuration, memory constraints, and virtio-based device design.
In this talk, we present a real-world hardware implementation combining Xen, Automotive Grade Linux (AGL), and Zephyr RTOS on ARM. We share practical integration issues and solutions, and demonstrate how virtio enables device abstraction and hardware decoupling.

近年 AI coding assistant 快速發展，但對許多開發者來說，真正困難的問題仍然是：

不知道該從哪開始
文件太多看不完
webhook/debug 很難排查
sample code 不知道如何修改

在這場分享中，我們將以「LINE Bot 開發學習流程」為案例，探討 AI 如何改善 Developer Experience。

我們結合：

Gemini
MCP Server
Antigravity CLI
LINE 官方文件

打造一個能協助開發者學習與開發 LINE Bot 的 Developer Assistant。

除了介紹技術架構外，我們也會分享：

AI 如何改變開發者 onboarding
Developer Relations 在 AI 時代的新挑戰
怎麼讓 AI 不只是產生 code，而是真正幫助開發者理解與學習

最後也會現場 demo：
從零開始透過 AI 建立一個 LINE Bot workflow。

In Software-Defined Vehicle (SDV) architectures, virtualization is an important technique for isolating software functions. SoDeV, an SDV platform being developed by Automotive Grade Linux, uses Xen for virtualization. In Xen, a Driver Domain (DomD) owns physical devices and provides para-virtualized interfaces to other domains. Zephyr is a good fit for this role because it combines broad device support with a small footprint, enabling compact and well-isolated driver domains.

In this session, we will present our work on running Zephyr as a Xen driver domain, including current upstream progress. We will explain why smaller Zephyr-based driver domains are attractive, and discuss practical challenges that appear in real systems, such as partitioning hardware cleanly across domains, handling shared resources like clock control, and dealing with the associated challenges on the Xen side.
We will also demonstrate Zephyr’s DomD support live—expected to be upstream by the time of the session—on the Renesas/Retronik Sparrow-Hawk V4H Board and Raspberry Pi 5.

Through this demonstration and discussion, attendees will see what is already working today, what benefits this approach can bring, and how the ideas may be applied in their own projects. We also hope to share the remaining open challenges with the community and encourage discussion on how Zephyr-based driver domains can grow into a practical open-source building block for future SDV systems.

For OSS to fulfill its potential in Automotive, the industry must learn from past mistakes and successes, then chart a more strategic course forward. The author brings experience of applying OSS to real-world vehicles from 3 OEM projects, including V2X IoT infotainment system and data-closed loop platform across vehicle and cloud.
In this talk, the author shares lessons learned from the painful deployment process of the open-source SDV projects. It starts from a practical experience of in-vehicle performance tuning, to process signals of the whole vehicle (> 10,000) while only consuming below 2K DMIPS. It also unveils the methodologies for trigger-to-upload and transmission prioritization, ensuring guaranteed safety-related data delivery in remote diagnostic services, even under poor network conditions. This also covers topics of CI/CD of OSS in mission-critical scenarios, by showcasing a story of building an in-vehicle real-time tracing feature for log and network packets. It serves as a workflow tool for better collaboration with other vendors, to escape from the blame game.
The session also gives an example of leveraging fuzzing technology to actively prevent intrusion.