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.
Thanos Ruler is a critical component in Thanos that is responsible for the alert evaluation and recording rules. However, a few extensive rules can create a significant amount of resulting time-series, limiting the scalability of Thanos Rule, as it uses a single embedded TSDB. Recording/Alerting Rules are a substantial piece of monitoring infrastructure, so we want to ensure users can operate Rulers and scale them in an easy way. There is no way to scale rule evaluation and storage today except functionally sharding rules onto multiple instances of the Thanos Ruler component. Luckily, we have already solved scaling storage of time-series across various processes using Thanos Receiver. To scale rule evaluations and storage, during this mentorship, you will have a chance to implement the proposal that allows the Thanos rule component to have a stateless mode, storing results of queries by sending them to a Thanos receive hash-ring instead of storing them locally. You will learn about Go, Time-series databases, distributed system design, Prometheus, and of course Thanos.
OpenDaylight user guide is extensively referred by users to understand how to interact with the controller. It details the APIs supported by different plugins and provides examples for the same. However, the user guides were originally written a few years ago and have most examples as XML payloads. Over the years though, JSON has turned into a format of choice for most developers, users to interact with such platforms. Hence, this project is to improve the documentation to include JSON examples for most widely used projects. The scope will be limited to the user guides for the following: - NETCONF - BGP - PCEP - Openflow
Description: Robot accounts should be allowed to access the full Harbor API (more of a UI thing) Expected Outcome: Implement a way to configure and fully documented with examples usecase how to setup Harbor Robot accounts with full or managed access to Harbor
As a built-in orchestration engine for Volcano, jobflow acts as an improtant role for users and it's still new-born. Many issues related to its stability are reported recently. Please help make full test for job-flow on the classical scenarios and reslove bugs reported in issues. - Expected Outcome: Make full test for jobflow and output the test report, fix bugs reported in recent issues.
Testing is an important task to ensure project stability, security, and other aspects. Since KubeEdge is built on top of native Kubernetes, in this project, we aim to integrate Kubernetes end-to-end (E2E) test cases into KubeEdge's CI. This integration will help ensure the native compatibility and usability of KubeEdge. Additionally, we also aim to improve the unit tests and increase the coverage of integration tests for KubeEdge. Expected Outcome: Improve KubeEdge test coverage scenarios
Codeuino is a volunteer-driven, open-source, social networking software development organization that desires the potential to change the way other communities and individuals use and create open-source social-environment tools to better align with end-user expectations, giving prospectus to various other organizations, users and activists to use the social environments built within Codeuino in a custom way. Donut is an open-source, feature-rich, highly flexible and privacy-friendly, social networking platform built for community-oriented collaboration in a customized way. It has been built on the Node.js framework allowing an essential impetus to provide custom and friendly rich widgets and an expansive library of modules to make communication and collaboration easy and successful. With a powerful module system, you can customize this platform by using third party tools, writing your own, or integrating other software.
Harbor is a popular and widely adopted container registry. LFX manatees 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 Golang 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.
Description: WasmEdge is a lightweight, high-performance, and extensible WebAssembly runtime for cloud native, edge, and decentralized applications. WasmEdge is an official sandbox project hosted by the CNCF. WasmEdge has implemented some features of WASI-NN. However, the backend is using ONNX. In this ticket, we would like to have both ONNX and OpenVINO backend.
This project focuses on enhancing observability in kgateway’s agentgateway integration by adding support for OpenTelemetry-based tracing, exposing Prometheus-compatible metrics, and configuring access logging. It builds on a previous LFX project that introduced tracing support for kgateway’s AI extproc server, extending those capabilities to support span propagation from agentgateway. Expected Outcome: 1. Translate the existing tracing and access logging APIs in kgateway to enable configuring tracing for the kgateway’s agentgateway integration 2. Create end-to-end (e2e) tests to validate configuration and trace propagation 3. Raise issues for any gaps or friction points discovered during testing 4. Write documentation for plugin developers and end users 5. Writing user-facing documentation and blogs on Otel tracing with agentgateway and kgateway integration with OpenTelemetry-compatible backends 6. Gain hands-on experience with AI providers, OpenTelemetry, tracing platforms, MCP, a2a, Kubernetes, and kgate 7. Fun!
<p>Chaos Mesh has an existing Go-based E2E test suite for validating chaos behavior on Kubernetes. The current tests are effective, but many scenarios mix test intent, fixture setup, Chaos Mesh custom resource creation, probing logic, assertions, and cleanup in Go code. This makes the E2E suite harder to read and extend, especially for new contributors who need to understand both the user-facing chaos behavior and the underlying Kubernetes test implementation at the same time. This project will introduce a Gherkin + Godog based BDD layer for selected Chaos Mesh E2E tests. The mentee will migrate the existing PodChaos and NetworkChaos E2E tests into executable Gherkin feature files backed by reusable Go step definitions. The new feature files should preserve Chaos Mesh-specific behavior and network/pod verification details, rather than hiding them behind overly broad user-story wording.</p><p><br></p><p><br></p><p>Expected Outcome:</p><p><br></p><p>- A Godog-based BDD test layer that can run Chaos Mesh E2E scenarios from Gherkin feature files</p><p>- Gherkin feature files for all existing PodChaos E2E scenarios</p><p>- Gherkin feature files for all existing NetworkChaos E2E scenarios</p><p>- Reusable Go step definitions for common E2E operations such as preparing workloads, applying Chaos Mesh custom resources, probing pod/network behavior, checking expected failure or delay, and verifying recovery</p><p>- Integration with the existing E2E development workflow, with exact command and CI integration decided during implementation</p><p>- Documentation explaining the Gherkin scenario style, step definition conventions, and migration guidance for other Chaos Mesh E2E tests</p>
Provide a CLI command for Keptn CLI that generates a template repository to start developing a Keptn service integration.
Optimize KCL LSP(language server protocol) prompt information, including the implementation of type inlayhint and optimization of hover content rendering. Currently, KCL’s hover content is in plain text format and needs to be rendered into a more beautiful style. Expected Outcome: Added type inlayhint in KCL IDE and optimize hover content render.
Cartography (https://github.com/cartography-cncf/cartography) makes maps of the cloud so that security and devops teams can find and fix problems. Think about it like the Maurauder's Map (https://simple.wikipedia.org/wiki/Marauder%27s_Map) from Harry Potter. Cartography has very good AWS coverage, but lacks support for many Azure and GCP resources. With your help, we can fix this! Companies around the world use Cartography to better understand their infra, and you can be a part of this. Most of these modules should be conducive to coding with agents (we have a well-documented AGENTS.md! (https://github.com/cartography-cncf/cartography/blob/master/AGENTS.md), so if you enjoy writing in Python, want to learn about information security/devops, and moving fast, this is the project for you. Expected Outcome: Design and implement graph schemas for missing Azure and AWS objects in Cartography
Barometer collects system metrics and events to aid in the monitoring of the NFVI and provide means for these metrics and events to be relayed to higher level fault management systems for enforcement and corrective actions. In addition, this information could be fed to analytics systems to enable failure prediction, and can also be used for intelligent workload placement. Barometer uses collected to collect the system metrics, and works closely with the collected community. Increasing the automated test coverage benefits collected as well as Barometer. The Barometer team has contributed several plugins to collected, and in some cases, specialized hardware is needed to test that the plugins are functional. Major work items for the Jerma release are improving the test infrastructure for collected. This project will involve automating existing tests for individual plugins. The test automation being set up will be one instance of a set of collected community CIs.
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.
This project focuses on implementing an enhanced Model Context Protocol (MCP) and A2A communication framework for KubeStellar's Management Control Plane server. It builds upon the foundation MCP implementation to include advanced A2A coordination capabilities, distributed AI agent communication, and sophisticated context management for multi-cluster environments. Expected Outcome: A fully specified Model Context Protocol with A2A communication extensions, implementation of protocol handlers in Python for the MCP server, A2A communication framework enabling AI agent coordination, context management system for KubeStellar state information, serialization mechanisms for cluster state, protocol extension mechanisms for different AI providers, performance optimizations, and comprehensive test suite.
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