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.
Multi-output Gaussian processes (MOGPs), a type of Bayesian nonparametric models, have recently gained strong attention from researchers, and become an active research topic in machine learning’s multi-task learning. The advantage of multi-output GPs is its capacity to simultaneously learn and infer many outputs which have the same source of uncertainty from inputs. This provides a useful and practical approach for various applications in different fields. The creation of new sampling methods and the advance in computing power have paved the way for the development of Bayesian models. Different software frameworks have been built to facilitate this probabilistic programming approach. Among those, PyMC is one of the most popular frameworks with a large and strong community. PyMC provides friendly interfaces that allow users in academics and industries to perform both parametric and nonparametric Bayesian data analysis. For Bayesian nonparametric models, the Gaussian process module in PyMC supports various mean and kernel classes. However, the current GP implementations in PyMC are limited to single output. This project aims to add support for multi-output GPs in PyMC. This feature would significantly extend the capabilities of this important module and benefit the PyMC community.
Android Client is a mobile application that allows bank staff field officers to keep track of clients, centers, groups, loan accounts, saving accounts, and other critical information. The project aims to upgrade the Mifos Android client application by updating it to the latest dependencies and rewriting it to consume the Mifos Fineract SDK using coroutines and flows. The Android client will become the first Mifos app to utilize the Fineract SDK, thereby reducing redundant network layer code. The upgrade will involve two main migrations: transitioning from XML to Jetpack Compose and supporting a multi-module MVVM architecture organized by feature-wise modules. Additionally, the project will include supporting Kotlin Multiplatform (KMP). The upgrade will also encompass implementing unit and integration testing for features and upgrading the CI/CD pipeline for KMP and Google Play Store release pipelines. Integrating the Google Play Store API will streamline the release flow, leading to a more stable and error-free codebase, faster build times, and an improved developer experience. These changes will also facilitate smoother release management and upstream contributions, ultimately reducing the time required for upgrades.
<p>SunPy uses python <code>datetime</code> module for handling almost all time related things. <code>datetime</code> is not the best choice for astronomy related projects due to a lot of reasons (for instance, it does not handle leap seconds). The answer is to use <code>time</code> module from <code>astropy</code>.</p> <p><code>astropy.time.Time</code> can do a lot things including:</p> <ul> <li>Handle leap seconds</li> <li>Easy conversion between format like <code>iso</code>, <code>isot</code> etc.</li> <li>Easy conversion between scales like <code>utc</code>, <code>tai</code> etc.</li> <li>Can be initialized from and converted to a lot of popular time formats and even supports python <code>datetime</code>.</li> <li>Ability to create custom classes to support extra formats of time.</li> </ul> <p>This makes <code>astropy.time</code> the best candidate to replace python <code>datetime</code> in SunPy.</p> <p>This project will transition the whole of SunPy to use <code>astropy.time</code> instead of python <code>datetime</code>.</p>
The VCell-AI Platform is an AI-powered system for discovering, analyzing, and exploring biomodels, publications, and research papers from the VCell database. It supports both traditional database queries and AI-powered natural language searches through a chatbot, provides biomodel diagram analysis, and includes a vector-based knowledge base for document retrieval for VCell Software tutorials and guides. Built with Next.js and Tailwind CSS on the frontend, FastAPI and Python on the backend, and Qdrant for vector storage, the platform also integrates Langfuse for LLM observability and can run with locally hosted LLMs, offering researchers a fully functional, flexible, and user-friendly environment for scientific exploration.
The problem I am solving: The existing HDF5 asynchronous I/O feature supports the C/C++ interface. This project involves the development and performance evaluation of a Python interface that would allow more Python-based scientific codes to use and benefit from the asynchronous I/O. The h5py package provides both a high- and low-level interface to the HDF5 library from Python. The low-level interface is intended to be a complete wrapping of the HDF5 API. The h5py package currently only supports synchronous I/O. And this project I am going to add the Asynchronous I/O. The plan to solve it: Milestone 1: create a new Python API. Milestone 2: convert existing c tests to python tests. Milestone 3: test my implementation with the tests. Milestone 4: evaluate the performance with a scientific python application. When all tests pass we will have a usable Python interface for the asynchronous I/O. An example: the H5Fcreate_async function: First, prepare the H5Fcreate_async.h file, H5Fcreate_async.c file, and we create the cyH5Fcreate_async.pyx file. Second, use the command to Parse pyx source code into c code. Next, use some commands to compile c files into object files (*.o files) Next, use some commands to link multiple object files into dynamic link library files (*.so files) In this way, the file of H5Fcreate_async.so is obtained, and then the library can be imported in the Python application.
Apache Kvrocks currently uses a minimalistic UI for its Controller, which limits usability and lacks advanced features. This project aims to revamp the Kvrocks Controller UI with a modern frontend stack (Next.js, Tailwind CSS) enhancing both functionality and user experience. Key deliverables include: A fully redesigned, responsive UI with clear navigation and real-time cluster visualization. Support for single sign on (SSO) authentication. Interfaces for cluster slot migration and master node failover handling. Intuitive forms and dashboards for managing instances, namespaces, and configuration. This improved UI will make it easier for developers and administrators to monitor and control Kvrocks clusters at scale, significantly enhancing the accessibility and robustness of the platform.
<p>The Translation Management Tool (TMGMT) module is an extension to support editors, publishers, translators and project managers during their process of content translation. Since I think that Local Translator is a very useful submodule, there are still lots of things missing. The tool was working in Drupal 7, but it was rather limited in functionality and by far not fulfilling expectations of professional translators. I believe the next goal is to make the Local Translator a professional CAT Tool and I would like to help with implementing CKEditor plugins using Javascript. Because TMGMT wants to use the CKEditor libraries to build an alternative non-WYSIWYG translation editor, I would propose to implement some special linguistic actions like defining segments, marking them in the UI and masking specific HTML tags.</p>
<p>While the network visualization module in cBioPortal is a powerful exploration tool, most biologists are more comfortable with the kind of simplified, curated pathway diagrams that are featured in many manuscripts from The Cancer Genome Atlas (TCGA) . With the motivation of creating a platform that provides more intuitive pathway diagrams, yet supports these with rich data ‘decoration’ and analysis with access to data in cBioPortal, with attractive visualization, a tool named PathwayMapper based on Cytoscape.js was developed. PathwayMapper is a valuable tool for constructing pathways from scratch. One can also use it as a viewer to overlay cancer genomics data on existing "template" pathways like those that appeared in TCGA papers. Ultimately, this project has two main purposes. First one is improving PathwayMapper with new attaractive features for both local and colloborative modes. Second one is integrating PathwayMapper into cBioPortal as an alternative to the cBioPortal's current network view.</p>
<p>The project aims to bridge the AIMALL and Molden programs with cclib by adding support for writing wfx/wfn files and Molden format files.</p> <p>Molden program supports reading input from GAMESS, Gaussian and MOPAC and some user written scripts add support for some other programs. cclib being the largest parsing library for QM program outputs could provide a one stop solution for making Molden files.</p> <p>Bader's Atom in Molecule is a popular method to characterize individual atomic contributions to the electron density to much more intuitive atoms and bonds. AIMALL is the go-to program for doing AIM analysis. Having a wfx/wfn writer within cclib would bridge the two programs.</p> <p>As stretch goals, I propose implementing either updating write support for .cube files which can be used with Henkelman group’s fast implementation for Bader charge integration or start building a parser for Molcas. The former is in-line with cclib's attempt to include modules for advanced analysis of quantum chemistry data, while support for the latter is a requested in cclib's github repository.</p>
To address Apache DolphinScheduler's lack of generalized OIDC support which limited its adoption in enterprises that rely on a variety of identity providers like Keycloak, Okta, or Azure AD, this project introduces a new, pluggable, and configuration-driven authentication module. Built with Java and Spring Security, the backend handles the complete OIDC Authorization Code Flow, including automated user provisioning and role mapping based on IdP groups, all without requiring any database schema changes. The Vue.js frontend was enhanced to dynamically render login buttons for each configured identity provider. To ensure smooth onboarding and adoption, the project also delivers production-ready documentation with detailed setup guides for administrators and developers. The feature's quality is ensured by a robust testing strategy, featuring comprehensive unit tests and a full end-to-end API test suite using Testcontainers, which automatically orchestrates a Docker environment with DolphinScheduler and a Keycloak IdP to validate the entire login flow in a production-like environment. This project successfully delivers a production-ready Single Sign-On (SSO) solution that significantly enhances DolphinScheduler's security, usability, and enterprise-readiness.
Inspektor Gadget is an eBPF tool and systems inspection framework for Kubernetes, containers and Linux hosts. A Gadget is an OCI image that includes one or more eBPF programs, metadata YAML file, and optionally, WASM modules for post processing. Today, Inspektor Gadget provides tooling to build gadgets from source code written in C (for the eBPF module) and Go (for the WASM module). This project is about adding support from building gadgets from Rust both for eBPF programs and for WASM modules. Expected Outcome: users can write their gadgets in Rust.
As AI assistants adopt humanlike names, conversational tone, and confidence framing, users form impressions of AI competence from interface design alone — independently of actual system capability. This can produce overtrust, underuse, or miscalibrated reliance. Most existing research measures trust through self-report scales, which cannot capture when or how quickly users actually defer to or override an AI recommendation. This project builds a modular, open-source web-based experimentation platform that makes behavioral trust measures tractable for researchers. Built in Next.js, the system supports randomized condition assignment, configurable manipulation of humanlike interface cues (agent name, tone, confidence framing), and a recommendation-acceptance task that produces clear reliance-versus-override outcomes under controlled AI accuracy. Fine-grained event logs — decisions, timestamps, response latency — are exported as clean JSON and CSV datasets, and a reproducible Python notebook reports reliance rate, override rate, and latency by condition. The platform is designed as reusable research infrastructure: cue logic is configuration-driven, task logic is decoupled from condition management, and the event schema is fully documented so future researchers can extend the system with new cues, tasks, and study conditions. Deliverables include a functional experimental prototype, cue manipulation framework, behavioral logging backend, sample dataset, analysis notebook, and complete documentation in a public GitHub repository.
<p>The Component Development Kit as of now supports only Non UI components and lacks multiple language support. This proposal aims at upgrading the Component Development Kit to the next level. Enabling multiple language support as well as visible UI external components. Another ambitious feature this proposal offers to implement is support Background processes. Enabling more flexibility and widening the range of Apps made with App Inventor. Some minor tweaks largely requested by the user community has also been planned to be implemented during this summer. The Projects will be selected or done as per the priority of community.</p>
<p>Tiled is a general-purpose tile map editor. It supports various tile shapes like square, hexagonal, isometric square. Tiled support in KivEnt will be a very useful tool, given that Tiled is already a very famous and feature-rich platform for creating game worlds and maps. A game developer would appreciate getting to use Tiled to create worlds with kivy than some custom platform in-built into KivEnt. This will also make it easier (at least the map part) for people to port their existing games to KivEnt, from other platforms which use Tiled.</p> <p>The aim of this project is to create a fully-functional Tiled module which supports almost all features which Tiled currently supports, i.e. various types of tile shapes, tile animations, multiple layers, shape definitions in tiles, custom data etc. The project will also require a TMX file format loader/parser.</p>
Drupal's AI Content Strategy module does a great job telling editors what to write, but the moment it hands off, editors are left staring at a blank field with no actual help getting words on the page. This project builds a content generation assistant that sits directly inside Drupal field widgets, letting editors prompt an AI model and insert the result without ever leaving the editing interface. The module will be built around a clean plugin architecture that supports OpenAI GPT, Anthropic Claude, Hugging Face, and Google Gemini as interchangeable providers, with a React-based prompt dialog giving editors control over tone, length, and style. A REST endpoint will bridge the frontend widget to the backend provider system, and the module will include generation history tracking, rate limiting, and cost cap controls for site administrators. By the end of GSoC, the project will ship as a fully documented, publicly released Drupal module that closes the gap between strategic content recommendations and actual content creation.
The project focuses on integration of FUSE-T kextless module for CVMFS on macOS. This initiative is motivated by the computational demands of particle physics, especially those associated with the Large Hadron Collider, which necessitates efficient and reliable software deployment across a massive, globally distributed computing grid. CVMFS (CernVM File System) plays a pivotal role in this process, serving as an optimized, POSIX-compliant read-only file system designed for user space via FUSE modules, thus facilitating software distribution. I propose replacing the current MacFUSE module as kernel extensions facing deprecation by Apple, with FUSE-T, a user-space module claimed to be a drop-in replacement. This transition addresses the issues with kernel extensions (kexts) and aligns with Apple's shift towards prohibition of support for them. Such approach potentially seems to be the most user-friendly in terms of security. The project involves various stages, including adapting CVMFS to use FUSE-T, benchmarking file operations, and investigating libfuse's new features like FUSE_CAP_SPLICE_MOVE. Deliverables include the successful integration of FUSE-T into CVMFS, benchmark reports on file operations, and an evaluation of libfuse updates.
<p>Python 3.5 has syntax features that are unavailable in the previous versions. They grant improved support for asynchronous programming (PEP 492), matrix multiplications (PEP 465) and the unpacking operator (PEP 448). The goal of this project is to implement these features in PyPy3. This way support for Python 3 code gets improved. Implementing coroutines will be the main feature of this project, as this feature offers more new methods than the other features. PEP 465 shows that Matrix multiplication is already used more often than bitwise operations in numeric libraries. Also, having coroutines with async and await syntax as well as enhanced unpacking options, the possibility that Python 3.5 syntax will be used in upcoming code rises. Therefore, an implementation of these features in PyPy3 will definitely increase compatibility to future Python 3 programs. In order to support PyPy’s Python 3 compatibility even further, other new features of Python 3.5 and 3.4 will be implemented after finishing the three PEPs if there is enough time, starting with the enum module of 3.4 and continuing with PEP 461 to allow support of the % formatting operator to bytes and bytearrays.</p>
The architecture of the GHC compiler in its current state is anti-modular. Designed with GHC-the-program as the sole consumer in mind, it is very difficult for newer tooling to reuse its components. These problems extend to the inclusion of new backends such that implementations for various target platforms forked GHC frequently. The first step to improving the current design is the isolation of the different components and separation the codebase in layers for different purposes, described in the classic book "Domain Driven Design". This is already partly done, and in this project I join the existing effort by working on the next remaining subsystem: GHC's Core pipeline. In order to achieve my goal, I will proceed by using an incremental bottom-up approach: Starting at the bottom of the module hierarchy, I will push references to upper layers module-by-module up in the callstack until they are completely removed from each component. For the entry points of each in-scope component, I will then provide component-specific configuration types and corresponding initialization functions. The in-scope components are specific configurable tasks of the optimizer, and the optimizer as a whole. With this work completed, there will be significantly less references to the ubiquitous global states used throughout the whole compiler, namely the DynFlags and the HscEnv type, and significantly fewer imports of modules from upper layers, e.g. the driver.
Astropy’s Python API is well-tested, but its underlying compiled layer (C, C++, Cython) lacks isolated testing. Because performance-critical extensions are currently only tested indirectly via high-level Python calls, deep bugs can easily be masked. This testing blind spot also blocks major architectural milestones, including the APE low-level package split, the Meson build system migration, and support for Python 3.15 free-threaded builds. This project will build a dedicated test suite to exercise each compiled extension module directly, entirely bypassing the public Python API. By engineering methods to probe these modules in isolation, including resolving complex runtime circular dependencies like `unit_list_proxy.c`; this work will establish a robust, reliable testing boundary between Python and the compiled code. Deliverables: C-API Audit: A mapped testing surface for active compiled extension modules. Isolated Test Suites: Direct pytest suites for compiled modules in astropy/table, time, timeseries, utils/xml, wcs, and erfa. Dependency Resolution: A C-level refactor (or minimal Python stub) to fix the `unit_list_proxy.c` circular dependency. Documentation: A new TESTING_EXTENSIONS.rst guide in Astropy's docs detailing how to run and extend these direct tests.
F2PY is an open-source utility that provides an easy connection between Python and Fortran languages. It enables users to integrate Fortran code into Python easily and quickly. F2PY has been in maintenance mode since 2009, ever since it became feature-complete for Fortran 77. Beginners browsing its codebase in the current state might find it challenging to read, understand and contribute. The frontend of F2PY is a handwritten command line parser that predates the intrinsic ‘argparse’ module by several years. This project will include modernising the CLI with the “argparse” python library, simplifying the frontend codebase and making it more developer-friendly to contribute to. Since “np.distutils” is set for deprecation, I propose adding an option to build the F2PY’s generated CPython extension modules with Meson. Meson will significantly speed up building standalone extension modules through the F2PY CLI. There is no change proposed to the process of generating C and Fortran wrappers from Fortran source files. Generation of the source code for integration in Python projects will be carried out in the same way. Currently, “np.distutils” is used by F2PY to build generated extension modules. Adding a Meson backend will provide faster builds and long-term backend support for F2PY. Additionally, I plan to re-implement the class-based test-suite of F2PY in a modern pytest manner and add a developer’s guide to F2PY.
<p>Conpot is an ICS/SCADA honeypot that supports a number of industrial protocols and environments. For Conpot to emulate industrial devices better, this summer I would work on adding functionality that let’s protocols interact more deeply with each other. This includes adding an internal interface, a central authentication module and a versioned-journaled virtual file system. This would follow support for protocols such as TFTP, FTP and Telnet. I would also write supporting tests and documentation for the above features.</p>
<p>The project is to write a driver for Bosch BME680(4-in-1) sensor module using the Industrial I/O interface to effectively read data from each of the four channels which are Temperature, Pressure, Humidity and Gas. The sensor communicates via I2C and SPI communication protocol and the captured data read from the sensor is transported from kernelspace to userspace using the sysfs bindings to the IIO core. The goal is also to add support for triggered buffer readings from each of the channels to efficiently read samples. Finally, power management support is also required to support suspend/resume functions.</p>
This project focuses on migrating JavaScript codebase to Typescript. Zulip is in the process of porting the main web app JavaScript codebase to TypeScrip. Zulip’s 8% of lines have been migrated while the goal for this summer will be to get that to ~75%. The challenges for migrating JS to TS include circular imports, a large number of interdependent modules, tracking down complex cycles, multiple cycles in one module, order of conversion, and understanding types and their relationships. The proposed solutions include classifying circular imports, passing callback workaround, extracting common functionality into a third module, and writing unit and integration tests to ensure the migrated codebase functions properly.
<h3>Current problem</h3> <p>A simple identity authentication module has been implemented in the current panel, which supports the user name/password authentication mode, but its implementation faces some problems.</p> <p>First of all, in the currently implemented authentication mode, the user name and password are stored in a configuration file in plain text. It does not support hot updates, nor does it support dynamic addition by programs, and it is also difficult to ensure security.</p> <p>Also, the back-end part currently does not implement an abstract authentication framework specification, and can only implement a single authentication mode, which cannot be extended.</p> <h3>Project Summary</h3> <p>This proposal aims to implement an extensible abstract framework for the front-end and back-end so that it can be extended to other authentication methods while retaining the existing username/password mode and improving it.</p>