Explore Projects

PSRAM/HyperRAM is a low pin count DDR-type memory that provides data in sequential address bursts. These memories are fairly large and would be great for applications that require more memory. Block SRAM inside GOWIN's FPGA's are dynamically addressable and are better for use with RISC-V MCUs since they can obtain instructions and data at any address within a clock cycle. However, there is limited amount of BSRAM in most semiconductor devices including FPGAs. A cache between the PSRAM controller bus and the RISC-V processor bus can help fetch instructions/data from PSRAM with sequential addressing and store locally in BSRAM. The processor can then dynamically obtain subsequent instructions and data from the BSRAM within a particular address range. GOWIN already has multiple RISC-V IP cores and PSRAM IP cores in it's IP Core Generator tool. This project would be to develop the cache architecture and RTL that sits in between these two IPs and efficiently trades off the efficiency of using BSRAM for instructions/data versus the storage size/cost benefits of using PSRAM memory.

Headlamp is a Kubernetes UI that supports a growing ecosystem of plugins, including integrations with CNCF projects like Flux, KEDA, and Falco. As the number and complexity of these plugins grow, ensuring a consistent, intuitive, and user-friendly experience becomes increasingly important. This project will focus on conducting UX audits of existing Headlamp plugins, identifying usability issues, and proposing design improvements. It will also explore user personas (e.g., operators vs. developers) to inform design decisions and help shape the future of plugin UX in Headlamp. Expected Outcome: A design-led UX audit and improvement initiative that includes: 1. A review of selected Headlamp plugins to identify usability issues and inconsistencies 2. User research and persona development to better understand plugin audiences 3. Design proposals and mockups for improving plugin UIs and workflows 4. Collaboration with technical mentors to help implement selected improvements 5. Optional exploration of UX needs for recent Kubernetes features or under-designed areas in Headlamp

A proof of concept to add buildkit support to pack in order to build multi-arch images. Pack is the reference implementation of a Cloud Native Buildpacks platform used to build application images from source code. Expected Outcome: Multi-arch support has been one of the most requested features for Cloud Native Buildpacks, and this would allow end-users/developers to build multi-arch images with the pack cli.

Kyverno currently supports cluster-wide CEL-based policy types (ValidatingPolicy, MutatingPolicy, ImageValidatingPolicy, GeneratingPolicy, and DeletingPolicy), but lacks namespaced versions. This creates challenges for namespace owners who need to manage policies within their namespaces without requiring cluster-wide permissions. The goal of this project is to implement namespaced versions of all five CEL-based policy types to provide better RBAC control, security, and lifecycle management for namespace-scoped policy management. Expected Outcome: 1. Implement namespaced versions of all five CEL-based policy types 2. Ensure proper RBAC integration for namespace-scoped policy management 3. Create comprehensive documentation and examples for namespaced policies 4. Write tests to validate namespaced policy functionality

Currently, OpenKruise depends solely on the PaaS or CLI to listing OpenKruise workload display and operations. The lack of a general purpose Web-UI greatly hinder the adoption among developer users. This project is about to build a simple Web-UI that can list OpenKruise workload along with the native K8s workload, and support enhanced operation such as container restart or workload rollout. The Web-UI is preferably developed using UI extensions of existing PaaS e.g. Kubesphere and Rancher. Expected Outcome: 1. simple Web-UI 2. integration of the Web-UI with existing PaaS such as KubeSphere (https://dev-guide.kubesphere.io/extension-dev- guide/zh/)

Develop a connector that provides both synchronous and asynchronous modes of interacting with a running Hyperledger Besu node. The connector would act as an interface between an enterprise application and the Hyperledger Besu node for data ingestions and it could provide event subscription options. The scope of the project would also include an end-to-end test on a sample network.

Currently, Kmesh metrics are only reported when a TCP connection is closed. In the case of long connections, it is not possible to know the status before the connection is closed. Therefore, we hope to add the capability to periodically report metrics for long connections. Expected Outcome: 1. proposal 2. code 3. user guide

Iroha 2 currently has WASM-based smartcontracts. WASM, however, imposes a maintainer burden on the user, so upgrading these takes work. We also have an ISI based on easily upgradeable smartcontract facilities, which are difficult to compose into arbitrary logic but require no manual intervention for upgrading to newer versions of Iroha. We would like to involve the community in creating a domain-specific language for creating and composing logic made out of ISI. Iroha 2 DSL is our most important project. Therefore, we would like it to be considered with top priority if not all Iroha-based projects can be considered for the internship program. Learning Objectives - Explore domain-specific optimisations not ordinarily possible in regular compiler design. - Explore the design of ergonomic languages. - Improve the understanding of Rust. Expected Outcome - (Optional) Well-defined Iroha DSL grammar - A binary application (compiler) that parses DSL and produces ISI according to a well-defined grammar - A set of example files written in the DSL covering the following simple use-cases -Cross-blockchain transfer -Modification of metadata -Transference of permission tokens

The Envoy Gateway project provides a simplified way to use Envoy Proxy as an API Gateway, and its documentation is critical to enabling adoption, onboarding new users, and improving developer experience. While the existing documentation covers core concepts and use cases, applying the CNCF Tech Docs Analysis Framework will help assess and systematically enhance its clarity, completeness, and usability. This project aims to evaluate and improve the Envoy Gateway website and documentation (https://gateway.envoyproxy.io/) by leveraging the structured analysis methodology from the CNCF Tech Docs Analysis Framework (https://github.com/cncf/techdocs/blob/main/docs/analysis/howto.md). The outcome will be a comprehensive documentation improvement plan, with targeted updates and best practices implemented. Expected Outcome: 1. Apply the CNCF Tech Docs Analysis Framework to assess Envoy Gateway docs 2. Identify gaps in content, structure, readability, and technical accuracy 3. Improve documentation organization, navigation, and developer onboarding 4. Optimize technical guides, examples, and API references 5. (Stretch Goal) Introduce best practices for continuous documentation improvement

The RISC-V movement has massive potential to unify a fragmented industry behind a single instruction set architecture (ISA). If technology providers focus their efforts on a single processor architecture, rather than duplicating efforts among incompatible architectures, the entire computing ecosystem benefits. Inefficiency in critical base components of the ecosystem hampers this consolidation. There are numerous projects which directly serve as the base components of the software ecosystem, including assemblers, disassemblers, compilers, linkers, loaders, simulators, emulators. In most of those projects today, the human-readable documentation is consulted, and the necessary implementations are performed manually. Needless to say, these processes are time-consuming, inefficient, and error-prone. A new foundation which can serve as a base for automatically generating large swaths of the processor-dependent ecosystem is available, but is not yet effectively use. The “RISC-V Unified Database” project has transformed the salient content from within the RISC-V specifications into an accessible format, YAML, from which content for downstream projects can easily and automatically be further transformed into the content necessary to their project which is currently produced by manual effort.

WasmEdge supports PyTorch, TensorFlow Lite, llama.cpp, and more NN backend. Dealing with the text-to-voice is a big thing that we want to achieve. To make it possible, we would like to integrate piper (https://github.com/rhasspy/piper), A fast, local neural text-to-speech system in C++ as a new WASI-NN backend (https://github.com/second-state/wasmedge-wasi-nn). Expected Outcome: 1. A new plugin provides a piper WASI-NN backend 2. A test suite for validating the plugin 3. Documents and examples for explaining how to use the plugin.

This project focuses on contributing to mldsa-native, a work-in-progress implementation of the ML-DSA post-quantum signature standard. The mentee will help advance mldsa-native towards its first stable release by working on various aspects of building a secure, fast, and portable implementation. Tasks may include implementing constant-time analysis tooling, expanding test coverage, improving build systems, enhancing documentation, developing benchmarking infrastructure, or contributing to CI/CD pipelines. The project offers flexibility to focus on areas matching the mentee's interests while contributing meaningfully to this post-quantum cryptography implementation and helping achieve production readiness.

<p>We plan to refactor and recode Community AI / ML and HPC (double precision) applications to port them to RISC-V this summer. This is a large, potentially daunting effort but we anticipate building scripts and methods to be able to substantially automate the process. Priority will be given to codes that make the most impact. Here is the initial list of 400 codes we are optimizing and compiling for RISC-V this summer: <a href="https://tinyurl.com/2aau5b9r" rel="noopener noreferrer" target="_blank" style="background-color: rgb(255, 255, 255); color: rgb(17, 85, 204);">https://tinyurl.com/2aau5b9r</a><span style="color: rgb(34, 34, 34);">&nbsp;</span></p><p><br></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.

This feature request aims to automate the building and publishing of OS images that are used in Kubespray CI testing. Currently, these images (defined in `test-infra/image-builder/roles/kubevirt-images/defaults/main.yml`) must be manually created and pushed by maintainers. Automating this process would reduce manual work, eliminate bottlenecks when maintainers are unavailable, and could include automatic cleanup of outdated or unused images, while still retaining images needed for older supported release branches. - Expected Outcome: A CI job (likely post-merge and possibly periodic) that automatically: 1. Builds the required Kubespray OS images used in CI for tested distributions. 2. Pushes these built images to the appropriate registry. 3. Cleans up old or no longer needed images but retains those required for supported release branches.

Vitess is a CNCF project that has been around for a while. It has a strong community of users and contributors. We want to continue growing this community and make sure that everyone feels welcome and included. Expected Outcome: The mentee is expected to evaluate contributor ladder schemes and rewards and produce a recommendation for the Vitess maintainers. Once a decision is made, the mentee is expected to implement the decisions from the maintainer team. The mentee is expected to collect data about Vitess usage from the community and publish the highlights as a blog post. The mentee is expected to review the Getting Started docs (https://vitess.io/docs/20.0/get-started/) on the Vitess website and enhance them to improve the onboarding experience. The mentee is expected to research and recommend marketing opportunities for Vitess. These could be guest blog posts, podcasts, live streams etc.

Jaeger is a distributed tracing platform. Jaeger V2 is a major new version where we rebase all Jaeger backend components (agent, collector, ingester, and query) on top of the OpenTelemetry Collector. Currently jaeger-v2 components are initialized without observability clients. We need to instantiate appropriate logging, tracing, and metrics clients and pass them to the components. The existing code uses internal metrics API, which needs to be bridged to OTEL metrics to minimize code changes. Expected Outcome: Achieve parity in observability of jaeger-v2 compared to jaeger-v1

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

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. On the other hand Iroha (version 1.x) is great with asset management, and has functionality to store data, which makes those two projects a perfect fit! With this internship we will not only allow the interoperability between different blockchains but also create a system of Iroha networks that will also demonstrate the integration in examples easy to run by everybody. The mentee will be able to learn: 1) ways of integrating different projects from architectural point of view, 2) architecture of Iroha (1.x) and Cactus, 3) work in true spirit of open-source, communicating with both Iroha and Cactus community, joining calls and using other community tools, 4) writing documentation, so anyone in the community could use the results of their work, 5)following rules and standards of open-source projects created by hyperledger Expected Outcome 1) Documented, ready-to-use integration of Iroha and Cactus, 2) Documented example of integration between multiple (two and more) iroha's networks with Cactus, 3)Documented example of integration between Fabric and Iroha