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>Both Link Time Optimization (LTO) and C++20 Modules will benefit from a closer interaction between build system and compiler. LTO benefits from parallelizing the LTO step by spawning separate compilations and Modules can discover new dependencies during compilation. Both of these task are traditionally under control of a build system.</p> <p>Currently, GCC's LTO can use GNUMake's jobserver protocol to control its direct spawning subjobs. C++20 modules can make use of a proposed protocol[*], or use pre-scanning. This project aims to unify these approaches providing (a) client/server librar{y,ies} to manage communication (b) extend the proposed protocol to cover LTO requirements (c) provide a sample implementation for GCC/GNUmake.</p> <p>[*] <a href="https://wg21.link/p1184" target="_blank">https://wg21.link/p1184</a></p>
My project aims to bridge the gap between single-cell gene expression data analysis and existing cancer genomics workflows, particularly within the cBioPortal platform. Currently, cBioPortal lacks support for visualizing single-cell data alongside bulk genomics data, hindering researchers from gaining a comprehensive understanding of cancer biology. To address this, I propose the development of a dedicated single-cell analysis module within cBioPortal, focusing on the MSK Spectrum dataset. The key problem I am addressing is the inability to integrate single-cell gene expression data with existing cancer genomics workflows. By incorporating single-cell data into cBioPortal, researchers will be empowered to identify specific cells with altered gene expression, understand their contribution to overall expression patterns, and connect this information with genetic alterations. My solution involves developing a custom Single-Cell Tab within cBioPortal's study view. The tab will include features such as dataset information, gene selection, interactive visualizations (boxplots, scatter plots, stacked bar graphs, and pie charts), filtering options, and download capabilities. To achieve this, I will aggregate the single-cell data to a gene-cell type-sample level, creating a pseudo bulk representation to manage the large dataset size effectively. I will utilize existing charting libraries like CanvasJS and React primitives for visualization components, ensuring seamless integration with cBioPortal's design language. My deliverables include: Custom Single-Cell Tab within cBioPortal study view. Dataset information panel for study description and cell type/sample details. Gene selection panel with autocomplete functionality. Interactive visualizations including boxplots, scatter plots, stacked bar graphs, and pie charts. Filtering options for focused data exploration. Download options for data and plots in common file formats.
<p>The goal of the project is to provide production ready, autoconfigured service that will be using all the AeroGear Voyager Server functionalities and will provide a command line tool for building and extending GraphQL based Node.js server. The client will help with developers getting started by generating standalone Node.js Server that can provide out of the box features for developers looking for RealTime DataBase capabilities and easing development effort required to build and deploy functional server to production.</p>
Summary: The OBA project aims to develop official OneBusAway REST API client libraries in TypeScript and Python, enhancing accessibility and user experience for developers interacting with OneBusAway servers. These libraries will support all REST API methods, handle diverse data types, include comprehensive tests, and provide helpful examples for new users. About Me: I am Ahmed Hossam, a senior information technology student with a passion for technology and problem-solving. With experience in backend engineering and competitive programming, I am excited to contribute to the OBA project and make a positive impact. Investigations: I have familiarized myself with OneBusAway endpoints, built a beta version of the TypeScript package, and experimented with different structures for scalability and maintainability. Detailed Design: The API client follows a modular structure, with each endpoint encapsulated within its own module. It employs a combination of factory and dependency injection patterns and includes a base class for foundational HTTP request functionality. Implementation Plan: I will collaborate closely with mentors to understand API client requirements and plan implementation details. Error handling and unit testing will be prioritized, followed by thorough testing and the publishing of final packages. Proposal Timeline: The timeline spans 14 weeks, beginning with communication and research in the first three weeks, followed by official coding in TypeScript. Python implementation will commence in week 9, with completion and finalization in week 14. Why Me: I find joy in making OBA APIs accessible to everyone and am dedicated to contributing positively to the project. My experience in API development, along with continuous learning, makes me well-suited for this role.
<p>Agones is a Kubernetes-native platform for hosting, running, and scaling dedicated game servers. This project builds a Headlamp plugin that adds an **Agones** section to Headlamp, surfacing Agones CRDs so operators can **view and manage game servers, fleets, and allocations** from the Headlamp UI. The plugin follows Headlamp UX patterns with list and detail views, links between related resources, and visibility into lifecycle and allocation state.</p><p><br></p><p>Expected Outcome:</p><p> - Plugin exposes key Agones CRDs: GameServer, Fleet, GameServerSet.</p><p> - List views, with summary columns (name, namespace, state, address, port, node, replicas).</p><p> - Detail pages, showing config, status conditions, lifecycle state, and sub-resources (game server pods).</p><p> - Relational navigation, fleet → game servers; game server → fleet.</p><p> - Consistent Headlamp UX, icons, tables, detail layouts, Map view enhancements.</p><p> - Structured config display (collapsible sections/YAML toggle), humanized lifecycle states (Ready, Allocated, Shutdown).</p><p> - README with prerequisites and limitations; blog post demoing usage.</p><p><br></p>
This project will enhance Makim by implementing Language Server Protocol (LSP) support for its YAML configuration files. This will introduce features like autocompletion, syntax validation, hover documentation, and custom commands directly within code editors. The project will deliver a Language Server and a VS Code extension, significantly improving the developer experience and making Makim more user-friendly.
The aim is to reimplement the Sugarizer Core architecture using Vue.js components, in order to update and improve the current implementation that relies on Enyo.js, a deprecated web framework. By utilizing Sugarizer Vue.js components, we can ensure that Sugarizer remains a modern and efficient tool for its users. The proposed project involves a comprehensive redesign of the Sugarizer Core UI, which includes developing new Vue.js components and integrating them with the existing Sugarizer codebase. The new components will be designed to improve the user experience, increase efficiency, and enhance the functionality of the app.
<p>Community of today used to use mobile phones to make their life easier and Community based mobile applications are famous among them. There are several kind of community based applications in use and most of them are relating to a specific domain. But core components have similar features. Address this issue and saving development time by Introducing a common app template with customizable components for community based mobile applications , is the main purpose of this project.</p>
<ul> <li>Improve the current Open Event Organizer Server application. Write tests for existing models and views. Provide bug fixes and enhancements.</li> <li>Create REST APIs to create/update/delete data at the server. Write tests and documentation for the same.</li> <li>Design and develop Organizer Server Permissions System.</li> </ul>
The kworkflow project has a GitHub Actions hosted CI pipeline that restricts testing possibilities for core kworkflow features, such as kw deploy, which would be better tested in real kernel deployment scenarios. I propose an implementation of a new Jenkins CI pipeline on a self-hosted server infrastructure for kworkflow, enabling more customizable and realistic testing cases and allowing specific hardware testing. The new server infrastructure will also be used for a data telemetry system.
My goal is to design an updated summary statistics API for use with Java 8 streams based on the summary statistic implementations in the Commons Math stat.descriptive package. The project aims to be a library of commons statistics functions in line with the latest developments in the Java language, in particular Java's functional programming syntax. At the end of the project I plan to provide a lightweight and reusable API that utilizes Java streams to offer commonly used statistical functions, with an emphasis on minimizing external dependencies and avoiding redundancy.
This project focuses on extending the existing React based Mifos X Web App to make it a strong candidate for the primary Mifos X web interface. The application will be enhanced using React and TypeScript, with improved integration to the Apache Fineract backend through the OpenAPI TypeScript client. This project will result in fully functional multi-step workflows and the implementation of missing or partially developed features. The final outcome will be a stable web application with feature parity with the existing Mifos X platform.
<p>JBoss Web Servers consists of Apache Tomcat 7, Apache Tomcat 8 and Apache Tomcat 8.5 servers. JBoss Core Services consists of Apache HTTP server and its dependencies. The project’s goal is to develop a tool that will scan and parse the upstream security advisories of Apache Tomcat and Apache HTTP Server along with their dependencies. This tool’s purpose is to populate Bugzilla by tracing down any new public CVE on every JWS and JBCS related upstream project. The tool will be built in Python3, scripts will be fired via Jenkins job and scripts will be running as a shell script.</p>
<p>Mozilla is a global non-profit dedicated to keeping the internet open, accessible, and safe for everyone.</p><p>Implement high-resolution DOM mutation profiling and memory footprint tracking inside Firefox Developer Tools.</p><p><br></p><p><strong>Deliverables:</strong></p><ul><li>DevTools panel extension for DOM mutation profiling.</li><li>Performance telemetry collector module.</li></ul><p><br></p><p><strong>Applications closing date: 25-Apr-2026</strong></p>
The project aims at helping researchers find journals that require open source code easily. I aim to create a user interface that could seamlessly help users submit, edit and delete journals and a user-management system that could help with admin and user roles. React forms can replace the outdated google forms to sign manifestos by individuals or organizations, which comes with proper authentication and spam prevention. Apart from working on having maximum functionalities integrated, I shall be removing the frontend dependencies like React-Bootstrap to make the project more user-friendly. With that, CI pipelines shall be integrated through Github actions along with E2E tests written with Cypress.
<p>Today most Koordinator scheduler plugins (DeviceShare, NodeNUMAResource, Reservation, etc.) keep their own private cache per scheduling framework/profile, so configuring multiple profiles in a single `KubeSchedulerConfiguration` produces duplicated plugin caches even though the upstream `SchedulerCache` and `PodNominator` are singletons per scheduler instance. This duplication wastes memory, desynchronizes state across profiles, and exposes correctness bugs: in `RunFilterPluginsWithNominatedPods`, `AddPod` is invoked for pods that are still in scheduling and are therefore missing from `nodeDeviceCache`'s used map, which causes DeviceShare and NodeNUMAResource to fail to reserve resources for high-priority pods in RDMA / VF / NV-Switch scenarios. This project will introduce a unified plugin-level Cache and Nominator abstraction that is shared across all profiles in the same scheduler instance, correctly integrates with `Reserve` / `UnReserve` lifecycle hooks, and fixes the `AddPod` / `RemovePod` handling for high-priority device and NUMA workloads.</p><p><br></p><p>Expected Outcome:</p><p> - A shared plugin-level `Cache` and `Nominator` framework exposed to Koordinator scheduler plugins, with a lifecycle tied to the scheduler instance rather than individual profiles</p><p> - Migration of DeviceShare, NodeNUMAResource, and Reservation plugin caches to the shared implementation, removing per-profile duplication</p><p> - Correct `AddPod` / `RemovePod` handling via reused `Reserve` logic that records assignment placements in the nominator, cleared symmetrically on `Reserve` / `UnReserve`</p><p> - Regression and stress tests covering multi-profile scheduling, preemption with nominated pods, and high-priority RDMA / VF / NV-Switch device assignment</p><p> - Developer documentation describing the shared Cache / Nominator API and migration guidance for other plugins</p><p><br></p>
<p>At the time of writing this, the frontend and the backend in <a href="https://github.com/fossasia/open-event-orga-server" target="_blank">open-event-orga-server</a> are tightly coupled with each other. The goal of the project is to refactor the current project and properly implement a json-api spec compliant API for Open Event Server. Other goals include setting up documentation testing using <a href="https://github.com/apiaryio/dredd" target="_blank">Dredd</a>.</p>
The Konveyor project helps modernize applications by providing open source tools to rehost, replatform, and refactor applications to Kubernetes and cloud-native technologies.We’re looking for help on building integration tests on application level as well as work on missing parts of Konveyor component tests.There is open testing work to better applications analysis, tasks coverage, more detailed Hub API tests and Hub integration with addons. All of those use the Hub API that is covered with basic tests already. Based on existing Hub API tests, it is expected to continue work to cover more Konveyor functionality with tests. The development environment is based on golang and Kubernetes. A minikube instance will work well for local development on Linux or Mac systems. - Expected Outcome: - Integration test suite and components testing added to existing Konveyor upstream automated test suite
This proposal aims to describe how to add inlay hints support to the Haskell language server. Inlay hints can provide a more fancy, intuitive, and convenient ui view of the current state of the code, such as the fixity of operators, the type of bound symbols in `let`, the type of holes, etc. Some basic work already exists in the current HLS that makes it feasible to implement inlay hints, such as the basic type library already in use: https://github.com/haskell/lsp; and the hls plugin system. Prior to submitting this proposal, I had already started working on trying to make some implementation work, and had made some progress. I submitted a draft pull request (https://github.com/haskell/haskell-language-server/pull/4131) to hls's github repository, which lists some todo's, but it should be noted that there is more to this proposal than just the pr's, and any suitable information that can be presented with the help of inlay hints will be included in the work. Since the ability to configure inlay hints is already in the todo, even if inlay hints that are too informative are implemented, they will not be a bother to the user: the user has the ability to configure the information that inlay hints will display. In the body of the proposal, I detailed the timeline and details for implementing the idea. I'll continue to build on the progress of this pull request, gradually implementing more inlay hints usages and important configuration capabilities.
Beam's Python SDK is increasingly the first choice for ML and data-intensive pipelines, making robust native streaming APIs more important than ever. However, two essential streaming primitives, UnboundedSource (Issue #19137) and Watch (Issue #21521), remain unavailable in Python despite being long established in the Java SDK. Today, Python developers who need these capabilities either pull in cross-language transforms that add Java dependencies and gRPC overhead, or wrestle with low-level RestrictionTracker internals. This project solves the problem by porting both primitives natively to Python on top of Beam's existing SDF framework. The UnboundedSource wrapper adapts the legacy reader API into a Splittable DoFn that handles checkpointing, watermark progression, deduplication, and splitting. The Watch transform adds periodic polling with composable termination conditions and stable dedup behavior. Porting both primitives natively abstracts away that complexity behind clean and Pythonic interfaces. It also unlocks native enhancements, such as updating fileio.MatchContinuously, without leaving the Python ecosystem. The planned deliverables are: (D1) a Python UnboundedSource API with its SDF-based wrapper, (D2) a native Watch transform with PollFn and TerminationConditions, (D3) a test suite spanning DirectRunner and Dataflow, and (D4) supporting documentation including docstrings, programming-guide updates, and migration notes.
<p>The project is a demo for the Hydra draft proposed by the W3C. It aims to build a smart client and server that is able to exchange information in an efficient manner over a RESTful API using a Hydra based vocabulary. A smart client is able to communicate with the server even without previously knowing the supported methods of the server. This is made possible using Hydra's API documentation method. Hydra is a push towards the idea of semantic web and it's potential as a mean of communication is demonstrated in this project. This project lays the foundation for a larger project that showcases Hydra's full potential.</p>
This project proposes building a new, modern web UI for Mifos X using React, Tailwind CSS, TypeScript, and ShadCN components. The new Mifos X will be integrated with the Apache Fineract backend using the official TypeScript API client to ensure seamless data flow and backend connectivity. Deliverables include a fully responsive, modular UI for Mifos X modules and complete integration with Fineract APIs. The new Mifos X will enhance user experience and provide a solid foundation for future improvements.
<p>Smart HTTP/2-based protocol for Infinispan.</p> <p>The Infinispan Server distribution contains a server module that implements Infinispan’s custom binary protocol called Hot Rod. The protocol was designed to enable faster client/server interactions compared to other existing text based protocols and to allow clients to make more intelligent decisions with regards to load balancing, failover and even data location operations.</p> <p>In 2015 the 2nd version of HTTP protocol (simply HTTP/2) was finally introduced. HTTP/2 provides a lot of features that are also implemented in Hot Rod protocol. For example, using the HTTP/2 will be more preferable than Hot Rod because the size of the requests and responses will be smaller.</p> <p>Expected results of this project are:</p> <ol> <li>Modify current REST Server endpoint for Infinispan to handle HTTP/2 protocol. Modification will be based on implementing features from Hot Rod protocol to HTTP/2.</li> <li>Create HTTP client on Java.</li> </ol>
<p>The objective of this project is to keep Sugarizer growing by enhancing two core concepts for our deployments: <strong>Security and Availability.</strong></p> <h4>📝 Deliverables</h4> <ul> <li>Fix current issues/features request on <a href="https://github.com/NikhilM98/sugarizer-school-portal-server/issues" target="_blank">Sugarizer-School-Portal</a></li> <li>Update package/chart versions for Sugarizer School Portal.</li> <li>Migrate from deprecated <a href="https://github.com/helm/charts/tree/master/stable/mongodb-replicaset" target="_blank">helm/mongodb-replicaset</a> chart to <a href="https://github.com/bitnami/charts/tree/master/bitnami/mongodb" target="_blank">bitnami/mongodb</a> chart.<ul> <li>While maintaining support on different Kubernetes providers.</li> </ul> </li> <li>Add Two Factor Authentication feature for Sugarizer School Portal to enhance user's security.<ul> <li>TOTP Enable and Disable feature</li> <li>TOTP Verification upon logging in after Two Factor Authentication has been enabled.</li> </ul> </li> <li>Add Two Factor Authentication feature for <a href="https://github.com/llaske/sugarizer-server" target="_blank">Sugarizer -Server</a> Dashboard to enhance user's security.</li> <li>Update the prevailing tests and write tests for new features added.</li> <li>Update Setup Scripts and documentation for <a href="https://github.com/NikhilM98/sugarizer-school-portal-server" target="_blank">Sugarizer School Portal</a></li> </ul> <h4>🎉All of the aforementioned deliverables were attained during GSoC coding period.</h4>