Fetching the latest programs, projects, and workspace data.
Find open source projects actively accepting contributors. Search repositories, filter by program milestones, difficulty tags, or tech stack.
Use our Orbit AI Matcher to find out! Get instant matching scores based on your developer skills, preferred frameworks, and contribution experience.
Convert your selected open-source project into a winning GSoC, LFX, or Outreachy application using Proposal Studio.
Hyperledger Aries currently support only Hyperledger Indy blockchain. Verifiable credential(VC) and decentralised identifier(DID) standard & specification emerged in last few years. Trust over IP , Sovrin network, covid credential initiative are using Indy & Aries technology framework. Hyperledger Fabric general enterprise blockchain framework and most used Hyperledger project, latest Forbes Blockchain 50 report shows that 60% companies using Hyperledger Fabric for their enterprise grade blockchain. All the major cloud provides fabric as BaaS( Blockchain as a Service). Currently every identity/credential application using Indy/Aries stack to build W3C complaint VC & DID applications. There will be huge adoption and applicability of Hyperledger Fabric & Aries integration project. As per Hyperledger project governance there should be Hyperledger project interoperability to huge adoption of Hyperledger technologies. Mentee will learn: 1) Hyperledger Fabric Architecture & SDK/API 2) Hyperledger Aries Javascript framework 3) VC/DID standard and Application Expected Outcome Hyperledger Aries & fabric Wrapper or Aries will have support to use Hyperledger Fabric as Blockchain for storing credentials.
Harbor is a widely adopted container registry, and its initial CLI has been developed by LFX mentees. The goal is to extend this CLI by implementing additional functionalities and workflows that are currently only available in the Web UI. The CLI should be useful for Harbor administrators and users, especially to manage workflows within CI/CD pipelines. We seek a Golang-experienced mentee to enhance the CLI independently. Expected Outcome: 1. Extend the Harbor CLI to include essential commands not yet implemented. 2. Add new features to improve Harbor management via the CLI for Harbor Administration, enabling robust workflows in CI/CD environments. 3. Review and test all implemented commands to ensure they work as expected.
Many advance workloads in OpenKruise are widely used in production, however the API version of the workload is still in v1alpha1. The goal is to promote the API version of mostly used and mature workload to v1beta1 and optimize the CRD fields for better clarity. This is a follow-up of [previous project](https://mentorship.lfx.linuxfoundation.org/project/7426f5d7-1879-46cc-a933-880ee790d0eb), and target API is the advance operation and resilience policy. - Expected Outcome: 1. API definition of v1beta1 resources and the implementation for conversion webhook to convert v1alpha1 resource to v1beta1 resource 2. Unit and integration tests 3. Documentation for the usage of v1beta1 resource in the OpenKruise website
Kgateway can be used as an “AI Gateway” that allows applying traditional traffic management, security, and resiliency policies when reaching out to LLM providers. It also allows sending a request to another server for processing things like prompt guards or enrichment before we send it off to the LLM providers. An important aspect in any system that has lots of moving parts is observability: the collection of metrics and other information that allow you to identify issues and troubleshoot a live system. This project aims to enable OpenTelemetry support in kgateway’s AI extensions by allowing users to configure a gRPC tracing collector. This feature enables span propagation from the AI extensions extproc server and exporting traces to an OpenTelemetry-compatible backend (e.g., OpenTelemetry Collector, Jaeger, Zipkin, or Datadog). This feature will build on Envoy’s native tracing capabilities and aligns with industry-standard observability practices. This will make it easier to debug, monitor, and optimize traffic flowing to LLM Providers through kgateway. Expected Outcome: 1. Design and implement an API to enable tracing for the kgateway’s AI extproc extension. 2. Extend the AI extensions extproc server with OpenTelemetry tracing. 3. Create end-to-end (e2e) tests to validate configuration and trace propagation. 4. Write documentation for plugin developers and end users.....
This project aims to develop a plugin system for KubeStellar that will allow users to discover, install, and manage plugins that extend KubeStellar's functionality. The plugin system will provide a centralized hub for community-contributed plugins, enhancing KubeStellar's extensibility and user experience. The implementation will include a backend API written in Go and a frontend interface built with React. Expected Outcome: 1) A fully functional plugin system integrated into KubeStellar's UI 2) Backend API for plugin management (upload, discovery, installation, updates) 3) Frontend components for browsing, searching, and installing plugins 4) Plugin versioning and compatibility checking 5) User ratings and reviews for plugins 6) Documentation for plugin developers and users
Jenkins is an open source automation server. It provides thousands of plugins to support building, testing, deploying and automating virtually any project at any scale. Your donations help to keep the project going and to accelerate its evolution. More information about how we use donations: https://jenkins.io/donate/
Meshery Models are declarative representations of infrastructure and applications. Within these models, Relationships define how different Components (e.g., Kubernetes resources, Cloud services) interact and depend on each other. These relationships are crucial for visualizing, understanding, and managing complex cloud native systems. This internship focuses on significantly expanding the breadth and depth of Meshery Relationships across a wide array of technologies supported by Meshery. As Meshery continues to integrate with more cloud-native technologies (Kubernetes, public clouds, and all CNCF projects), there's a growing need to accurately model the intricate relationships between their components - vital for providing users with comprehensive insights and control over their deployments. Expected Outcome: - A multitude of new relationships defined both intra and inter GCP services. - Policy Contribution: For advanced interns, there may be opportunities to contribute to the Rego policies that evaluate and enforce these relationships.
Microcks (https://microcks.io/) is a cloud native, open source tool under CNCF for API and microservices mocking and testing. This project seeks to enhance our CLI tool by integrating frameworks like Cobra CLI. Expected Outcome: @JulienBreux has started some work on creating a utility tool called `mksctl` here (https://github.com/JulienBreux/mksctl). The base of `mksctl` has also been reversed into the `1.x` branch of the `microcks-cli` repo (https://github.com/microcks/microcks-cli/tree/1.x). The main goals of a new CLI version are: - Provide the same interface for exiting test and import commands - Provide a way to easily install this tool via integration with packet manager (brew, apt or others) - Allow developers to easily start new Microcks instances with mksctl start and mksctl stop, for example - Allows quick addition of new commands like import from URL, import all the files from a directory, create job, list jobs, and so on. Moving to standard tools like Cobra CLI is a way to make it more scalable so that people can contribute and add the features they want.
After upgrading the OpenEBS control plane, user/admin is required to upgrade the Jiva Volumes by launching a Kubernetes Job. This enhancement request is to improve the existing OpenEBS CLI jiva sub-commands that will help users with required information to create Kubernetes Jobs, as well as to add a sub-command that will automatically launch the upgrade jobs.
Prometheus remote write allows users to send their metrics to other time series databases. Though the Prombench tool has existed for a number of years, it has never been extended to support performance testing of Remote Write in a realistic production like environment. With the upcomming Remote Write 2.0 changes to both the underlying implementation as well as the wire format, the need for benchmarking of remote write beyond static Go bechmark tests has increased. Expected Outcome: Build additional (or extends existing) tooling, similar to Prombench’s load-generator and avalanche, to support scenarios under which remote write should be performance tested. For example; allowing gradual increases/decreases in # of active series, sudden spikes in active series, various amounts of latency in the server receiving the remote write data, etc. Time permitted, extend Prombench's test suite to include a set of Remote Write tests that can be run via a new command.
Integrate a new architectural component into Meshery: a workflow engine, using Temporal. This project involves shifting Meshery off of sqlite over to postgres using gorm (golang). Interns will familiarize with concepts of orchestration engines, including chaining workflows, and content lifecycle management.
stress-ng is a tool designed to stress test and exercise core components of a kernel. This project aims to improve the test coverage of stress-ng using data driven test coverage data generated using gcov. The project will help increase understanding of the Linux kernel interfaces with userspace, usage of tools such as gcov and experience with C programming.
<p>This project focuses on validating KubeEdge as an edge-native infrastructure for lightweight large language model inference. As more AI services move from the cloud to edge devices, lightweight LLMs provide a practical way to reduce latency, protect data privacy, and support local intelligence under limited resources.</p><p>The mentee will deploy one or more lightweight LLMs on KubeEdge edge nodes and evaluate the complete workflow, including model packaging, workload scheduling, service exposure, lifecycle management, and performance measurement.</p><p>The project is expected to produce a practical reference for running generative AI workloads on edge nodes managed by KubeEdge.</p><p><br></p><p>Expected Outcome:</p><p> - Successfully deploy and run one or more small-parameter large models on KubeEdge edge nodes, and complete end-to-end inference workflow validation.</p><p> - Explore deployment methods and best practices for managing lightweight model services based on KubeEdge.</p><p> - Evaluate basic performance on edge devices, including startup time, memory usage, inference latency, and runtime stability.</p><p> - Fix issues discovered during validation, and submit PRs to KubeEdge or related example repositories when necessary.</p><p> - Publish a blog or document to kubeedge/website introducing how to deploy and run small-parameter large models based on KubeEdge.</p><p> - Optional: complete example validation with a lightweight scenario, such as local Q&A, document summarization, or lightweight multimodal inference.</p><p><br></p>
Create sustainable open source Ansible modules for creating/managing virtual server instances and storage devices connected to IBM Z. The final target state products could be used to communicate to various storage devices connected to mainframe and control HW function to automate storage managements. Intermediate target state would be communicating to IBM DS8K CLIs and/or RestfulAPIs to help initialization of storage device for virtual servers.
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.
Harbor CLI is the official command-line interface for Harbor container registry. This project focuses on improving CLI user experience by porting the remaining complex commands such as job service dashboard and audit logs streaming, and enhancing the release pipeline for simplicity and security. - Expected Outcome: - Implement job service dashboard commands in CLI - Add audit logs streaming functionality - Improve and secure the release pipeline - Enhance overall CLI usability
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