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.
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.
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/)
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
<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);"> </span></p><p><br></p>
In the past few quarters, a lot of work has gone into the new Remote Write 2.0 (PROM-35) proposal, and a new spec has been successfully established https://prometheus.io/docs/specs/prw/remote_write_spec_2_0/. But there is still a lot of work that needs to be done to declare it stable, in terms of stability and performance in Prometheus, and general adoption from the wider Prometheus ecosystem. Expected Outcome: Since this is a large initiative, for this round of mentorship, we want to focus on the following tasks, 1. Add 2.0 support to compliance test; make it easy to test write and receive implementations. 2. Ensure RW new features works on agent mode (test for agent mode with metadata-wal-records and type-and-unit features). 3. Ensure Prometheus uses the official RW client
OpenCost has helped a lot of people save a lot of money on their infrastructure. We like to think that this has contributed to things like engineering headcounts not getting reduced, small businesses and startups surviving longer, and so on. The OpenCost UI is a key part of this - it lets people visualize their spend, find inefficiencies, and so on. It's time to uplevel the OpenCost UI to enable the next generation of savings! Expected Outcome: We would like all pages of the OpenCost app to be implemented in Carbon or similar modern design system. We would like dashboarding functionality and a unified color scheme. All implementations should be delivered with unit and end-to-end tests. All existing functionality of the UI should be present in the revamped design.
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
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.
<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>
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.
Build a documentation playbook detailing the specifics and resources needed for running Open Programs Offices within a university. This work will involve developing an outline of topics required, summarizing various resources, and working with team members to re-format documentation to be used in our playbook. Essential skills - Writing educational material that evolves over time - Ability to quickly learn & understand complex topics - Copywriting branding content - simplifying technical concepts for non-technical folks - Social Media/Journalism - Computing generalist Previous co-op/internship experience a plus· Experience in working with and/or contributing to Open Source Software, Open Data, Open Hardware or similar communities a plus Mentees will learn how to work within a multi-disciplinary team of developers, designers, and writers to collate and re-package technical information for a broader, more generalized audience. Essential skills - Writing educational material that evolves over time - Ability to quickly learn & understand complex topics - Copywriting branding content - simplifying technical concepts for non-technical folks - Social Media/Journalism - Computing generalist Previous co-op/internship experience a plus· Experience in working with and/or contributing to Open Source Software, Open Data, Open Hardware or similar communities a plus
The VelaUX API server follows the Open API schema. It could auto-generate the swagger configs via CLI. When VelaUX frontend or other projects need to call these API, they must write the model code and request the API code. We can provide SDK for them to start faster. [OpenAPI generator](https://openapi-generator.tech/) could help to generate most codes. But there are still some special cases like: - Dynamic component/trait/policy/workflowsteps properties need to be generated according to CUE. - Automatically handles the user authentication process, including automatically refreshing tokens. - The API definition may be incomplete accuracy, we should check it to generate high-quality code. - Expected Outcome: The outcome of this project will be expand two more database driver for KubeVela VelaUX API server: - VelaUX APIServer TypeScript SDK - VelaUX APIServer Java SDK
Cortex provides horizontally scalable, multi-tenant, long term storage for Prometheus metrics when used as a remote write destination, and a horizontally scalable, Prometheus-compatible query API.
This project focuses on improving localization workflows in Kubernetes SIG Docs by strengthening visibility, prioritization, and traceability across English and localized documentation. The enhanced workflows will benefit to reducing review burden and coordination costs that arise in environments where upstream content changes and subsequent localization efforts occur asynchronously. The project also explores practical approaches to achieving measurable productivity gains by adopting AI-assisted tools within established human workflows. Mentees work with mentors in SIG Docs localization to improve existing localization review and coordination processes, such as label-based coordination and review signals implemented through Prow/CI. The project focuses on the following core areas: improving traceability between frequently changing English content and localized documentation, continuously tracking and notifying review priorities for translation updates, and maintaining visibility into localization coverage and prioritization based on document importance. All outcomes are designed to integrate naturally into existing SIG Docs GitHub workflows and practices while preserving and supporting human-led review and decision-making. - Expected Outcome: - Reusable Prow/CI automation prototypes - Extensible architecture - Best practices documentation
Policy-based control for cloud native environments.
Leading Open Source Container Attached Storage, built using Cloud Native Architecture, simplifies running Stateful Applications on Kubernetes.
The Zowe Virtual Desktop needs to provide a way to easily transfer files and datasets from the mainframe to a user desktop and vice versa, while dealing with encoding and security.
The objective of this project is to improve the interoperability of different blockchain networks by developing smart contract gateways that can interact with multiple networks. These gateways will automate, trace, and secure the process of submitting transactions to other blockchain networks. To achieve this goal, the project will involve creating smart contract gateways for various blockchain networks, including those using the same platform, as well as gateways to submit transactions to heterogeneous networks. The initial focus will be on developing gateway smart contracts for connecting multiple separate Hyperledger Fabric networks, and the next step will be to create gateways to connect Hyperledger Fabric to other heterogeneous networks, such as Hyperledger Indy and Besu. The project's primary objective is to evaluate system-level and large-scale integrations, which will be accomplished by setting up an extensive network of blockchains using Hyperledger Fabric as the source blockchain and other networks as destination networks. Overall, the project aims to enhance the efficiency, security, and traceability of cross-blockchain transaction submissions, thereby improving the overall functionality of blockchain technology.
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.
This project will focus on governance documentation for the Cilium project with two key parts. First, the governenace documentation should be moved out of the main docs and into the community repo. Second, we need to do an inventory of all of the repos under the project and come up with a lifecycle for them. Expected Outcome: Governance docs in community repo. All repos accounted for and with a lifecycle plan. Recommended Skills: enthusiasm for governance and basic markdown experience Upstream Issues: - https://github.com/cilium/community/issues/78 - https://github.com/cilium/community/issues/27 - https://github.com/cilium/community/issues/82
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.