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.
This project aims to implement full coarray support in the LFortran compiler, enabling native parallel programming capabilities based on the Partitioned Global Address Space (PGAS) model defined in the Fortran 2008/2018 standards. Currently, while LFortran’s parser supports coarray syntax, the feature is not implemented beyond basic stubs, preventing execution of even minimal coarray programs. The project will bridge this gap by extending LFortran’s Abstract Semantic Representation (ASR) to model coarrays, implementing semantic analysis for coarray constructs, and introducing a dedicated coarray runtime library. A key component is an ASR-to-ASR lowering pass that translates high-level coarray operations (such as coindexed access, synchronization, and collective intrinsics) into runtime calls. This design follows LFortran’s existing OpenMP architecture, ensuring backend-agnostic support across LLVM, C, and other targets. The implementation will proceed in two phases: first, establishing a fully functional single-image mode with correct semantics and runtime integration; second, enabling multi-image execution using an MPI-based runtime backend. By the end of the project, LFortran will be capable of compiling and executing coarray programs in both single-node and distributed environments. This work lays the foundation for supporting real-world coarray-based HPC applications and positions LFortran as a leading LLVM-based Fortran compiler with modern parallel programming support.
The CICADA (Calorimeter Image Convolutional Anomaly Detection Algorithm) project aims to detect anomalous physics signatures without bias from theoretical models in proton–proton collisions at the Compact Muon Solenoid (CMS) experiment at the Large Hadron Collider. CICADA identifies anomalies in low-level calorimeter trigger data using a convolutional autoencoder, whose behavior is transferred to compact student models via knowledge distillation. Careful model design and quantization ensure sub-200 ns inference times on Field Programmable Gate Arrays (FPGAs). CICADA currently uses a distilled neural network model with layer-wise quantization to meet the strict sub-200ns latency required for the CMS Level-1 Trigger (L1T), trained using QKeras (a now-deprecated library for quantization-aware training). This GSoC project aims to enhance CICADA by integrating highly granular quantization (HGQ) techniques, which allow automatic, per-weight and per-bias quantization, providing finer control over model precision and resource usage. This project involves developing a HGQ version of the CICADA distilled model and evaluating its performance and resource consumption when deployed on a FPGA, while contributing to the open-source CICADA, HGQ2 and hls4ml frameworks as needed. Notably, the HGQ2 library is also compatible with JAX, opening the door for future integration with modern, hardware-friendly ML ecosystems. These contributions will benefit the broader fast machine learning community focused on deploying ML models in low-latency, resource-constrained environments.
This proposal aims to address the lack of support for histogram charts and other advanced chart types introduced in Microsoft Office 2016 within LibreOffice. Histograms are essential for data analysis, scientific research, and machine learning, providing valuable insights into data distribution. Currently, LibreOffice users rely on some clunky workarounds to create histograms, limiting productivity and compatibility with industry standards. The goal is to implement native histogram chart support in LibreOffice, eliminating the need for workarounds and enhancing the user experience. By leveraging the existing column chart implementation as a starting point, the project will gradually transform and extend the code-base to support histogram-specific functionality. This approach minimizes disruption to the stable code-base while introducing new capabilities.
Kyverno is working towards support of ValidatingAdmissionPolicy (CEL admission). Extend this support for other items such as CLI, reporting, and auto-generating ValidatingAdmissionPolicies from Kyverno policies. - Expected outcome: Extended support and integration with ValidatingAdmissionPolicies
LLMs rely on floating-point arithmetic for inference, but the Logarithmic Number System (LNS) offers a compelling alternative: multiplication becomes integer addition in the log domain, and 16-bit LNS (xlns16) uses only 2 bytes per element, half the memory bandwidth of float32. This project integrates the open-source xlnscpp C++ LNS library into ggml (the compute backend of llama.cpp) as a proper ggml_backend, enabling LLM inference to run entirely in xlns16 arithmetic as a proof of concept. The implementation introduces GGML_TYPE_LNS16 as a native ggml datatype and implements the 13 operations required for a complete transformer inference pass (matrix multiply, softmax, RMS norm, RoPE, SiLU, residual add, along with some others), all using xlns16 kernels. Activations stay in xlns16 format throughout inference; weights are converted dynamically from their stored quantised formats (Q4_K_M, etc.) per kernel invocation using O(1) lookup tables. The backend is validated at two levels: a unit test confirms sub-0.6% relative error on matrix multiply, and an end-to-end run on SmolLM2-135M-Instruct confirms the full transformer executes without crashing. Deliverables: (1) GGML_TYPE_LNS16 datatype registered in ggml; (2) a complete ggml_backend for xlns16 arithmetic covering all ops needed for LLM inference; (3) integration with llama.cpp; (4) a validation test suite; (5) an accuracy analysis comparing LNS and FP output across model layers
**Pwndbg** is a debugger extension that enhances the debugging experience. It currently supports only GDB and LLDB on Linux and macOS. This project introduces Windows support for Pwndbg. Initially, only WinDbg will be supported, but a generic interface could enable support for other debuggers (GDB, LLDB, x64dbg, etc.). The goal is to bring Pwndbg enhancements to the WinDbg console — providing a similar experience to using it with GDB or LLDB. End users should be able to access all native WinDbg features while also using Pwndbg commands and context windows. The project leverages WinDbg’s `wdbgexts` or `DbgEng` to interface with Pwndbg. This requires either an RPC client-server protocol or native integration of Pwndbg on Windows. Pwndbg needs to hook into WinDbg states (registers, memory, etc.) and respond to all command calls from WinDbg.
<p>Jupyter project provides a way to perform scientific/mathematical computations with several different programming languages using the same user interface. It achieves that by distributing the processing between a front-end (Jupyter clients, like the web based Jupyter Notebook) and a back-end (Jupyter kernels, written in Python, R, Java, etc.), that communicate among themselves with standardized format messages, transmitted through ZeroMQ connection.</p> <p>Besides the ability to switch across different kernels from the same common interface, another advantage of this approach is the possibility to run the two software components on different machines, e.g., offloading the heavier backend processing to a remote server while sending commands and visualizing data from a mobile device running the frontend.</p> <p>For Scilab, there is currently a kernel that uses a compatibility layer with file access data exchange and numpy calls to communicate with clients through the Python reference implementation.</p> <p>This Google Summer of Code proposal aims to adapt or rewrite the current suboptimal solution, to make it a truly native kernel, linking ZeroMQ messages directly to Scilab API.</p>
Move2Kube is a command-line tool for automating creation of Infrastructure as code (IaC) artifacts. It has built-in support for creating IaC artifacts for replatforming to Kubernetes/OpenShift. Currently we have support for resources such as ArgoCD, Tekton, etc. There is still a gap to be covered in the support Move2Kube provides. Example - enhance support for external transformers (GRPC, file/folder permissions, etc.). Expected Outcome: - More comprehensive support for Move2Kube advanced resources and other components.
Description: Use OCI References in image verification Expected Outcome: PR sent to kyverno/kyverno implementing support for OCI references in verifyImages rules
<p>This project focuses on implementing OpenCL support for Libavfilter, with other parts of the project (including scaling, color conversion and deinterlacer) being treated as optional improvements for FFmpeg.</p>
Enable Tremor to receive and send Syslog Protocol Messages (https://tools.ietf.org/html/rfc5424), supporting as many Syslog implementations as possible that might deviate from the standard
OpenELB is an open-source load balancer implementation designed for exposing the LoadBalancer type of Kubernetes services in bare metal, edge, and virtualization environments. Currently, OpenELB supports the BGP protocol. However, the BGP policy is not fully supported in OpenELB. Therefore, based on the BGP protocol, OpenELB is supposed to support the BGP policy to enable leveraging the GoBGP policy feature for controlling the route advertisement.
<p>Currently, mypy and mypyc are unable to recognize uses of the singledispatch decorator, making mypy generate false positives and mypyc generate incorrect or slow code when it is used. This project would improve both of these problems by adding special support for singledispatch in mypy and mypyc.</p>
<p>The task is to create software support for FPGA cape (based on iCE40 device). The completed project will provide the BeagleBoard.org community with easy to implement and powerful tools for realization of projects based on Programmable Logic Device(FPGA), which will surely increase the number of applications based on it.</p>
<p>This is a proposal to add serialization and deserialization support for TOML in the functional configuration language Dhall. TOML is a relatively new configuration language that is easily human readable, supports dates and times, and is unambiguous. The biggest users of TOML are Rust’s Cargo, and consequently many Rust programs read TOML. Adding support for TOML in Dhall would mean users do not have to choose between readability and the power to program their configurations.</p>
<p>Kodi codebase is written in C++ which is dynamically converted to Python through SWIG and Groovy. In this project Python 3 support is to be added for Kodi add-ons and updating the Kodi built-in libraries by changing the custom Python templates provided as an input to Groovy and updating the calls to threads and sub-interpreters as per Python3 C API.</p>
<p>Add support for timeless debugging in r2. This requires r2 to create tracing session and read, write memory at any moment in tracing sessions. Same for registers.<br> Add new reverse execution commands, like ‘dsb’, that may read previous tracing sessions, and seek program counter to backward. And moreover, r2 should load recorded tracing sessions from tools like, rr or QIRA.</p>
<p>WebDriver is a remote control interface that enables introspection and control of user agents. Currently, Servo supports only a minimal subset of the WebDriver protocol. The goal of this project is to extend this support and pass the conformance tests to demonstrate the implementation's correctness. Additionally, the project also aims to support running WebDriver-based automated tests like the WebBluetooth test suite, which require complex browser control and automated interactions that WebDriver provides.</p>
<p>Matlab Simulink is an advanced tool for simulating physical systems. Adding support to ArduPilot will allow for greater depth of understanding of both the ArduPilot control systems and the behavior of the simulated vehicle. This understanding can be used to improve the control systems of ArduPilot and test behavior without risking a real vehicle. It is hoped that this will allow the implementation of more advanced control systems tailored to particular vehicle types.</p>
PostgreSQL extensions can offer detailed views of query performance, storage usage, and system health but this would need frequent manual setup to be used with monitoring systems. Our proposal improves upon pgexporter through automatic detection of supported extensions and the output of pre-configured metrics for vital extensions such as pg_stat_statements, pg_buffercache, and pg_stat_monitor. It allows easy observability, diminishes the role of manual setup, and helps for optimal data-driven database performance monitoring.
The problem I am trying to solve is to add ARM support. Right now, when the CircleCI pipeline is triggered, it pushes a Docker image that only supports the AMD64 architecture and does not support ARM architecture. I plan to solve this issue by using Docker's buildx functionality to build multi-architecture images. As a deliverable by the end of the tenure, we will have a shell script which, when run, will execute the circleci/config.yml associated with the repository. This will result in the creation of maintainable and portable code.
This project aims to improve Git-based collaboration in JabRef by building a reliable synchronization layer for BibTeX files. It treats Git changes as edits from remote collaborators and introduces support for conflict detection, a guided merge UI, and safe synchronization workflows. Key deliverables include a modular GitSyncService, a conflict resolution interface, integration with JabRef’s save flow, and secure credentials management. The result will be a smoother, more collaborative experience for researchers using version control in their bibliography workflows.