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.
SDC is the ONAP visual modeling and design tool. It creates internal metadata that describes assets used by all ONAP components, both at design time and run time. The SDC manages the content of a catalog, and logical assemblies of selected catalog items --as needed-- to completely define how and when VNFs are realized in a target environment. A complete virtual assembly of specific catalog items, together with selected workflows and instance configuration data, completely defines how the deployment, activation, and life-cycle management of VNFs are accomplished. Selected sub-assemblies may also be represented in the catalog and may be combined with other catalog items, including other sub-assemblies. ONAP has adopted the CII (Core Infrastructure Initiative) Badge Program. This project will focus to address the remaining Security requirements defined by the ONAP SECCOM Community based on JIRA Backlog.
Distributed transactional key-value database, originally created to complement TiDB.
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.
<p>Volcano's scheduler has no presence in the dashboard today. Three critical operator workflows are missing: </p><p><br></p><p>(1) Configuration — the entire scheduling policy (6 actions, 22 plugins, per-plugin toggles and arguments) lives in a raw Kubernetes ConfigMap edited only via `kubectl`, with no validation or UI; </p><p>(2) Observability — Volcano exposes rich Prometheus metrics (scheduling latency, preemption counts, unschedulable job/task counts) that the dashboard never queries, leaving operators dependent on a separate Grafana stack; </p><p>(3) Logs — debugging scheduling issues requires `kubectl logs` against pods in `volcano-system`; the dashboard has no log viewing capability at all. This project adds a `/scheduler` section with three tabs: a Config tab that reads and writes the `volcano-scheduler-configmap` as a structured form, a Metrics tab that proxies and visualizes the scheduler's Prometheus `/metrics` endpoint, and a Logs tab that streams live logs from any Volcano system component (`volcano-scheduler`, `volcano-controller-manager`, `volcano-webhook-manager`, `volcano-agent`) — all backed by new tRPC procedures using the existing `CoreV1Api` client in `packages/trpc/server/utils/k8s.ts`.</p><p><br></p><p>Expected Outcome:</p><p><br></p><ul><li>Config tab: draggable action pipeline editor, plugin tier editor with per-plugin `enabled` toggles and typed argument fields, live YAML diff preview, and a Save button that patches the ConfigMap via `CoreV1Api.patchNamespacedConfigMap`.</li><li>Metrics tab: stat cards for unschedulable jobs/tasks and total preemptions; line chart for e2e and per-plugin scheduling latency; bar chart for per-action latency — all from a new `getMetrics` tRPC procedure querying the scheduler's `/metrics` endpoint.</li><li>Logs tab: component selector dropdown (`scheduler`, `controller-manager`, `webhook-manager`, `agent`), `tailLines` control, keyword filter/highlight, and real-time log streaming via `CoreV1Api.readNamespacedPodLog` with a Server-Sent Events or polling transport.</li><li>Updated RBAC in `deployment/volcano-dashboard.yaml` for ConfigMap `get`/`update` and Pod logs in `volcano-system`.</li><li>Tests and user-facing documentation.</li></ul>
As organizations from different sectors move their computing workloads across multiple environments, from on-premises to public Cloud to Edge, they require greater assurances that their sensitive code and data are protected. Confidential Computing protects data in use by performing computation in a hardware-based Trusted Execution Environment (TEE). To learn more about the Confidential Computing Fellowship, please check the guide below: https://enarx.dev/docs/Fellowship/Introduction Also, please join the #mentorship chat channel at: https://chat.enarx.dev/channel/mentorship
MLModelScope (https://mlmodelscope.org/) is a playground that allows people to try ML tasks with various model types, frameworks and hardware backends. It is jointly developed by IBM and University of Illinois. It is currently one of the platforms that collaborate with MLPerf for ML benchmark workload validation. (IBM participates in MLPerf as a founding members, including contribution from z). MLModelScope enables multiple backends for model training, execution and performance study. Currently IBM Z is enabled.
KubeFlex is a flexible and scalable platform for running lightweight Kubernetes control plane APIs to support specific use-cases in cloud and edge computing environments. It supports various kinds of control planes, such as: vcluster, ocm, host, etc. This project aims to extend KubeFlex to support a new type of control plane that provides the full components of a control plane in a typical Kubernetes cluster (e.g., API Server, Scheduler, Controller-Manager, etc.). This new control plane will be based on K3s and it will allow KubeFlex to support new use-cases such as multi-tenant scenarios. Expected Outcome: A new type of KubeFlex provided control plane based on k3s
OpenYurt is an open-source edge cloud-native platform designed to streamline application management and resource orchestration in edge computing scenarios. This project aims to enhance the yurt-dashboard (the core management interface of OpenYurt) by implementing internationalization support, integrating edge AI capabilities, and upgrading core API versions to improve global accessibility, technical innovation, and system stability. The project will leverage the React frontend framework, Golang backend services, and Kubernetes ecosystem toolchain to provide developers with a more efficient edge cloud-native experience. Expected Outcome: 1. i18n Implementation: Extract existing Chinese text and complete English translations using LinguiJS framework Implement frontend language-switching functionality with dynamic user selection 2. Edge AI Integration: Containerize and develop deployment templates for at least 3 open-source edge AI applications in the dashboard 3. API Modernization: Align with OpenYurt' latest API standards to ensure platform compatibility and security.
Integrated Cloud Native (ICN) Blueprint (BP) family intends to address deployment of workloads at large number of edges and public clouds using Kubernetes (K8s) as resource orchestrator at each site and ONAP4K8s as service level orchestrator across sites. ICN BP is an end2end solution that provides a software stack integrating multiple layers of software such as Service orchestrator, Resource Orchestrator, Software and hardware accelerator plugins etc. Objective of ICN BP is to have single stack for Enterprise, Telco and IoT use cases. Major work items where the intern can help are – 1. Bug fixes and improving installation scripts 2. KUD integration, tuning, and adding new features 3. Maintaining current CI/CD systems 4. Integrating Cluster API into ICN local controller
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/)
<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>
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.
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.
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 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
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
Leading Open Source Container Attached Storage, built using Cloud Native Architecture, simplifies running Stateful Applications on Kubernetes.
Enhance Meshery's existing orchestration capabilities to include support for kro ResourceGraphDefinitions (RGDs) as first-class Meshery Models. This involves enabling Meshery to manage and orchestrate RGDs, similar to how it handles other Kubernetes resources. The project will also include generating support for ResourceGraphDefinition in Meshery's Model generator. Expected Outcome: - Meshery will be able to orchestrate and manage kro RGDs. This includes the ability to deploy, configure, and manage the lifecycle of RGDs through Meshery. The Meshery Model generator will be updated to automatically generate models for kro RGDs, simplifying their integration and management within Meshery. This will be an officially supported feature of Meshery.
In the Thanos Compactor UI there is visibility of the global block list and loaded block list. But it would be useful to also have a list of planned and currently running compaction groups in order to see what exactly is in progress. This way it would be easier to diagnose what the Thanos Compactor is currently working on, and possibly what is delaying the progress of compactions. This is especially useful if you have large TSDB blocks in S3 buckets that take time to get compacted. Expected Outcome: We have an endpoint in Compactor that details compaction plan, and this is also visualized in a Compactor UI page.
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 proposed project includes the following key activities: A systematic review of the applicability of fault-tolerant software patterns to Hyperledger Fabric chaincode as the potentially faulty software Creation of programming idioms for applying the applicable patterns to Hyperledger Fabric chaincode Prototyping "fault tolerance gadgets" (libraries) for easy application to chaincode The book "Patterns for Fault Tolerant Software" from R. Hanmer (Wiley, 2013) is a good reference of the patterns that the project will target. This is a research-focused project which is relatively light on programming. At the same time, a rather deep dive into the workings of Hyperledger Fabric is expected.
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)