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.
Solang is a Solidity compiler that targets several blockchains, including Solana, Substrate and ewasm. The mentorship project consists of three goals that can provide mentees with a broad knowledge of a compiler's inner-workings. The three tasks are in different stages of the compiler. Solang’s parser analysis halts compilation entirely when there is any invalid expression or function declaration. This should be improved so that it continues parsing the Solidity contract after encountering an error, providing better diagnostics (warnings and errors) to the developer. The parser utilizes Lalrpop and the mentee would be using its error handling capabilities to implement a solution. Often the length of a dynamically allocated array is known at compile time as the allocation happens with a constant. When the length is required at some later point (e.g. for bounds checks for array indexing), the length is retrieved again. Mentees will add an optimization to make the length a compile time constant. Solang has an implementation of multiplication of integers of 256 and 128 bit. This does not have overflow detection. This requires improving the multiplication in the solang stdlib.
This project aims to design and build a suite of automated scale tests for kgateway that would run as part of our builds and releases process. These tests will help us understand how kgateway behaves under a large number of Kubernetes gateway resources and kgateway extensions, and load tests to ensure it performs reliably as usage scales. You'll gain hands-on experience with performance testing, infrastructure automation, and Kubernetes-based systems. Expected Outcome: 1. Design and a scale testing suite 2. Build a scale test suite for kgateway 3. Analyze test results to identify bottlenecks or failure points 4. Write developer-facing documentation 5. Explore Oracle Developer cloud and determine if it is suitable for kgateway’s scale tests.
Vitess is a distributed database system built on MySQL. Developers often need to search through documentation, Slack discussions, and GitHub issues to find answers. This project will implement an AI-powered FAQ chatbot using **Retrieval-Augmented Generation**, integrating **vector search** with an **LLM** (like OpenAI, DeepSeek, GPT-4, Mistral, Llama3). The chatbot will be available via a **CLI and Slack bot** for developer support. Expected Outcome: A chatbot that provides accurate Vitess-related answers via CLI and Slack, using indexed documentation and discussions for retrieval.
The zlib is required for compiling and running many existing C / C++ / Rust apps in Wasm. Most noticeably, it is [needed in the Python port to Wasm](https://github.com/python/cpython/issues/93819). The VMWare Wasm Labs team is using a zlib port from [Singlestore](https://github.com/singlestore-labs/python-wasi) in [their Python Wasm runtime](https://wasmlabs.dev/articles/python-wasm32-wasi/). In WasmEdge, we could support the zlib host functions through our [plugin system](https://wasmedge.org/book/en/plugin.html). This way, any existing zlib apps can be compiled to Wasm and runs inside WasmEdge. - Expected outcome: Create a new [WasmEdge plugin](https://wasmedge.org/book/en/plugin.html) that exports all public functions in `zlib`. Implement SDK (in C/Rust) that uses the C ABI to generate corresponding headers for the above plugin. Generate the unit tests and pass the unit tests. >80% of code coverage for verification.
Description: Cluster API Provider AWS (CAPA) can create and manage the lifecycle of Kubernetes clusters in AWS (with the help of Cluster API in general). For each target AWS account where a user wants to create clusters it must be prepared for usage first. This is currently done using [clusterawsadm](https://cluster-api-aws.sigs.k8s.io/topics/using-clusterawsadm-to-fulfill-prerequisites.html) which creates/updates a CloudFormation stack that in turn creates/updates IAM resources. This approach has caused issues as CloudFormation is region specific but IAM is global and users often run the tool in different regions which results in failed stacks that cannot easily be deleted. As a project we want to move away from using CloudFormation and instead use API calls (like the rest of CAPA). We also want to make the process idempotent so it doesn't matter if you run it against different regions. This account preparation is key to CAPA and with out it CAPA cannot run. Expected Outcome: A new approach to handling the prerequisites required for CAPA. We need to continue to support the cli based approach (so clusterawsadm will be updated) but we can also explore a declarative approach with an operator.
Today, most users adopt Blockchain in order to collaborate with each other, however, it is difficult to manage a large blockchain network because of multiple organizations and nodes. Hyperledger Cello is aiming to resolve the following challenges, 1) Facilitate creation of blockchain network, can help user without blockchain background to setup their network nodes quickly. 2) Cross organization communication, can connect blockchain networks among multiple organizations. This project targets to design and implement a practical operational system equipping with decentralized functionalities to solve above challenges, based on Hyperledger Cello code base. Learning Objectives 1) Work closely with community experts and developers to learn the open-source culture and skills; 2) Learn the advanced knowledge inside the blockchain and distributed ledgers; 3) Practice hand-on experience with web application design and implement. Expected Outcome Help design and implement the blockchain operation dashboard and api server.
Description: Chaos Mesh is not like Chaos Engineering as a Service now: - Poor observability: the result of chaos experiments are not easy to observe and judge, the users need to check whether the Chaos effects by manual. - Chaosd(for physic node) is too simple: only supports command line operation, does not support task scheduling and life cycle management. - The costs of learning operation and maintenance are high: the maintenance of Chaos Mesh and Chaosd are not unified. - It should be a unified place to manage Chaos experiments for multiple platforms and multiple clusters, and can see the monitoring data of the experiment.
kpm is a package management tool for KCL. kpm currently lacks checksum verification for dependencies, so this part needs to be completed to support package integrity verification and package source verification Expected Outcome: Complete the workflow of adding checksum through `kpm` when uploading package and verifying checksum through `kpm` when downloading package
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. 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
With WASI-NN plugins, WasmEdge is well-suited for running AI applications. However, AI applications are more than just the model. The application must pre-process data (such as images, audio and video) into TFLite / PyTorch formats, and convert the inference results back into application data in post-processing. Here are some examples: * The [mediapipe-rs](https://github.com/WasmEdge/mediapipe-rs) project provides a Rust SDK to build applications for the mediapipe AI models. * The [llama2.c](https://github.com/karpathy/llama2.c) application is [compiled to Wasm and runs in WasmEdge](https://medium.com/@michaelyuan_88928/running-llama2-c-in-wasmedge-15291795c470) to generate text using the [llama2](https://ai.meta.com/llama/) models. In this project, we would like to build a Rust SDK to support applications on the [YOLO models](https://pjreddie.com/darknet/yolo/). - Expected Outcome: - A Rust SDK that implements the pre-processing and post-processing functions required for the YOLO models. Those functions are implemented in OpenCV and Python in the official YOLO release. - Both image and video inputs should be supported. - Examples and documentation should be provided. - Recommended Skills: - OpenCV - Rust - Tensorflow / Pytorch - WebAssembly
Istio is a service mesh platform used by thousands of companies to secure and manage their microservices traffic, most often in a single Kubernetes cluster. However, the ability to operate across multiple clusters is an important feature in Istio's traditional Sidecar mode, and work to support it in Istio's Ambient mode is making rapid progress. To call any feature complete, comprehensive testing is needed. Given that multicluster Istio Ambient is a new mode of operating, we will need to both adapt tests for existing features to ensure they work across multiple clusters, as well as identify multi-cluster specific scenarios we want to codify in tests. Expected Outcome: 1. Audit existing ambient integration tests for cases that do not support multi-cluster testing patterns. 2. Refactor those tests, using Istio's testing infrastructure to cover features within a multi-cluster environment. 3. Work with Istio maintainers to identify opportunities for testing new scenarios that exist only for ambient multi-cluster. 4. As documentation is written for https://istio.io, verify that the user instructions (kubectl commands, YAML snippets, etc.) actually work end-to-end. 5. Gain hands-on experience with Istio's codebase, service mesh architectures, and Kubernetes multi-clust......
This project focuses on enhancing the KubeStellar UI with WDS-related functionalities, allowing users to manage and deploy workloads effectively. Objectives: - Implement UI components for managing workloads in WDS. - Integrate real-time workload deployment tracking. - Enhance UI design for better user experience and usability. - Display visual indicators for workload placement across multiple clusters. Expected Outcomes: - A user-friendly UI for managing WDS workloads. - Real-time feedback on deployment status. - Improved visualization of workload distribution.
Jaeger (https://www.jaegertracing.io/) is an open-source, distributed tracing platform designed to monitor and troubleshoot microservices-based systems. Jaeger-UI is the web UI for Jaeger, built with React (https://react.dev/) . The current version of React used by Jaeger-UI is v18. This project aims to upgrade Jaeger-UI to React v19, in order to stay up to date with the dependencies. Expected Outcome: A working version of Jaeger-UI upgraded to React v19, with all the features and functionality of the current version. This may include a need to upgrade or replace some other dependencies that may not be compatible with the latest React.
Move2Kube is a command-line tool for automating creation of Infrastructure as code (IaC) artifacts. It has inbuilt support for creating IaC artifacts for replatforming to Kubernetes/OpenShift. Move2Kube has a very plugin friendly architecture, users can write custom logic in the form of "Transformers" that Move2Kube can integrate seamlessly into its transformation pipeline. So far we have support for both Starlark and container image based transformers. We would like to support writing transformers as WASM modules that Move2Kube can run. WASM provides extensive sandboxing for security, it allows writing transformers in different language stacks like Rust, C/C++, etc. other than Golang, and WASM is just as lightweight and fast as Starlark. - Expected Outcome: - Implement a feature in Move2Kube CLI to allow running WASM modules as custom transformers.
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.
Description: Vitess is a database clustering system for horizontal scaling of MySQL. One of the key goals of Vitess is to emulate MySQL behavior even while running multiple MySQL instances so that ORMs and frameworks work seamlessly. Vitess has its own in-built SQL-parser which it uses to understand the query and represent as structs for further processing. As of now, a lot of MySQL functions are not parsed correctly and result in syntax errors. Parsing for a lot of the newer features in MySQL 8.0 is also missing. The task of the mentee would be to add parsing support for such functions and features.
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