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.
Pwndbg delivers a powerful debugging experience on traditional Linux systems, but its support for Android environments remains limited. This is largely due to fundamental differences between GNU libc and Android’s Bionic, as well as the lack of tooling for Android-specific components such as Binder. As a result, many existing features either do not work as expected or provide limited insight when analyzing Android binaries. This project aims to address these limitations by introducing structured and practical support for Android within Pwndbg. It will extend existing features to correctly handle Bionic internals, particularly in memory inspection and heap analysis, and improve Binder support by enabling meaningful userspace inspection. Additionally, the project will refine internal abstractions to ensure consistent behavior across LLDB and GDB.
The plasma module is used to determine the ionization and excitation states of the supernova ejecta using the basic structure of the supernova (elemental abundances, densities, radiation temperature). As described in the project description in the GSOC project page, CodeCov does not accurately report coverage of the TARDIS plasma. This is because the plasma module is used as a parameter for models and simulations, and is therefore indirectly tested by the tests of the simulation and model functions. While there are parts of the plasma module that are tested directly, many aspects of the module have no easy to find direct tests. This project aims to increase the test coverage of the plasma module and make the tests of the plasma modules easy to find and read.
LiquidHaskell is a verification tool that allows Haskell developers to prove the correctness of their code through refinement types. This proposal aims to restore the support for type class elaboration: a feature that enables the verification of typeclasses laws and instances. The work that had been done previously to support typeclass elaboration is currently broken: typeclass methods produce "Unknown logic name" errors, hence the test suite for the feature has been disabled. The aim of this project is to restore this functionality, by fixing the elaboration mechanism responsible for making typeclass methods available during verification. I will trace the elaboration pipeline, implement the necessary fixes and extend test coverage. Additionally, the project will include an in-depth analysis of the features supported by the implementation and how they compare against the expected outcomes in the original paper. The deliverables will include successfully merged contributions on the LiquidHaskell GitHub repository, with its corresponding documentation, and a post with the solution on the Tweag blog.
KomaMRI.jl is a Julia package for Magnetic Resonance Imaging (MRI) simulation focused on speed and extensibility. Like other MRI simulators, it solves the Bloch equations, for which the solution can be parallelized due to the independent spin property of the system. Although KomaMRI currently has built-in support for GPU and CPU parallelization, GPU support is CUDA-based and could be extended to work with different GPU backends. In addition, writing GPU kernels tailored for the solution implementation could significantly improve performance compared with the current array-based approach. The goals for this project are to update the KomaMRI.jl package to support Metal, AMD, and OneAPI-based GPU backends, and create a new BlochKernel simulation method which is fully kernel-based and optimized. If time permits, the use of MPI.jl and Distributed.jl to run MRI simulations across multiple nodes and GPUs will also be explored.
The ENIGMA project uses a hierarchy of objects to represent entities. These objects are serialized and deserialized using (de)serialization routines implemented for them. However, the current implementation is not very clean as it checks the type of each argument against an if-else ladder, making it difficult to read and extend. This project aims to make the serialization framework easier to use and extend by changing the way the serialize, serialize_into and deserialize functions work to dispatch to supported types implicitly without the need for an if-else ladder. And the project also aims to implement support for additional data types like generic routines for map, vector and complex numbers. This would enable more easily serializing ENIGMA's internal state for use in sending state either across a network or into a file. Additionally, the project aims to introduce support for the JSON format within the serialization system, offering it as a new option alongside the existing bytes format. This addition enhances the readability and debugging capability of the serialized data.
<p>In this project, I am trying to implement some deep learning modules which are used for classification. I am trying to implement some important modules like Radial Basis Kernel SVM, Radial Basis Function Network and Deep belief Nets.<br> Deep belief nets:- They are probabilistic generative models that are composed of multiple layers of stochastic, latent variables. The latent variables typically have binary values and are often called hidden units or feature detectors.</p> <p>Radial Basis Function Network:- It is an artificial neural network that uses radial basis functions as activation functions. The output of the network is a linear combination of radial basis functions of the inputs and neuron parameters.</p> <p>Radial Basis Function Kernel:- It is also called the RBF kernel, or gaussian kernel, is a kernel that is in the form of a radial basis function (more specifically, a Gaussian function).</p> <p>We can use these deep learning classification modules for various purposes like speech recognition, handwriting recognition, biometric identification, document classification etc.</p>
<p>The idea is to implement cloud support in ScummVM. Users would be able to sync their save files and download game data from different cloud storage services on all their devices.</p> <p>At least these cloud services would be supported:</p> <ul> <li>Dropbox;</li> <li>Box;</li> <li>OneDrive;</li> <li>Google Drive.</li> </ul> <p>All of them use OAuth2 and provide an API to manage user's files.</p> <p>Things to be implemented:</p> <ul> <li>GUI for user to interact with;</li> <li>more or less portable way to open a link in a browser (for OAuth);</li> <li>more or less portable way to run a local webserver (for OAuth);</li> <li>portable (using libcurl) API interaction for all supported cloud services.</li> </ul> <p>Possible mentors: <a href="http://scummvm.org/index.php/User:Sev" target="_blank">Eugene Sandulenko</a>, <a href="http://scummvm.org/index.php/User:Uruk" target="_blank">Peter Bozso</a>.</p>
According to the Google Summer of Code (GSoC) project ideas listed for One proposed DeepChem project involves adding support for the OLMo Large Language Model (LLM) family to the DeepChem repository using the Hugging Face Model wrapper. The goal of this project is to enable DeepChem users to perform tasks such as text generation, classification, and continued pretraining with large language models, including Open Language Model (OLMo). I have already contributed several improvements to DeepChem’s HuggingFaceModel integration, including improving typing and validation for the fill mask method and implementing a new generate() function that wraps HuggingFace’s text generation API. I have also already demonstrated partial compatibility with OLMo models through recent contributions to the generate() function and example scripts using allenai/OLMo-1B-hf. I have also added support for causal language modeling in the HuggingFaceModel wrapper, including integration with AutoModelForCausalLM and end-to-end validation through unit tests. My contributions demonstrate familiarity with the DeepChem codebase and provide the foundation for extending DeepChem to support large language models such as OLMo.
<p>KDE Connect has recently launched an SMS Messaging app for the desktop which uses KDE Connect to synchronize all the existing conversations from the remote device. In its current state it can:- Show a list of existing conversations and the corresponding conversation history. Send and display SMS. Send SMS to only existing contacts and conversations on the remote device. Display (not send) group messages. However, It is very limited to MMS and can only support showing text. It cannot send and display pictures, audio, video and other kinds of attachments, also users cannot reply to multi-target conversations. Considering the importance of sharing multimedia files and group messages, the SMS client becomes very limited in use. This project aims to improve MMS support with the integration of sending multi-target MMS by re-working the current implementation of sending SMS and UI support using Qt Multimedia library. By the end of this project, SMS client will be capable of sending and receiving MMS, will be able to send multi-target MMS with the capability to view pictures, video/audio in SMS app and the capability to download attachments.</p>
<p>Graal produces analysis related to code complexity, quality, dependencies, vulnerability and licensing and the data produced conforms to the ones that can be processed by GrimoireLab. I will mainly be focusing on:</p> <ul> <li>Adding support of source code related metrics to Grimoirelab with the help of analysis data produced by Graal. </li> <li>Adapting Grimoirelab toolchain to be able to execute Graal and process the data produced by it.</li> <li>Writing appropriate unit tests for additional backends, their corresponding supporting connectors, and methods.</li> <li>Producing analytics related to proposed and calculated metrics* ( described below )</li> <li>Adding documentation related to additional features and improvements in existing ones.</li> </ul> <p>Out of all the five backends provided by Graal, CoCom (Code Complexity) covers a vast majority of the popular languages and CoLic (Code License) supported by NOMOS & ScanCode helps us fetch license & copyright related information from software development repositories and is language independent. Addition of metrics related to these two backends during GSoC period could be applied to a wide range of projects in the future.</p>
RustCloud unifies cloud provider APIs for Rust developers, but Generative AI support is completely missing. Every GenAI provider uses a different auth model, API style, and request format, forcing developers to maintain separate HTTP clients for each one. Rust has no equivalent of Python's LiteLLM or LangChain. This project delivers concrete LlmProvider implementations for AWS Bedrock, GCP Vertex AI, and Azure OpenAI, a complete GCP BigQuery module, a UnifiedLlmClient with Explicit/ModelBased/Fallback routing strategies, RetryMiddleware with exponential backoff, and a full test suite targeting 85%+ coverage with complete documentation. I have been contributing to RustCloud since March 2026 with 19 PRs across all four cloud providers, including working proof-of-concept implementations of all three GenAI providers and the routing layer. The GSoC period is where these drafts become production-quality, tested, and merged modules.
<p>This project will explore extending a new feature for the Performance Co-Pilot (PCP). PCP is an open source framework at the system level that monitors, analyze and retrieve information to understand system performance. It has a distributed architecture of agents, called Performance Metric Domain Agents (PMDA), that extract performance values from the desired environments or systems.</p> <p>Every agent (PMDA) reports to a centralized daemon called Performance Metric Collection Daemon or PMCD per host. Then, accessing any metric is as easy as sending a request to PMCDs. PCP has several client tools to help the final user understand the metrics. Finally, PCP also offers a good API to create an agent for any software.</p> <p>Coming back to the interest of the proposal, PCP also supports instrumentation. This is a way to enable user applications like Firefox to send metrics in execution time to the PMDA. In this scenario, Memory Mapped Values (MMV) are used to offer an extremely lightweight mechanism for instrumenting applications using shared memory. However, there is no support for metadata labels added since the newest v4, and hence the goal of this project: add label support for instrumentation.</p>
This project focuses on extending the imputeTestbench R package to better support modern time series data. The current package works well for univariate data, but many real-world datasets are multivariate, where multiple variables evolve together over time and may have structured missing values. The main goal is to add support for multivariate time series while keeping the package simple, stable, and fully compatible with CRAN. The project will introduce methods to handle multivariate inputs, simulate realistic missing data patterns such as block missingness, and improve benchmarking so that imputation methods can be evaluated both per variable and in aggregated form. In addition, the project will improve performance through efficient data handling and optional parallel processing using CRAN-safe approaches. The internal structure of the package will also be refined to improve readability, maintainability, and future extensibility. The expected deliverables include multivariate input support, structured missing data generation, improved benchmarking functions, optional parallel execution, and updated testing and documentation. These improvements will make imputeTestbench more useful for real-world applications such as environmental data, energy systems, finance, and sensor-based monitoring.
<h3>Summary</h3> <p>This project aims to implement Node Labeling and Preemption API, which are existing feature of resource managers, on REEF. Node Labels allow users to group resources with similar characteristics or with similar ACL policies and Preemption is a way to respect elasticity and SLAs together.</p> <h3>The Project</h3> <p>Even though YARN and Mesos, the resource managers have existing features that supports Node Labeling and Preemption, REEF doesn’t have APIs that makes these features available. To make developers can exploit these features on REEF regardless of which resource manager they use, APIs that make available Node Labeling and Preemption will be implemented on REEF in this project.</p> <h3>Required Deliverables</h3> <ul> <li>Support for the Node Labeling API as it exists in YARN and Mesos in REEF</li> <li>Support for the Preemption API as it exists in YARN and Mesos in REEF</li> </ul> <h3>Benefits for REEF</h3> <p>When Node Labeling and Preemption has been done in REEF, developer can exploit these features without directly dealing with resource managers such as YARN or Mesos, but through the same interface on REEF. It will increase portability and simplifies development of applications for cluster resource managers.</p>
<p><strong>TensorFlow Lite Flutter Support Suite</strong> is a cluster of three projects TfLite Flutter Plugin, TfLite Flutter Helper library, Flutter example ML app along with a tutorial.</p> <p><strong>TfLite Flutter Plugin</strong> provides TfLite JAVA like dart API to perform inference in flutter apps. The plugin is built on the top of the existing dart bindings and binds to TfLite C API using dart:ffi.</p> <p>View <a href="https://github.com/am15h/tflite_flutter_plugin/" target="_blank">am15h/tflite_flutter_plugin</a> & <a href="https://pub.dev/packages/tflite_flutter" target="_blank">tflite_flutter on Pub</a></p> <p><strong>TfLite Flutter Helper library</strong> aims at providing an interface to easily use high-level objects involved in Image, Text, Audio processing with TfLite Flutter plugin, and related utility functions in addition to similar functionality as the TensorFlow Lite Android Support Library.</p> <p>View <a href="https://github.com/am15h/tflite_flutter_helper/" target="_blank">am15h/tflite_flutter_helper</a> & <a href="https://pub.dev/packages/tflite_flutter_helper" target="_blank">tflite_flutter_helper on Pub</a></p> <p>A comprehensive and detailed <strong>Flutter example ML app</strong> demonstrating the combined efficient usage of the TfLite Flutter plugin and TfLite Flutter Helper package together will be published with a detailed tutorial.</p> <p>View <a href="https://github.com/am15h/object_detection_flutter/" target="_blank">am15h/object_detection_flutter</a> & <a href="https://medium.com/@am15hg/real-time-object-detection-using-new-tensorflow-lite-flutter-support-ea41263e801d" target="_blank">blog</a></p>
Proposal Summary: Interaction to Next Paint (INP) Subparts Problem Statement: The recently introduced Interaction to Next Paint (INP) metric, integrated into the Core Web Vitals (CWV) system in 2024, aims at measuring user interaction performance. However, INP lacks granularity, making it difficult for developers to diagnose and address specific latency issues within different stages of event processing and rendering. Solution Approach: To enhance the diagnostic capabilities of INP, this proposal suggests breaking down the INP metric into its sub-dimensions—input delay, processing time, and presentation delay—by leveraging modifications to Chromium’s Event Timing API. These fine-grained timestamps will be transmitted from the Renderer process to the Browser process via Mojo IPC, eventually integrating these metrics into the UKM metric system and CrUX experimental dataset. The project will involve updating the PageLoadMetricsSender to include detailed timing data for each event, as well as enhancing the UkmPageLoadMetricsObserver to handle both old and new data formats seamlessly. Deliverables: 1. Prototype Verification: Establish a proof-of-concept for collecting sub-dimension data using Chromium’s debugging environment. 2. Mojo Protocol Modification: Extend existing IPC interfaces to support new subpart timings. 3. UKM Integration: Implement new UKM metrics reporting and update relevant configurations. 4. Test Suite Development: Develop comprehensive tests including Web Platform Tests/WPT cases and unit test coverage. 5. Performance Regression Testing: Analyze benchmark reports and memory usage to ensure no negative impact on performance. 6. Documentation & Wrap-up: Provide detailed design documentation and outline plans for integrating improvements into CrUX.
<p>The project mainly concentrates on automating the module site for collecting information about modules from all over Terasology organization and display their generated information on the module site it also focuses on migrating the web presence and it will include working on frontend layout and improving the UX and UI of the module site.</p>
<p>The p5.js website has all the features but it lacked Translation features. In this project, I have added the new translation feature to the P5.js website. Due to internationalization (i18n), the p5.js website is built from templates that retrieve the text content from data files. The entire site is built with Node JS, Handlebars, and Grunt. There are three kinds of pages and each works differently: References, examples, and other web pages. References Pages are built-in English and swapped to other languages using JS on the front-end. Translation content is stored in a JSON object. For every new page, we need to create a key-value pair in the hi.yml file. A single JS template is also needed. Examples pages are built from templates with handlebars, while examples are stored in JS files. To implement i18n, new templates were created specifically for the Hindi language, so that Examples were rendered properly. Other pages are built from templates in which Handlebars point to the content in the actual language when rendered.</p> <p>The entire website is deployed and it is live at <a href="https://p5js.org/hi/" target="_blank">https://p5js.org/hi/</a></p>
<p>With the move of the Hedera's code base to Hiero, the project expanded significantly in scope. The SDKs that are currently available are all coming with the limited scope to Hedera and the Hedera network. Additionally, some of the SDKs are not created in the best possible way for the underlying programming language. Therefore, SDK usage is from time to time hard to understand and developers often run into issues. With all the changes to Hiero over the last year, including the modularization of the consensus node and the support for custom services and transactions, the architecture and public API of the SDKs is outdated in several ways. While we want to provide a great developer experience for our users, the current SDKs are not suitable for the future.</p><p>Based on all these factors, we started to invest in prototyping a possible new architecture and API for the future of our SDKs. That work is currently named "SKD V3" and happens in the <a href="https://github.com/hiero-ledger/sdk-collaboration-hub" rel="noopener noreferrer" target="_blank" style="color: rgb(9, 105, 218);">SDK collaboration hub of Hiero</a>. We currently define language agnostic APIs and language best practices for architecture and APIs of the future SDKs. Regarding general language agnostic API design, our <a href="https://github.com/hiero-ledger/sdk-collaboration-hub/blob/main/guides/api-guideline.md" rel="noopener noreferrer" target="_blank" style="color: rgb(9, 105, 218);">API guideline</a> is a good starting point. Based on that guideline, we created a <a href="https://github.com/hiero-ledger/sdk-collaboration-hub/tree/main/v3-sandbox/prototype-api" rel="noopener noreferrer" target="_blank" style="color: rgb(9, 105, 218);">draft of the new SDK architecture and APIs</a>.</p><p>As a next step we need to create PoCs for the new SDK architecture and APIs in multiple languages. The main goal of this mentorship program project is to:</p><ul><li>Create PoCs for the new SDK architecture and APIs in multiple languages.</li><li>Create a roadmap for the new SDK architecture and APIs.</li><li>Contribute to our guidelines and documentation to make the new SDK architecture and APIs more accessible to developers.</li><li>Check how AI (like Claude code or GitHub Co-Pilot) can be used as a helpful tool when working on SDK code with all our guidelines and documentation in context.</li></ul><h3>Learning Objectives</h3><ul><li>Understand Hiero and how Hiero based networks work.</li><li>Understand the Communication between a Hiero network (a consensus node and a mirror node) and a client.</li><li>Understand the current SDKs of Hiero and how they work.</li><li>Learn how to create future proof and non breaking APIs.</li><li>Learn how to use language features like generics and type inference to create the best possible SDKs.</li></ul><h3>Expected Outcome and Deliverables</h3><p>The successful completion of this project will result in at least 3 SDK V3 PoCs in multiple languages. Next to that we hope that contributions can be done to the general API guidelines and specifications.</p><p><br></p><p>Lean more at <a href="https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/71" rel="noopener noreferrer" target="_blank">https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/71</a></p>
<p>To support colored glyphs in <strong>OpenType</strong> fonts, several formats currently exist, namely <strong>SBIX</strong>, <strong>CBDT</strong> and <strong>COLR</strong>. These are used widely with varying degree of support across different platforms. <strong>SVG</strong> is a recent addition that uses a subset of <strong>SVG1.1</strong> features to represent glyphs. It is growing in popularity and will be supported across most devices very soon. <strong>FreeType</strong> is a very powerful font rendering library that is being used across billions of devices. It already supports <strong>SBIX</strong>, <strong>CBDT</strong> and <strong>COLR</strong> formats. The goal of this project is to add support for SVG glyphs to <strong>FreeType</strong>. I plan to accomplish this by:</p> <ol> <li>Writing code that reads SVG documents from SVG font tables and decode it if it's in <strong>gzip</strong> encoded format.</li> <li>Creating a callback API that would allow users of FreeType to plug any external SVG Renderer to be used for SVG rendering.</li> <li>Choose one SVG Renderer as the default one so that SVG support comes out of the box with FreeType, while making the callback API generic enough to support other renderers too. </li> <li>Testing and documenting everything.</li> </ol>
SQLancer is an open-source tool for testing the correctness of SQL database systems and supports close to 20 database systems. The goal of this project is to add support for one or more new database systems to SQLancer and test them to find potential bugs. As for which DBMS to add support for, I would like to firstly choose StoneDB, which is being actively maintained and their community showed their interest of being support by SQLancer. What’s more, StoneDB is just the primary choose. If we have time, we can also add support to other DBMS. The project Proposal will consist of four main stages: 1)Choose a DBMS 2)Implementation of selected DBMS 3)Refactoring existing code 4)Testing and reporting
Java Pathfinder (JPF) is a Java virtual machine that can run compiled Java programs as well as model checking it. It is also an extensible software analysis framework for Java bytecode. As it has been created for about two decades, supporting new Java language features is of vital importance for its wide adoption. JPF community has taken steps to add Java 11 support, but there are still some unsolved issues. In this project, I plan to add better Java 11 support for JPF. This includes more comprehensive Java bytecode support, especially for invokedynamic, more JDK API support, and some bug fixes. It will fix all 13 failing tests JPF faces now on Java 11 and enable more programs to run on JPF.