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.
<p>Eclipse 4diac is an open source environment for programming distributed industrial automation solutions and control systems based on the IEC 61499 standard. One of the components of Eclipse 4diac is the 4diac IDE which is an integrated development environment for modeling distributed control applications compliant to the IEC 61499 standard. The current version of 4diac IDE does not support the validation of the models, which makes it difficult for users to get design-time feedback on inconsistencies regarding the models developed in 4diac. The Object Constraint Language (OCL) could be a solution to find issues in 4diac models since it provides capabilities for specifying generic constraints a model has to fulfill. The aim of this project is to develop OCL constraints and well-formedness rules to the metamodels of 4diac in order to improve the usability of the IDE.</p>
The proposed project aims to bridge a critical gap in the Kubeflow ecosystem by introducing robust Helm-based deployment support. While Kustomize has been the default configuration tool, many organizations have standardized on Helm for managing Kubernetes applications due to its templating capabilities and ecosystem support. This mismatch has led to significant maintenance burdens, with adopters often resorting to maintaining custom Kustomize forks to support essential components such as Istio and OAuth2. These customizations introduce complexity in upgrades and contribute to version drift, undermining reliability. By enabling Helm-based deployment, the project will align Kubeflow with mainstream Kubernetes practices, simplify maintenance, and foster broader community adoption. This initiative also supports the CNCF’s goal of interoperability and standardization across cloud-native projects.
This project focuses on optimizing and deploying EduAid, an AI-powered tool that generates interactive quizzes from educational content. Key deliverables include: - Adaptive Difficulty Control: NLP-driven question generation targeting overlooked concepts using TF-IDF scoring and synonym replacement. - Multilingual Integration: Leveraging the T5 model to enable question translation into German, French, and Romanian. - Scalable Infrastructure: Deployment via Electron.js, Celery-Redis task queues for scaling by the factor of 10x. - Performance Enhancements: Model quantization (25% size reduction), ONNX runtime acceleration (65% latency improvement), and service workers for background processing. - Unified UI/UX: Revamped frontend with reusable components and IndexedDB migration for efficient data handling.
<p>The project will require to implement a backend for OpenWISP 2. The backend must generate Raspbian compatible configuration files (i.e. <code>etc/resolv.conf</code>, <code>etc/network/interfaces</code>, <code>etc/hostapd/hostapd.conf</code>, etc ) from NetJSON Device Configuration. The backend must also be capable of generating NetJSON Device Configuration from the Raspbian configuration files. The backend must atleast conver General, NTP Settings, Wireless Settings, Wireless Settings, DNS Server, DNS Search Domains, Static Routes, Files, etc. The test coverage of the library must be above 95%. The backend will be documented inside python-sphinx docs directory contained in the <code>netjsonconfig</code> repository.</p>
<p>PostgreSQL is a big and active open-source DBMS. This means that the code changes frequently and there are a lot of branches and commits. When big changes are made, performance has to be tested.</p> <p>Performance Farm is a program that can be used to collect and visualize the benchmark results while the source code changes. Developers can analyze the performance of different versions of the source code or the efficacy on different operating systems.</p> <p>It is built with Python scripts, a Django REST API server, and a front-end website. The actual benchmarks can be run on Linux and macOS machines while the users can easily see the results using the website.</p> <p>This year's goal is to improve Performance Farm by adding system metadata, removing dependencies, and improving the website.</p>
A Device Tree (DT) is a data structure used to describe non-discoverable hardware to the OS or bootloader. It is written in a device tree source (.dts/.dtsi) file, which is compiled into the kernel image at build time. This structure provides a standardized way to describe a system’s hardware topology. Device Tree bindings are the rules and conventions used to describe devices within the Device Tree. These bindings define how to represent various hardware components. Device tree bindings were historically written in human readable (.txt) format and developers had to rely upon manually reading these files and writing device tree source files accordingly. Now, these files are being converted to DT schema (.yaml) format so that semantic validation can be done on device tree sources automatically.
Scientific workflows often require sophisticated analyses that encompass an extensive collection of algorithms. In neuroimaging, Nipype (Python) is a widely used open-source framework. Nipype provides a uniform interface to existing neuroimaging software and facilitates interaction between different software components. The current project - Pydra - is a part of the second generation of the Nipype ecosystem and is more lightweight and flexible than the older generation. Pydra is meant to facilitate computational graph construction, manipulation, and distributed execution and ensure the reproducibility of scientific pipelines, including but not limited to neuroimaging. The goal of this project is to convert existing neuroimaging analytical workflows that are written in other languages to the new dataflow engine Pydra. The main deliverables of the project are comprehensive Pydra workflows that use interfaces from neuroimaging packages such as FSL, SPM, ANTs, AFNI, FreeSurfer.
A Device Tree (DT) is a data structure used to describe non-discoverable hardware to the OS or bootloader. It is written in a device tree source (.dts/.dtsi) file, which is compiled into the kernel image at build time. This structure provides a standardized way to describe a system’s hardware topology. Device Tree bindings are the rules and conventions used to describe devices within the Device Tree. These bindings define how to represent various hardware components. Device tree bindings were historically written in human readable (.txt) format and developers had to rely upon manually reading these files and writing device tree source files accordingly. Now, these files are being converted to DT schema (.yaml) format so that semantic validation can be done on device tree sources automatically.
<p><a href="https://github.com/AnemoneLabs/unmessage" target="_blank">unMessage</a> is a privacy enhanced instant messenger that uses its own end-to-end encrypted protocol to maintain conversations, not depending on servers, metadata or transport.</p> <p>Designed by Felipe Dau and David R. Andersen, unMessage's initial Python implementation had issues such as improper use of the Python Twisted asynchronous network IO framework, lack of a test suite and others that would harm its maintainability and quality.</p> <p>Mentored by David Stainton and meejah, the goal of this project is teaching Felipe how to work with asynchronous programming, how to use Twisted better, how to test the software and how to use Continuous Integration, while applying it to unMessage to improve its code quality and contributing to its maturity as a messenger which the community can benefit from.</p>
OpenFASOC is an open-source framework for autonomous generation of optimized integrated circuit blocks given user specifications. It is a growing project divided into multiple circuit block generators, one of which is a novel temperature sensor design. While the generated temperature sensor circuit is adequate, its resulting physical layout is not. A multi-voltage domain structure causes issues with routing between circuit components, which needs to be reworked. To do so, the OpenROAD tool will be studied to implement a better generated layout by tweaking the OpenFASOC flow. An opening to a design space exploration (DSE) optimization technique for the flow parameters is also proposed. Deliverables: an updated, working generator flow that outputs OpenFASOC's temperature sensor physical layout (GDS and DEF files) in SkyWater 130nm with no LVS, DRC or simulation errors.
<p>Apache Airavata used to support user-defined workflows using the XBaya interface, to drag and drop application components to a workspace and define data flow and control flow dependencies among the application nodes. Airavata has evolved significantly and currently it only supports single job submissions through Orchestrator. But the current development version is being built-over Apache Helix for DAG orchestration. This provides an opportunity to resurrect workflow capabilities in Airavata. This GSoC project consists of the following sub tasks.</p> <ul> <li>Finalizing the Airavata Workflow Language.</li> <li>Modifying the Orchestrator to parse user-defined workflow and translate to equivalent Helix DAGs, execute the workflow, and monitor it at runtime.</li> <li>Developing a simple GUI to demonstrate the capabilities.</li> </ul>
<p>The Workflow Designer is a prototype web-based application allowing drag-and-drop creating, editing, and running workflows from a predefined library of methods. Moreover, any workflow can be exported or imported in JSON format to ensure reusability and local execution of exported JSON configurations. The application is primarily focused on electroencephalographic signal processing and deep learning workflows.</p> <p>Currently, the entire Workflow Designer system (workflow system, deep learning models, server) is based on Java. The aim of this project is to transfer the deep learning workflow related blocks/models and backend technologies from Java to Python and allow executing workflow blocks (methods) implemented in Python, using e.g. MNE for EEG signal processing, or TensorFlow for deep learning.</p>
This project aims to enhance PVNet, a multi-modal deep learning model for solar energy forecasting, by integrating aerosol data as an additional input feature. Aerosols like dust, smoke, and haze significantly affect solar irradiance but are not currently accounted for in PVNet’s forecasting pipeline. The work involves identifying suitable open aerosol datasets, preprocessing and aligning them with existing NWP inputs, and incorporating them into the model architecture through a dedicated encoder. By comparing baseline and aerosol-aware models, we aim to assess the impact of aerosols on forecast accuracy. The final deliverables will include updated data pipelines, modified model components, and performance evaluation. This project contributes toward more accurate, climate-aware solar forecasting using open-source tools and public datasets.
Millions of lines of open-source Verilog exist but remain verbose and hard to maintain. TL-Verilog offers a cleaner abstraction, but almost none of this codebase has been converted. This project strengthens the LLM-driven conversion pipeline in the conversion-to-TLV repository by improving error recovery, refining prompt recipes for complex Verilog patterns (FSMs, parameterized modules, arithmetic pipelines), and applying the flow to real open-source modules including RISC-V components. All conversions are formally verified using SymbiYosys and EQY, generating high-quality training data for future LLM improvement. Deliverables include a fast working failure-classification system, improved prompts.json recipes, 10+ converted and verified modules, and structured training data registered in the project repository.
This project successfully developed two AI-powered tools to enhance software quality at Eclipse Adoptium. The first, GlitchWitcher, implements the REPD (Reconstruction Error Probability Distribution) model, using an autoencoder for supervised anomaly detection to proactively predict software defects. The project's primary deliverable evolved into VitAI, an advanced, modular multi-agent AI assistant for interactive test triage. VitAI's architecture features a custom MCP (Model Context Protocol) server for providing an interface to interact with a specialized agent and a Retrieval-Augmented Generation (RAG) system. The RAG system provides deep, context-aware responses by querying a vector database of project documentation, issues, and build data. This work was supported by automated data pipelines and is showcased in a live interactive demo.
The ONAP Portal is a platform that provides the ability to integrate different ONAP applications into a centralized Portal Core. 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. During the latest release retrospective, the ONAP Integration Team has identified 3 areas of improvements: 1. Integration tests in target deployments using OOM. 2. Improve robot healthcheck across projects. 3. More projects added to CI pipeline and more project-specific testing. This project will focus to address these improvements defined by the SDC/Portal Projects Teams.
<p>The goal of this project is to create a QGIS Desktop plugin which provides a web service API that exposes QGIS' data processing and canvas drawing functionalities. The plugin provides a way to include QGIS in the data processing workflow of other (‘mapping-deficient’) programming languages over a HTTP interface which mirrors the existing QGIS API, without precluding the ability to make use of its interactive editing components. The project also covers the generation and documentation of automated geospatial analysis workflow examples using Jupyter notebooks for both Python and R. The example notebooks will integrate data obtained from Open Data repositories with use cases of the QGIS Web API as well as other OSGeo geospatial libraries to demonstrate the potential of automatic report generation for open source GIS analysis.</p>
OpenHPC is accepting applications for a new mentorship program that aims to give students practical experience contributing to an open-source project and an opportunity to work with volunteers from the project’s Technical Steering Committee (TSC). OpenHPC is a software stack that aggregates a variety of software components ranging from administrative tools like bare metal provisioning and resource management to end-user development that span a range of scientific/numerical uses. If your interest is in the domain of high performance computing , scientific computing or cluster management, this might be the right program for you. This initial program will occur during the Fall of 2020 with future versions expected to occur during the summer. See our website for details and project ideas - http://bit.ly/ohcmentorship2020 . For questions feel free to email - mentorship@openhpc.community
Currently, the codebase lacks comprehensive unit testing coverage for all critical components, and the existing unit tests do not provide adequate coverage. The primary objective of this project is to augment unit test coverage for essential files, aiming to achieve a coverage range of 90% to 95%. Subsequently, these unit tests will be seamlessly integrated into the existing GitHub continuous integration and continuous deployment (CI/CD) pipeline. The CI pipeline is presently triggered on each pull request to the 'develop' branch. However, merging is contingent upon the successful execution of these tests, which can be manually triggered by either the maintainers or the developers locally. The overarching goal is to establish an automated testing framework, ensuring that no code is merged unless it passes all requisite tests, with the exception of documentation or non-code-related pull requests.
<p>One of the gems dug up by Deep Mind in the field of neural learning is Neural Turing Machines. By extending the capabilities of a simple neural network by attaching a memory to it, neural networks are able to learn simple algorithms such as copying sorting and etc. The project involves implementing a Neural Turing Machine in the current ANN framework and testing it with the preliminary algorithms.</p> <p>In addition, I will also implement batch normalization and GRU cell as part of my project. Batch normalization is an effective technique which has become an essential component in stabilizing the deep network learning. GRU cells are essentially simple forms of LSTM cell, yet for some tasks have been proven to converge faster. Also, GRU cells have lesser parameters, making them more prone to overfitting and stable towrds training.</p>
Inspired by the pMix and Amati projects, this plugin will be built using the JUCE framework for the interface and libFaust with LLVM and interpreter backend API to compile Faust code. The user will be able to write Faust code in any VST-aware host and can be saved or recompiled on the fly. There are six components to the plugin, the editor, the console, a section for editing the parameters, a block diagram displaying the DSP, a preference page to change the settings, and a keyboard section where the user can enter MIDI inputs. The plugin will also support polyphonic Faust DSP objects, and the parameter inputs will be created depending on Faust code. Amati project is currently used as a starting point for the project, so it will use much of the existing code. However, changes might be made to them if needed.
<p>Elastic deformation is an essential component of animation pipelines. Volumetric soft body simulation can be used to capture the complex details of muscle and skin, e.g. volume preservation under collision/compression. In visual effects, such methods must also be robust to extreme deformation (no numerical blow-ups) and fast enough for interactive manipulation. Moreover, many of the underlying material models are nonlinear and computationally expensive, such as hyper-elastic models for realistic tissue or artistically-defined deformation. Toward these challenges I propose the implementation of a volumetric soft body solver in Blender, that is not only rapid and robust, but is general to hyper-elastic materials. The solver will also be capable of robustly resolving self-collisions and possibly other constraints. This would greatly improve the use of physics in Blender for animation pipelines.</p>
<p>This project involves the development of an open source database to enable the linked exploration of data in the platform, including energy demand, supply and technology data. Data in the HUES platform is highly diverse and rapidly growing. Currently, this data is stored in separate platform modules using different data structures and file formats, making it difficult to explore holistically. We will migrate this data using a tool Mongify to migrate database from MySQL to MongoDB. The development of server based scripts to automatically extract relevant data from the modules of the HUES platform, and write this data to a common database. In the new database everything can be retrieved in the form of JSON objects. The development of a web-based portal for querying, visualizing and downloading data will be the last part of the project development.</p>