Explore Projects

The mediapipe-rs project provides a Rust SDK to support mediapipe AI models. The SDK provides utility functions to pre-process application data (such as images, audio and video) into TFLite / PyTorch formats, and convert the inference results back into application data. In order to accomplish this, the [mediapipe-rs](https://github.com/WasmEdge/mediapipe-rs) project has made extensive use of the [ffmpeg](https://www.ffmpeg.org/) library. It [compiles ffmpeg to Wasm](https://github.com/WasmEdge/mediapipe-rs/blob/main/src/build.rs) and then builds it together with the application binary. However, the issue with this approach is that those Wasm-compiled ffmpeg functions are slow. We believe a better approach is to create a ffmpeg plugin for WasmEdge, and allow Wasm applications to call native ffmpeg functions as host functions. - Expected Outcome: - The deliverables will be - A WasmEdge plugin for ffmpeg that is similar to the [WasmEdge OpenCV-mini plugin](https://github.com/WasmEdge/WasmEdge/tree/master/plugins/wasmedge_opencvmini). That is to re-export ffmpeg functions in C style as plugin functions as covered in the [plugin developer guide](https://wasmedge.org/docs/category/wasmedge-plugin-system). - A Rust SDK for Wasm programs to access ffmpeg functions in the plugin. Similar to the [WasmEdge OpenCV-mini SDK](https://github.com/second-state/opencvmini) - Refactor the mediapipe-rs project to use the ffmpeg plugin

This project intends to propose a solution to this real-world problem, and it is research-focused. The goal is to give a strong contribution to the Hyperledger ecosystem in terms of the state of the art in blockchain interoperability. Some questions that this project aims to answer are: How can we interoperate Hyperledger technologies with other blockchains?, How can Hyperledger initiatives position themselves to tackle blockchain interoperability?, What standards we require to define middleware between blockchains? What are the consequences of employing smart contracts with external processes and data (the external part means another connected blockchain)?, The key to the survivability of this technology? In other to try to answer those questions, in this project the mentee(s) will start by studying some of the most prominent blockchain interoperability solutions already available or being proposed, and how they can be used to promote and strengthen Hyperledger technologies. Then, the mentee will design and develop a framework for creating, deploying and maintaining services with several blockchains. The applicability of the solution to be proposed is to be demonstrated through the exploration of a use case, implementing several blockchains (including Hyperledger Fabric) to increase the dependability of blockchain-powered services administrated by several stakeholders, serving as a proof-of-concept.

Develop content for Notary documentation and write blog posts to educate users about the Notary use cases. Write user guides, contributing guides, and developer guides for every new Notary release and keep those content up-to-date. - Expected Outcome: - Write user guides with end-to-end scenarios based on given doc structure and requirement - Write contributing guides and developer guides, ensure new developers can easily build and start contributing to Notary subprojects - Write blog posts to educate users to use Notation with cloud-native ecosystem tools

Knative enables serverless on Kubernetes (scale-to-zero, traffic splitting). This project finishes and polishes a Headlamp plugin so operators can **view, inspect, and manage Knative Services, Revisions, Configurations, and Routes** from Headlamp, complementing the `kn` CLI. Builds on an existing plugin. Expected Outcome: - Fully functional Knative plugin: in the Headlamp repo with a "Knative" sidebar. List KServices across namespaces with key columns (name, URL, traffic %, latest revision status) matching existing tools. - Service detail pages: showing URL, traffic split, concurrency/scaling, conditions; UI actions to adjust traffic, edit config/env/concurrency, and trigger redeploys via forms/modals with feedback and RBAC checks. - Related resources: list/link Revisions, Configurations, HTTPRoute/Knative Route; optional read-only revision/config views. - Headlamp-consistent UX: Map/metrics integration, bug fixes, basic tests, packaged metadata, ArtifactHub releases, README, and a kubernetes blog post with a short demo.

In a previous LFX mentorship project (https://github.com/WasmEdge/WasmEdge/issues/3495), we have created an LLM-based coding assistant grounded in Rust programming language skills (https://huggingface.co/datasets/gaianet/learn-rust). We aim to further improve the Rust coding assistant by incorporating inference-time compute that utilizes the Rust compiler for feedback. One of the greatest advantages of Rust is its powerful and strict compiler, and the detailed error message generated by the compiler. The Rust compiler could give valuable feedbacks to code generating LLMs to improve the code quality. Expected Outcome: 1. Run a Qwen Coder 2.5 LLM locally (https://github.com/GaiaNet-AI/node-configs/tree/main/qwen-2.5-coder-7b-instruct) or access it via an API. 2. Create an LLM system prompt that describes the structure and key elements of a cargo project. It will guide the LLM to generate multiple files (artifacts) for a complete project. 3. Create a Python program to send user requests to the LLM and parse the generated result into locally cached files. 4. Use a local Rust compiler to build the generated project. Sends the error messages back to the LLM to re-generate. 5. Iterate until there is no more errors. 6. Build a web API for the Python program that takes OpenAI compatible requests and return OpenAI compatible results.

Distributed transactional key-value database, originally created to complement TiDB.

In the current KubeSlice design, IP address management (IPAM) for slice overlay networks is static and inefficient. A predefined CIDR block (e.g., 10.1.0.0/16) is divided into a fixed number of subnets regardless of how many clusters participate in the slice, leading to significant IP space wastage. This project aims to implement a dynamic IPAM system that allocates IP subnets to clusters on demand and reclaims unused ranges when clusters leave the slice. It will ensure efficient address utilization, synchronization across clusters, and integration with the KubeSlice control plane. Expected Outcome: 1. A dynamic IPAM allocator integrated with the KubeSlice controller or sidecar component. 2. Support for on-demand IP allocation and subnet reclamation when clusters join or leave a slice. 3. Conflict resolution and state synchronization across clusters using CRDs or distributed storage. 4. Documentation on how the system works, configuration options, and edge case behaviour.

As industrial manufacturing accelerates its digital transformation through advancements in robotics, adaptive production lines, and smart testing systems, cloud-edge collaboration has emerged as a critical enabler for deploying embodied intelligence in complex operational environments. Contemporary industry requirements for embodied intelligence now extend beyond basic task execution to encompass multimodal perception and decision integration, dynamic environment adaptation, and distributed device orchestration. Existing benchmarking frameworks exhibit limitations in evaluating scenario-specific embodied attributes inherent to industrial settings. This initiative leverages the KubeEdge-Ianvs collaborative AI framework, integrating domain-specific test datasets, simulation environments, and quantitative metrics to establish a certified industrial-grade evaluation infrastructure for embodied intelligence systems. Expected Outcome: 1. Develop an industrial-grade embodied intelligence dataset through systematic classification and reorganization of existing resources/ examples 2. Deploy baseline algorithms and introduce metrics to establish performance benchmarks within KubeEdge-Ianvs

Hyperledger Cactus is a blockchain decentralised integration tool designed to allow users to securely integrate different blockchains started by companies Fujitsu and Accenture. Cactus has pluggable architecture which makes easy to integrate various blockchain by creating plugin, currently plugins for Fabric, Besu, Quorum are implemented. Cactus allows to transfer not only assets but also data between multiple blockchains. Hedera Hashgraph is a DLT built on top of an asynchronous BFT algorithm, providing smart contract, token, and consensus services to end users. The flexibility - Document ready-to-use integration of Hedera and Cactu, - Document example of integration using Hedera's Testnet and Hedera's Previewnet - Document example of integration between another blockchain and Hedera using Cactus

Harbor is a popular and widely adopted container registry. We have developed an initial CLI (https://github.com/goharbor/harbor-cli) that we would like to extend and implement additional functionality, and common workflows that are currently only present in the Web UI. We are seeking a Golangs experienced manatee who can work on the project independently. - Expected Outcome: Working Golang Harbor CLI which can be used in the CI/CD implementations that compliment the Web UI covering the typical workflows of Harbor administrators and users. Familiarity with Golang library spf13/cobra and REST/Open API. Well-documented CLI that users love to use, and with the corresponding architectural diagrams under the Harbor. Working CI/CD with GitHub actions that create multi architecture binaries and containers.

Jaeger is an open-source, distributed tracing platform designed to monitor and troubleshoot microservices-based systems. A critical component of Jaeger is its storage backends, where traces captured by Jaeger are stored. With the release of Jaeger v2 last year we introduced a new, more efficient Storage API v2. However, the existing backend implementations in Jaeger are still using v1 API that is only wrapped in the v2 adapter, which prevents them from benefiting from the new capabilities such as batch writes and result streaming. The objective of this project is to upgrade some (or all) backend implementations to use the Storage API v2 natively. Please refer to the upstream issue for more details. Expected Outcome: 1) Upgrade memory and Elasticsearch backends to use the Storage API v2 natively. 2) Bonus: upgrade Cassandra and Badger backends to use the Storage API v2 natively.

Meshery's highly dynamic infrastructure configuration capabilities require real-time evaluation of complex policies. Policies of various types and with a high number of parameters need to be evaluted client-side. With policies expressed in Rego, the goal of this project is to incorporate use of the https://github.com/open-policy-agent/golang-opa-wasm project into Meshery UI, so that a powerful, real-time user experience is possible.

KubeSlice currently uses a full-mesh topology for the slice overlay network, where every cluster connects to every other cluster in the slice. This results in unnecessary tunnel creation and resource consumption. This project proposes a topology-aware design, allowing users to define custom connectivity matrices for slices. Users can specify partial meshes. Additionally, the project will support configuring each cluster's VPN deployment type (client/server) to accommodate network constraints such as firewalls or NAT. Expected Outcome: 1. Extension of the Slice CRD to support custom topology and VPN role definitions. 2. Logic to establish tunnels based only on the defined connectivity matrix. 3. Support for various deployment topologies (full-mesh, partial mesh, hub-spoke). 4. Sample configurations and documentation on how to define and validate topologies.

Cluster API (CAPI) provides declarative APIs and tooling to provision, upgrade, and operate Kubernetes clusters. This project continues an existing Headlamp plugin to deliver first-class UI support for CAPI resources (Clusters, Machines, MachineDeployments, KubeadmControlPlanes). The plugin will let operators discover, inspect, and manage cluster lifecycle objects in Headlamp, visualizing hierarchical relationships and closing gaps in the plugin. Expected Outcome: - Sidebar and Map: List key CAPI CRs in the sidebar and Map view; show Clusters with Machines, MachineSets/Deployments, and control planes. - Resource details: Dedicated pages with CAPI-specific fields (conditions, infra refs, provider info, control plane refs, node pools, cluster membership, provider status). - UI integration: Map visualization, sidebar icons, on-hover "Glance" tooltips. - Robustness and tests: Fix runtime errors, human-friendly fields (e.g., "2d5h"), add automated tests. - Polish and delivery: Refined tables, icons, clickable "Controlled by" links; packaged in Headlamp’s plugin repo with install and developer docs; Kubernetes Blog post showcasing benefits.

OPNFV VSPERF already includes comprehensive Monitoring solution. However, it lacks the Log-Analysis and Alert-Management solution. This project aims to include log and alert management solutions based on opensources - ELK Stack. This will enhance the ability of VSPERF to: 1. Perform post-test correlation/causation analysis. 2. Adapt the Test-Traffic patterns based on the Alerts. The first aim is to create custom kibana dashboard analyzing and synthesizing VSPERF logs/events. For every test-run, VSPERF generates following logs: 1. vsperf-overall 2. vswitchd 3. trafficgen 4. host-cmds 5. guest-cmds These logs have useful information that can help user to understand the test behavior, and analyze the performance results. VSPERF will have Alerting from the Monitoring component, and lacks alerting from the logs. As the next step, this project aims to use the same information - The logs - and create alerts than will be notified to VSPERF.

<p>Currently, urunc launches sandbox monitors, such as Firecracker and QEMU</p><p>through command-line invocations. This approach offers limited control over the</p><p>sandbox lifecycle once the process is started. On the other hand, most</p><p>monitors expose remote management interfaces, typically through a socket-based</p><p>API.</p><p><br></p><p>These interfaces provide access to the same operations currently performed via</p><p>CLI, but also enable further control over the sandbox lifecycle. In particular,</p><p>they allow more fine-grained lifecycle management of the sandbox, including</p><p>querying and monitoring its state, performing device hotplug and unplug</p><p>operations and interacting with the guest.</p><p><br></p><p>This project aims to extend urunc's sandbox integration layer to support remote</p><p>management interfaces and to explore each monitor's capabilities in order to</p><p>extend the functionalities of urunc sandboxed containers.</p><p><br></p><p>Expected Outcome:</p><p>&nbsp;- A design document describing the updated architecture and workflow for</p><p>&nbsp;&nbsp;spawning and managing sandbox monitors in urunc.</p><p>&nbsp;- Implementation of the necessary changes in urunc to manage sandbox monitors</p><p>&nbsp;&nbsp;through their respective APIs.</p>

The component-model proposal merges and supersedes the Module Linking and Interface Types proposals. With this feature, WasmEdge can execute multiple modules wasm with Module Linking and and more flexible types with Interface Type.

<p>Ianvs serves as the KubeEdge SIG AI distributed benchmark toolkit. As more and more contributors running, KubeEdge Ianvs now has up to 30 examples, and the number is still increasing. KubeEdge Ianvs then faces mounting usability issues due to dependency evolution and validation mechanisms. As Python versions, third-party libraries, and Ianvs features advance, partial historical examples fail to execute. This has led to surging user-reported Issues from confused contributors, untested PRs breaking core functionality of legacy features, and severely outdated documentation misaligning with actual capabilities. Without systematic intervention, the example risks becoming obsolete for edge-AI developers and especially newcomers. We then try to resurrect Ianvs’ usability with a comprehensive example restoration.</p><p><br></p><p>Expected Outcome:</p><p>&nbsp;- Diagnose &amp; fix bugs across examples, including dependency manifests, license scan, and runtime configurations.</p><p>&nbsp;- Documentation Modernization, including revamp tutorials with reproducible step-by-step guides, publish developer-focused debugging playbooks for common failures. Write and upload the corresponding blog to the KubeEdge Website.</p><p>&nbsp;- Advanced: Build a CI pipeline testing examples with GitHub Actions against multiple Python versions, critical Ianvs/upstream updates, and block PRs that break validated examples</p><p><br></p>

All In is a community dedicated to advancing diversity, equity, and inclusion within open source. All In for Students is a paid, 12-month program for select college students from underrepresented backgrounds. During the program, students will receive professional development training, open source education, a structured 12-week open source project, and ultimately have the opportunity to join one of our corporate partners for a summer internship experience.

Envoy is an open source edge and service proxy, designed for cloud-native applications.

FINOS (FinTech Open Source Foundation - part of the Linux Foundation) is looking for a summer marketing intern to assist with: - Marketing research (members, projects, BD) - Social media (research, operations) - Content for website (research, operations) - Podcast production (research, operations)

The RISC-V Mentorship Program enables one or more 12-week internship-style projects per session, funded by RISC-V, to match mentors/project leaders together with mentees/interns . Mentees are guided through a series of milestones by one or more project mentors, with whom the mentees meet on a weekly basis. Convolution is the core operation of deep learning models and computer vision applications. MLIR supports various convolution operations. Our project is to vectorize them for the RISC-V backend. There are several methods to implement convolution vectorization, such as optimizing nested loops, implementing vectorization algorithm, converting to GEMM, etc. This project needs to choose a vectorization method and implement a conversion pass for the convolution operations. As for the vector semantic support, MLIR has the “Vector” dialect for the general vector abstraction, and it also allows the backend-specific vector dialect, such as the “x86vector” dialect, “arm_neon” dialect, and “arm_neon” dialect. Like these dialects, the project also needs to propose an “RVV” dialect and work with existing dialects and tools. Deliverables: - An MLIR “RVV” Dialect. (Operations in the dialect can support the convolution vectorization) - A conversion pass to vectorize convolution operations in “Linalg” dialect with “RVV” dialect enabled. - A conversion pass to lower the operations in “RVV” dialect to “LLVM IR” dialect. - Unit tests for “RVV” dialect and conversion passes.

The Software Package Data Exchange (SPDX) is an open source standard for communicating software bills of material information (including components, licenses, copyrights and security references). To support SPDX, an online tool has been developed which provides an easy all-in-one website to upload and parse SPDX documents for validation, comparison and conversion and search SPDX license list. This project will provide enhancements and support for the online tools including: - More automated and high-quality deployment for software updates - Removing some of the dependencies on a Python Java Bridge by moving features like license matching over to a native Python implementation - Improving performance and quality of the online tools implementation