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.
<p>A Module System for C++ is on its way to the C++ standard.</p> <p>The current state of the Module System, although fairly stable, it has a few bugs for C++ support. The most common reason for the bugs is the semantic merging of C++ entities. Currently, the method for ensuring no regressions is a buildbot for libc++, which builds llvm in modules self-hosted mode. Its main purpose is to find bugs in clang’s implementation and ensure no regression for the ongoing development.</p> <p>Since the Module Systems is meant to be generic, the project aims to improve the stability and coverage of the Module System by finding as many issues as possible. One approach is to add a buildbot for libstdc++, because this would change the merging model for the modules, and in this way, it will point out different issues which would not be observed by using libc++. The choice for libstdc++ is motivated by its wider use in Unix and, more importantly, the benefits it will bring to supporting modules for third party projects that rely on libstdc++.</p>
Cacti provides modules, toolkit, and protocols to enable networks built on distributed ledgers to interoperate and carry out transactions spanning their boundaries, such as asset transfers, asset swapping, and ledger data communication. For ease of building DLT-agnostic protocols in Cacti, we need to build modules corresponding to various DLTs supported by Cacti that implement these core operators and expose them using a standard API. The goals of this project are as follows: 1. Design and build DLT-specific core operator modules for Cacti by leveraging existing Cactus or Weaver packages. This involves identifying building blocks of unique features in either, and integrating legacy Cactus and Weaver packages wherever they offer a common feature. 2. Design and implement a common DLT-agnostic API, following the OpenAPI standard, using which any DLT-specific core operator module can be invoked by application-specific business logic on-demand. 3. Add suitable API support within the common Cacti client API for ease of application development 4. Do a research survey of existing blockchain/DLT literature to identify a potentially exhaustive set of core operators any DLT network must possess (or harness) to interoperate with other networks.
Maglev is OneBusAway's next-generation, high-performance Go REST API server designed to replace the legacy Java architecture. To achieve full production readiness for real-world transit agency deployments, this project focuses on four core deliverables. First, it ensures strict 1:1 API parity through automated, field-by-field output validation against the legacy server integrated directly into CI. Second, it executes a complete Go rewrite of the GTFS merge and transformer modules, creating native CLIs that enable runtime multi-feed loading directly into Maglev. Third, the project integrates the GTFS-Flex specification to support demand-responsive paratransit services, and finally, it expands the existing GTFS-RT pipeline to handle real-time structural trip modifications. Together, these enhancements will transform Maglev from a fixed-route Western transit tool into a globally deployable platform capable of serving diverse transit ecosystems across South Asia, Africa, and Latin America.
Mifos is moving toward a more modular architecture, but many large modules still rely on direct dependencies, which makes the codebase harder to maintain, test, and evolve. This project aims to address that problem by introducing an event-driven approach for stand-alone modules, using Spring’s application event publisher to replace one-way direct calls wherever possible. The goal is to reduce tight coupling between modules, especially in areas such as loan, savings, and group support, so that modules can become more independent and easier to package, reuse, and publish separately. The project will focus on identifying suitable direct dependencies, designing event-based replacements, implementing publishers and listeners, and validating that the new flow works cleanly without breaking existing behavior. The final deliverables will include the architectural changes needed to support event-driven communication, working implementations for selected module interactions, tests and documentation for the new design, and clear guidance for extending this pattern across the Mifos platform in the future. The broader outcome will be a cleaner and more scalable modular foundation for Mifos, making it easier for the community to build and maintain true stand-alone modules over time.
<p><a href="https://projects.freifunk.net/#/projects?project=libremesh_librenet6_integrations&lang=en" target="_blank">https://projects.freifunk.net/#/projects?project=libremesh_librenet6_integrations&lang=en</a></p> <p>LibreMesh already does extensive use of IPv6 technology, we even have an IPv6 mesh tunnel broker provider based on Tinc VPN. It works very well but configuring the tunnel is a manual work that requires specific skills which are not common in the majority of communities. Because of this, communities often are not taking advantage on IPv6 while their routers already support and make good use of it. To improve this situation the student should design a semi-automatic system to grant access to trusted routers to LibreNet6 (this may include key exchange) and code a tiny LiMe module that take care of tunnel configuration.</p>
<p>In this project, we will extend netifd by a generic device handler interface, which is exposed via the ubus IPC system to enable interaction with external device handlers. In other words, the goal is to decouple the device management functionality from netifd to other separately maintained device managers to allow both sides to evolve independently. Moreover, the decoupling will allow netifd to manage devices of types which may even be unknown to netifd without the need to change the central UCI network device configuration in /etc/config/network. In this project, we will present a basic proof-of-concept module which outsources the control over Open vSwitch in OpenWrt to an external device handling entity. Specifically, we will realize a small daemon acting as a relay between the ovs command line tools and netifd's ubus device handler interface. Native support of Open vSwitch in OpenWRT will open a wide range of different use-cases.</p>
The IEEE 802.11 specification for Wireless Local Area Networking (WLAN) has been widely deployed worldwide due to its low cost and convenience in providing internet access. As such, the performance of WiFi networks is far from optimal, especially when multiple participants share the same channel in an uncoordinated manner. Hence, resource allocation in wireless transmission plays a vital role in optimizing the throughput of a link. The aim of this project is to implement a joint power and rate controller in user space using the Rateman Python package. As a rate control algorithm in user space has already been developed at SupraCoNeX, namely "py_minstrel_ht", this variant of Minstrel-HT can be extended with power tuning capability to better manage interference and increase spatial reuse. In general, the proposed joint controller will consist of a power tuning module that tweaks the power level of the set of best rates, selected by the Minstrel-HT, to an optimal value. Furthermore, the joint controller could also be extended to support modes such as fixed power and low power.
This project will build friendly automation tooling to support community translation of the p5.js reference documentation (including p5.js core and p5.sound). The p5.js reference (API documentation) is authored in English via JSDoc comments in the source code, and the website currently offers documentation in five languages (English plus Spanish, Simplified Chinese, Korean, and Hindi) . As p5.js evolves, keeping these translations up-to-date is challenging. The goal is to create GitHub Actions and workflows that do not automate translation itself (which requires human nuance) but instead assist volunteer translators. These tools will automatically track changes in the English “source” docs, flag or open tasks for updates in other languages, suggest new translation needs (for newly added APIs), and streamline communication with translation contributors.
Currently, the wild linker has limited support for linker scripts, which are commonly used in the Linux Kernel and embedded development. This makes it nearly impossible to use the wild linker for any Linux or embedded development. This proposal lays down a suggested path to try and implement most, if not all the major features requested for Linux kernel module support.
The goal of this project is to improve the netjsongraph.js visualization library, which has not been released yet. This project aims to improve the geographic map feature by revamping the UI, fixing the zoom animation, implementing a clustering feature to the nodes on the map and making it looks good on narrow screens. The project also aims to add support to GeoJSON in netjsongraph.js library.
ESP-Website administrators currently manage program modules manually with no way to pre-schedule transitions, causing configuration errors that risk corrupting student registration data. This project builds a visual, Gantt-style Module Management UI that lets administrators schedule module open/close windows on a drag-and-drop timeline canvas, with separate student and teacher views, real-time conflict detection, and a time scrubber to preview the student experience at any point. On the backend, ProgramModuleObj will be subclassed from ExpirableModel to add native time-windowing, and five AJAX endpoints will power all frontend interactions. Deliverables include the model migration, time-aware module filtering, the timeline canvas UI, a module picker side panel, full WCAG 2.1 AA accessibility, and bidirectional integration with the existing module questions interface.
The project will involve creating adding a support for Android Os and Android Auto in the existing Organic Maps Android App. And the code for both these features will be shared , so if an car supports Android Os the application will run in the Android Os or if it is not supported the app can still work using the support for Android Auto
Arianna ebook reader uses the epub.js, which is no longer actively maintained. This creates a challenge as the epub.js may not be able to keep up with the evolving standards and new changes. To address this issue, the proposed solution is to port Arianna to the Foliate-js, which is an actively maintained epub renderer and has more features compared to epub.js and is used by the Foliate ebook reader.
Goal: ○ To add a Terraform module for SkyWalking deployment to facilitate users in conveniently spinning up a cluster for demonstration or testing. ○ To allow users to customize the Terraform provider according to their needs, making it feasible for them to use it in their production environment. ○ To mainly focus on the support for AWS in the Terraform module for SkyWalking deployment. ○ To provide a hassle-free solution to users where they only need to provide their access key/secret key, and the Terraform provider does the rest of the work, which includes creating VMs, creating database/OpenSearch or RDS, downloading SkyWalking tars, configuring the SkyWalking, and starting the SkyWalking components (OAP/UI), creating public IPs/domain name, etc.
Developers are enthusiastic about leveraging Java's latest language features, which offer more powerful, declarative, and expressive code; these features include unnamed variables, record patterns, and string templates. However, Checkstyle currently lacks robust support for these features. This project aims to bridge this gap by updating existing checks and potentially introducing new ones to ensure thorough coverage of Java 21 syntax and conventions proposed by the JEPs associated with these language advancements. The objective is to deliver comprehensive support for the new language features through revising check modules, exhaustive testing, and detailed documentation updates. This effort not only aligns Checkstyle with cutting-edge best practices in the Java community but also contributes to the project's ongoing evolution.
As the LLVM Flang frontend matures, a significant gap has emerged between compilation and diagnostic capabilities. Currently, LLDB does not provide native debugging support for Fortran. This project aims to address that gap by building the essential foundation for native Fortran debugging. The goal is to deliver a functional debugging stack that allows users to: Inspect Variables: Support for scalar variables, function arguments, and return values. Data Structures: Inspection of static arrays, character strings, and derived types. Visibility: Implementation of module and global variable lookups. Expression Evaluation: Enabling basic arithmetic and variable inspection via the print command. To achieve this, a new Fortran TypeSystem, a dedicated Language Plugin, and a DWARFASTParser to interpret and traverse Fortran-specific DWARF metadata are needed.
Developers are enthusiastic about leveraging Java's latest language features, which offer more powerful, declarative, and expressive code; these features include Flexible constructor bodies (JEP 513), JEP 512: Compact Source Files and Instance Main Methods. However, Checkstyle currently lacks robust support for these features. This project aims to bridge this gap by updating existing checks and potentially introducing new ones to ensure thorough coverage of Java 25 syntax and conventions proposed by the JEPs associated with these language advancements. The objective is to deliver comprehensive support for the new language features through revising check modules, exhaustive testing, and detailed documentation updates. This effort not only aligns Checkstyle with cutting-edge best practices in the Java community but also contributes to the project's ongoing evolution
<p>This project focuses on implementing an asynchronous mechanism for model inference and batch execution in the TensorFlow backend of the FFmpeg Deep Neural Network module to boost model inference performance.</p> <p>The Tensorflow backend uses the TensorFlow C API, which currently does not provide functions for asynchronous execution. The support for async behavior can be provided using multithreading on the existing TensorFlow library functions. We will implement this behavior through detached threads that work independently of each other.</p> <p>Several inference frames will be combined to a single input tensor and executed together in a single batch to enable the batch mode. The DNN module authors saw a performance gain in the OpenVino backend with asynchronous batch inference against synchronous inference. A similar performance gain is expected from this project.</p>
Clang includes libInterpreter, a framework for incrementally JIT compiling and executing C++ code. The goal of the project is to port this to WebAssembly and run inside a Javascript engine in a browser. This would involve modification to libInterpreter to run in WASM and produce WASM JIT code. These separate WASM modules need to be linked together and executed in the JS engine. If possible, the final goal is to integrate this with JupyterLite, a version of Jupyter that runs WASM kernels entirely on the client side.
Embedding p5.js sketches on different platforms can be tricky because some sites block scripts, remove iframes, or require a specific format. This project will create an easy-to-use embed generator that lets users customize their embeds without writing any code. It will support both Global and Instance Mode, making it flexible for different coding styles. Users can adjust the size, background color, playback options, and whether the code is editable or locked, all through a simple interface. To make things even easier, the tool will include smart platform presets, so users can generate the right embed code for platforms like WordPress, Medium, Notion, and static site builders. A live preview will show exactly how the embed will look before copying the code. This project will remove technical barriers, making it simple for teachers, artists, and developers to share p5.js sketches anywhere.
This project involves working with Capa, a tool which detects capabilities in executable files. The rationale behind the project is that, current static analysis tools often struggle with scripting languages because of its reliance on fragile regular expressions that can be easily evaded . So, this project aims to extend the capa engine to natively support the static analysis of scripting languages using Tree-sitter. I plan to solve it by working towards the merging the tree-sitter implementation pull request. Once it is merged, I plan to extend the tree-sitter to support more languages of which Bash and Powershell are in my priority list. Then, I will extend the feature extraction of the tree-sitter to have more detailed analysis. Next, I plan to write the capa rules which would verify the integration. Also, I will add relevant documentation for ease of developers and contributors. I plan to deliver all the goals mentioned above within the 12 weeks timeline. Beyond GSoC, I plan to stay involved by contributing code, reviewing pull requests and participating in community discussions.
<p>Kuadrant's MCP Gateway is an Envoy-based gateway for Model Context Protocol (MCP) servers that provides routing, policy enforcement, and tool federation. As the agentic ecosystem grows, we're looking to extend the gateway's capabilities beyond MCP to support other agentic protocols. The A2A (Agent-to-Agent) protocol is an emerging standard for inter-agent communication with capabilities like long-running tasks, streaming, and agent discovery via agent cards. This project will investigate how A2A support can be added to the gateway alongside MCP, then build a proof-of-concept demonstrating federated agent discovery and A2A request routing through the gateway. The mentee will work closely with mentors throughout — collaborating on the design doc, pairing on implementation decisions, and spiking on specific pieces as needed to validate assumptions early. They will also engage with the broader Kuadrant community through PR reviews, design discussions, and community calls.</p><p>- Expected Outcome:</p><p> - Analysis of the A2A protocol with a gap assessment comparing A2A and MCP traffic patterns (request/response vs long-running tasks, push notifications, multi-modal artifacts)</p><p> - Design document covering A2A routing through ext_proc, federated agent card serving in the broker, session handling implications, and CRD design</p><p> - Federated agent card endpoint in the broker that aggregates upstream A2A agent cards</p><p> - A2A request routing through the Envoy ext_proc path, with appropriate header handling and policy enforcement</p><p> - CRD design (new resource or MCPServerRegistration extension) for registering A2A agents with the gateway controller</p><p> - E2E tests demonstrating A2A agent discovery and task execution through the gateway</p><p><br></p>
<p>The aim of this project is to write a working Demo for the Matlab Mex modules present in Scilab. The Matlab MEX-Files is an API which is a wrapper on the current API Scilab. This would make it very easy to port existing Matlab Mex toolboxes into Scilab. A module - mexlib module already exists in Scilab which is compatible with the Matlab-Mex API. Currently the mex support for Scilab is good but there is a lack of a concrete demo. Thus, it is necessary to have a working demo for Mex within Scilab.</p>
This proposal outlines the development of create-webpack-app, a webpack cli tool designed to streamline project setup for web development. Leveraging the power of Webpack, create-webpack-app will provide a user-friendly interface for selecting frameworks like React, Vue, or Svelte. Users can then generate a complete project structure pre-populated with essential files, configurations, and a tailored Webpack configuration for both development and production builds. The planned 12-week development utilizes Plop.js to create reusable templates, ensuring flexibility and customization. A core base template will be established, containing essential project files like package.json, README.md, and a foundational webpack.config.js. This will be complemented by framework-specific templates pre-filled with boilerplate code relevant to the chosen framework. Additionally, comprehensive user documentation will be created, guiding users through installation, usage, and framework-specific considerations. By prioritizing a lightweight and customizable approach, this proposal lays the groundwork for future enhancements, including broader framework support and potential community contributions.