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>Query Optimization is an active field of research in the Database Research Community, researchers have spent significant time and resources studying the state of art in query optimization and continuously improving it through different approaches. At the 2015 VLDB conference, a team led by Dr. Viktor Leis at Munich Technical University introduced a new benchmark suite for evaluating database query optimizers. The research revisited the main components in the classic query optimizer architecture using a complex, real-world data set and realistic multi-join queries.</p> <p>This project aims to obtain the above benchmark suite, obtains an end to end analysis of various components of Derby Query Optimizer, isolate each component’s contribution towards Derby query optimization and improve the components. The analysis obtained will serve as the knowledge base for Derby’s current state of art in query optimization and help in directing future efforts towards improving Derby in the long term.</p>
<p>Brief Explanation: In the past, Kipi-plugins provided a way to export KIPI host data to DLNA/UPNP by a plugin using HUpnp library for Qt. Since porting this tool to Qt5 will not work as HUpnp project is unmaintained and its code is not ported to Qt5. The goal of this project is to find a new way to restore this feature in digiKam core directly (not as a plugin), using a suitable solution to support UPNP/DLNA in the long term.</p> <p>Expected results:</p> <p>Review old plugin code DLNA Export. Review all required features to export digiKam contents through a DLNA server. Implement a DLNA server in digiKam core to export photo and video hosted in physical and virtual collections. The server must have the capability to be restored at each digiKam session. Implement the server configuration panel in digiKam setup. Test the new implementation with DLNA compliant devices, as smartphones, tablets, TVs. Test the new implementation under Windows and MacOS. Write unit tests and documentation.</p>
<h3>Project VI: Publishing Workflow in Joomla!</h3> <p>Main goal is to replace publishing states with flexible workflows. User should can create multiple states and define transitions between them with assign role acl. In the list of items on the back side should be something to perform selected transaction between defined state in item and defined in the transaction. Created component should filter states and transactions by given extension. User for each transaction could define which action of which component will invoke when the transaction is performed.</p> <h3>Milistones</h3> <ul> <li>Schema of database</li> <li>List of states</li> <li>Create, update, delete of state</li> <li>List of transactions</li> <li>Create, update, delete of transaction</li> <li>States to workflows in core components</li> <li>Role ACL to transaction</li> <li>Perform transaction</li> <li>Action invocation</li> <li>Component respect Joomla ACL</li> </ul> <p>*more in Google docs</p>
<p>The project will add the ability to sync events from OpenMeetings Calendar and iCal/CalDAV Protocol. OpenMeetings is a Web-Conferencing and collaboration software which already has a Calendar, but it does not integrate with CalDAV yet. This project aims to include the ability to use the CalDAV as a front-end feature by any user or organization to allow bidirectional access to the calendar server.</p> <p>This task will make use of the CalDAV4j, iCal, and jackrabbit-webdav libraries to implement the CalDAV client for OpenMeetings.</p> <p>This will be done in 3 stages:</p> <ul> <li>Implement client for CalDAV</li> <li>Extend openmeetings-db to store the server credentials and calendar to the database.</li> <li>Extend openmeetings-web to add read and write access to the user's CalDAV server.</li> </ul> <p>CalDAV implementation to the calendar would be one major upgrade to the current OpenMeetings Calendar, which at the moment uses a local database on the OpenMeetings Server to store the calendar data, allowing groups more flexibility in setting and viewing their respective schedules.</p>
<p>hydrus is a set of Python based tools for easier and efficient creation of Hypermedia driven REST-APIs. hydrus utilises the power of Linked Data to create a powerful REST APIs to serve data. At the moment, hydrus does allow POST operation on hydra:Collection, but new functionalities should be added to effectively update, get or delete particular members from a Collection without actually sending the whole collection in the request payload. The flagship server hydrus can only serve static data and does not provide a way to define custom server-side logic. A new feature for dynamic endpoint could be added so that a developer would be able to define logic/functions for how the incoming data is processed on the server end. A lot of improvements are possible in CRUD operations of hydrus, including setting up constraints and handling errors on the server-side depending upon how the data is stored in a Collection. The project also aims to enhance the functionality of hydrus, optimize existing codes and keep it synced with upgrades and development in hydra-python-core, hydra-python-agent, and Hydra specifications.</p>
<p>The project is to rewrite the frontend of OpenDF with ReactJS and Redux. Some UI Components have been done and others will complete through the project. After completion the Frontend will be fully component based frontend. Also testings will be done for the newly created components.</p>
The UI Toolkit serves as a component library tailored for crafting web interfaces within the Jupyter ecosystem, encompassing platforms such as Jupyter Hub, Jupyter Widgets, and Jupyter Lab. With the introduction of this toolkit, the aim is to capitalise on its capabilities to enhance UI consistency and alleviate maintenance overhead. Here's a structured plan to achieve this: 1.Use toolkit search/input for all search/inputs: filebrowser, extension manager, debugger kernel source 2.Use toolkit button for all buttons: Dialog, extension manager, notification, running tabs 3.Use toolkit tree view for all tree view: table of content, debugger variables and running tabs 4.Use toolkit for the settings editor 5.Add icon component to the toolkit 6.Use toolkit icon for LabIcon 7.Add window split component to the toolkit 8.Add tree grid component to the toolkit 9.Add dock panel to the toolkit 10.Explore switching default renderer in lumino by the toolkit: a.Menu b.Tab panel c.Dock Panel I am committed to collaborating closely with my mentor, @Frédéric Collonval, to tackle these challenges efficiently and deliver tangible results within the stipulated timeframe of the Google Summer of Code program.
The ros2_control framework uses a plugin-based system to support multiple hardware drivers at the same time. It takes care of resource constraints between different controllers and hardware components, asynchronous operation of controllers, etc. As of now, controller_manager publishes the diagnostics of itself, and for controllers and hardware components about their lifecycle state and operational statistics such as their periodicity and their execution time. However, A current limitation of the framework is that hardware components, e.g. the ros2_control hardware driver plugin for a given robot, doesn't have a good API for reporting the diagnostics of its own hardware, for instance, the state of the CAN Bus, some internal motor control board stats like temperature, error codes etc. This integration would make the ros2_control, provide complete diagnostics within its ecosystem. This project focuses on setting up an API that hardware manufacturers & driver maintainers can use to report things with minimal code changes to their existing setups. This project thus aims to add reporting capabilities to the hardware components with minimal changes. It will also aim to unify the three existing hardware interfaces into one as they currently contain a lot of similar code. Furthermore, to enhance the contribution, there will also be focus on adding contributions to exisiting widely used Hardware Interfaces with the new API so that the work is adopted with ease, and the community has better references to work off of.
This project aims to develop a comprehensive Out-of-Tree (OOT) module for GNU Radio that enables amateur radio enthusiasts to incorporate FT8 and WSPR functionality directly into their applications. Currently, most operators rely on standalone applications like WSJT-X, limiting flexibility and integration possibilities. The proposed solution is to create modular, reusable components for encoding, modulating, demodulating, and decoding FT8/WSPR messages. These components will include: FT8/WSPR Message Encoder: Implementing standard message formats with validation for callsigns, grid locators, and signal reports FT8/WSPR Modulator: Building 8-FSK modulation for FT8 and 4-FSK modulation for WSPR with proper timing and tone spacing FT8/WSPR Demodulator: Creating components to detect signals, handle frequency drift, and extract weak signals from noise FT8/WSPR Message Decoder: Implementing error correction algorithms and partial decode support Integration Components: Developing example flowgraphs, time synchronization, and potentially QSO tracking features This module will allow experimentation with weak signal protocols, enable integration into complex signal processing chains, provide educational value for understanding digital mode implementation, and support development of new applications leveraging these protocols—ultimately bringing more skilled contributors to the GNU Radio community.
<p><strong>Security event auditing</strong> permits the selective and fine-grained configurable logging of security-relevant system events for the purpose of post-mortem analysis, intrusion detection, and run-time monitoring and is intended to meet the requirements of the <strong>Common Criteria(CC)/Common Access protection profile(CAPP) evaluation</strong>. The audit subsystem in FreeBSD, <em>audit(4)</em>, can record a variety of system events like user-logins, file system activities, network activities, process creations, etc.</p> <p>The <em>auditd(8)</em> on the server doesn’t generate any record trails for the NFS activities as the audit works mostly on the syscall level and the NFS server is implemented within the kernel.</p> <p>To audit NFS activities within the network, it will require to run the <em>auditd(8)</em> on each NFS client. This arrangement works perfectly fine in case of secure networks. But In the case of an insecure network, running <em>auditd(8)</em> on each client is not an option. The <em>audit(4)</em> support to the NFS server is a missing feature for such networks. Thus, the aim of this project is to <strong>audit each NFS RPC</strong>. This would allow audit of all NFS activities within the network by just running <em>auditd(8)</em> on the server.</p>
<p>Meshery Models are declarative representations of infrastructure and applications. Within these models, Relationships define how different Components (e.g., Kubernetes resources, Cloud services) interact and depend on each other. These relationships are crucial for visualizing, understanding, and managing complex cloud native systems. This project focuses on expanding Meshery Relationships across a wide range of technologies, including Kubernetes and major cloud providers, to better model their interactions and improve user insights. There is a growing need to accurately model these relationships to provide better insights and control over deployments.</p><p><br></p><p> The next phase focuses on Cloud Solution Architecture through workload design by creating and publishing Meshery designs that use the newly developed relationships to represent real-world deployments. These designs will be turned into structured tutorials with hands-on labs using Meshery Playground, offering step-by-step guidance and interactive learning. All content will be reviewed by maintainers and published in Meshery’s official documentation</p><p><br></p><p>Responsibilities:</p><p> - Research and Analyze Technologies: Dive deep into various cloud-native technologies (e.g., different compute services, databases, messaging systems, network services, etc.) to understand their components and how they interconnect.</p><p> - Develop Relationship Definitions: Create and contribute relationship definitions, typically in JSON or YAML format, to the Meshery models.</p><p> - Model Inter-Technology Interactions: Focus particularly on defining relationships between components from different technologies (e.g., how a Kubernetes deployment relates to an AWS RDS instance, or how a Linkerd service interacts with a Prometheus monitoring component).</p><p> - Document New Relationships: Clearly document the newly defined relationships, their purpose, and how they are represented within Meshery designs, contributing to the official Meshery documentation.</p><p> - Create and publish designs that use newly developed relationships.</p><p> - Create and publish hands-on tutorials using Meshery Playground, featuring step-by-step guides and interactive labs that enable learners to apply concepts without the hassle of any configuration.</p><p><br></p><p>Expected Outcome:</p><p> - A multitude of new intra- and inter-service relationships defined across AWS, Azure, and GCP.</p><p> - Creation and publishing of real-world workload designs that represent cloud solution architectures using the newly defined relationships.</p><p> - Tutorials reviewed by various project maintainers and then published in guides/tutorials.</p><p> - Policy Contribution: For advanced interns, there may be opportunities to contribute to the Rego policies that evaluate and enforce these relationships.</p><p><br></p>
<p>The Kuadrant Console Plugin provides a web interface for managing API gateway policies in OpenShift, but currently relies heavily on YAML editing for most policy types. While DNSPolicy and TLSPolicy already have user-friendly form-based interfaces with dual Form/YAML views, validation, and guided workflows, the remaining core policies (RateLimitPolicy, TokenRateLimitPolicy, AuthPolicy, Plan, and OIDC) still require users to manually write YAML. This creates a steep learning curve and error-prone configuration experience. This project aims to bring RateLimitPolicy, TokenRateLimitPolicy, AuthPolicy, Plan, and OIDC policies to feature parity with the existing DNS and TLS form implementations. Form designs will be provided by the Kuadrant team. The mentee will implement these designs as PatternFly-based form interfaces following the established patterns from the DNS and TLS policy forms. These forms will allow users to configure policies through validated form fields while maintaining the flexibility to switch to YAML view for advanced use cases. The forms must support both creation and editing of policies, include proper field validation, handle complex nested structures (such as rate limit configurations and authentication rules), and synchronize seamlessly between form and YAML representations using the same patterns already proven in the DNS and TLS implementations.</p><p><br></p><p>Expected Outcome:</p><p> - Form-based creation and editing interfaces for RateLimitPolicy, TokenRateLimitPolicy, AuthPolicy, Plan, and OIDC policies implemented using the same patterns, components, and structure as the existing DNSPolicy and TLSPolicy forms</p><p> - Dual view toggle (Form View / YAML View) with bidirectional synchronization using js-yaml for all five policy types</p><p> - Field validation following the established validation pattern covering required fields, numeric constraints, conditional dependencies, and Kubernetes resource naming conventions</p><p> - PatternFly component integration matching existing forms: expandable sections for complex nested configurations, validated text inputs, dropdowns for enum fields, and reuse of gateway selection components</p><p> - Policy-specific form fields for: rate limit units and counters (RateLimitPolicy), token-based rate limiting (TokenRateLimitPolicy), authentication strategies and credentials (AuthPolicy), plan tiers and quotas (Plan), and OIDC provider configurations (OIDC)</p><p> - Error handling using the existing error modal and inline validation message patterns</p><p> - Internationalization support for all form labels and validation messages using i18next following the existing localization structure</p><p> - Both create (`/~new`) and edit (`/:name/edit`) routes for each policy type matching the DNS/TLS routing pattern</p><p> - Unit and component tests covering form validation, YAML synchronization, and error states following the established testing patterns</p><p><br></p>
During the 2018 GSoC period, web components of FHIR Resource using Polymer.js were written. This project is to use those web components to completely re-write the UI of LibreHealth Radiology and LibreHealth Toolkit and make them Open Web App modules. The result would be a complete Open Web App with Spring Data on the backend and Polymer.js web components as the frontend
<p>Some functionality in SunPy or in affiliated packages is going to need access to data files on remote (HTTP) servers. Examples of this include data provided by instrument teams relating to the calibrations or performance of the instruments, these kind of data are highly likely to change with time.</p> <p>This project needs to be designed and implemented under the assumptions that SunPy has no control over the data on these servers, and that files on the servers may be replaced with different files with the same name.</p>
<p>I will be working on a couple of UI components for FURY’s UI module. These 2D and 3D components will be sci-fi like as seen in <a href="https://www.youtube.com/watch?v=b0ve2nHEVWw" target="_blank">this</a> scene from the movie “Guardians of The Galaxy”.</p> <p>My main objective would be to develop these UI components with their respective test and tutorials such that it adds on to the UI module of FURY and doesn’t hinder existing functionalities/performance.</p>
<p>OpenMRS is based on the principle that information should be stored in a way that makes it easy to summarize and analyze. OpenMRS is a client-server application, which means it is designed to work in an environment where many client computers access the same information on a server.</p> <p>Android client is android based project of open mars which comes in handy when the providers need to use but dont have system or internet access as android client has offline feature which saves the details locally and sync it with server when online</p>
<p>AsyncAPI offers many different ways to reuse certain parts of the document like messages or schemas definitions or references to external files, not to even mention the traits. There is a need for a tool that can be plugged into any workflows and optimize documents that are generated from code.</p> <h4>Some Features of the library:</h4> <ol> <li>Reuse of components.</li> <li>Duplicated schemas moved to components and ref-ed from a message.</li> <li>Remove unused components.</li> </ol>
<p>This project is about creating a responsive dashboard framework for extensive exploration, monitoring, and reviewing large neurological imaging datasets present on the XNAT server instance. This dashboard will fetch data from any XNAT instance servers and will generate highly-visualized, summarized representations of complex scientific data present on the servers and facilitate user navigation through large cohorts. This dashboard will be a light-weight, flexible, and modular framework that can adapt and change as per the new needs of the users.</p>
Jaeger is a distributed tracing platform. Jaeger V2 is a major new version where we rebase all Jaeger backend components (agent, collector, ingester, and query) on top of the OpenTelemetry Collector. Currently jaeger-v2 components are initialized without observability clients. We need to instantiate appropriate logging, tracing, and metrics clients and pass them to the components. The existing code uses internal metrics API, which needs to be bridged to OTEL metrics to minimize code changes. Expected Outcome: Achieve parity in observability of jaeger-v2 compared to jaeger-v1
A collaboration server is owned by Mission Support System. Local users can be created by using this server. Existing identity providers using SAML 2.0 are desired to be used. A service provider (SP) needs to be implemented on the server side in the existing WSGI application and an authentication into the QT client application. When a user logs in on the QT client, a browser will be triggered for the login process. The QT client user can authenticate afterward by exchanging a one-time token. To test the system, a local identity provider (IdP) will be configured and a few tests will be added.
Description: OpenEBS is completely Kubernetes native and is implemented using microservices. OpenEBS can be installed via kubectl or helm chart and managed via Kubernetes custom resources. To improve the usability of OpenEBS, the proposal is to have easy to use OpenEBS CLI (similar to kubectl) to perform operations like: - upgrade => Upgrade OpenEBS pools and volumes - status => Print the readiness of various components, verify prerequisites are met to run openebs pools and volumes. - version => Print the OpenEBS version and associated images - describe => Describe OpenEBS component status like component/control plane, pools and volumes. - create => Create OpenEBS resources - delete => Delete OpenEBS resources
Make the developer experience for Carbon developers better by adding support for Carbon to editors and IDEs. Possible tasks include: Create an "official" VSCode extension with a mirror repo and packaging similar to the Vim repo we provide. Add syntax highlighting using a Tree-sitter grammar for Carbon. Create a language server for Carbon Deliverables • A working language server for Carbon that supports features like code completion, diagnostics, and go to definition. • A parser that can handle incomplete or erroneous input and produce a Carbon AST. • A test suite that verifies the correctness and performance of the language server. • A tree-sitter parser for Carbon that passes the explorer test suite. (Optional)
CodeLabz is an open source tutorial platform by C2SI built on React, Redux, and Firebase. The codebase has no TypeScript, uses deprecated MUI v4 patterns, React Router v5, and lacks key features like notifications and progress tracking. I will complete the TypeScript migration of the entire frontend and Cloud Functions, upgrade React Router v5 to v6, migrate MUI v4 styling to the modern sx prop, improve UI/UX across all pages, implement organization RBAC, build a real time notification system with Pub/Sub architecture, build an interactive quiz and progress tracking system, and optimize Firestore queries by adding missing composite indexes.
This project aims to integrate bytetrack algorithm into a Mediapipe graph using OpenVINO inference calculators. The bytetrack graph will be deployed on OpenVINO model server to perform efficient object tracking on a video input. The deliverables of this project include a bytetrack graph in OpenVINO mediapipe fork with custom calculators, YOLOv10 model and bytetrack graph packaged in OpenVINO model server, and a Python client for the bytetrack graph to perform bytetrack algorithm on video stream. The final phase of this project includes evaluation of bytetrack on metrics MOTA, IDF1, and HOTA. The goal of this project is to bring the bytetrack algorithm to OpenVINO model server to leverage its efficiency, scalability, and robustness for production-grade inference.