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.
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.
Wikidata is one of the largest hosts of open data. Missing or new information needs to be added by community members. Otherwise, the knowledge base will dry out and be obsolete after a while. My project's goal is to create an ecosystem that will consist of Web service interfaces to push data from different sources, s.t. researchers. The industry can easily integrate it into their systems and efficiently help to extend the Wikidata knowledge base. The impact of this will be data donations will be possible directly via different sources. The process will become easier and less time-consuming for contributors. Hence, the quality and quantity of the open data offered by Wikidata will increase. I will later try to implement a recommendation engine that suggests agreeable facts to Wikidata editors that are likely to be in their area of expertise. Also, gamification features to show appreciation to Wikidata editors, e.g., a badge Web service allowing users to integrate their score/rank into their profiles on social networks. That will be encouraging for the editors. Goals (1) Implement Webservice interfaces for data donations, i.e., sets of approvable facts (which should also contain links to evidence, etc.) (2) Implement a recommendation engine that suggests agreeable facts to Wikidata editors that are likely to be in their area of expertise. (3) Extend the gamification features to show appreciation to Wikidata editors. Example: a badge Web service allowing users to integrate their score/rank into their profiles on social networks (e.g., on Wikidata’s user page, GitHub profile, Linkedin profile) to show their dedication and activate other users. Impact (1) Data donations are possible and at the same time, an efficient approval process is supported. (2) More fact ingestions with the help of the Wikimedia community. (3) Faster integration of new facts into Wikidata.
<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>Xwiki has pre-existing filter streams converter extension, based on the filter stream framework that allows conversion of different input syntax to desired output syntax. This proposal focuses on improving one such input filter that allows converting from dokuwiki syntax to relevant events. The filter stream extension parses the text format file based storage where the data of the dokuwiki instance stored.</p>
<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>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>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>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
<p>The bhyve hypervisor does not have any sound card emulation at the moment. This project is proposed by Peter Grehan and aims to implement the High Definition Audio Specification which is one of the best performant and supported device in the nowadays operating systems. Some of the reasons to have this device are: support for multiple input and output streams, up to 16 channels per stream, command-response codec communication, DMA channel for each stream and it is interfaced with the PCI bus. The main goal is to have a functional implementation by the end of the summer that will allow playing sounds inside a bhyve virtual machine.</p>
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.
<p>Apitrace is an open source program that allows tracing, replaying, inspecting and profiling OpenGL/Direct3D calls made by any application. Last summer during GSoC 2015 there was developed an abstract interface that allows to use various profiling backends in Apitrace, also several backends (that use OpenGL extensions) were implemented then. The goal of this task is to provide a convenient interface to the new feature in qapitrace. There already exists a version of profiling view in qapitrace. It has only a limited set of old metrics and it might lack some usability features. This GUI project plans to add new metrics, as well as improving the interface overall.</p>
<p>SenZ Switch is a high-speed message passing system which can be used to do the communicating between IoT devices. After connecting the devices to the system, they can share data with the other connected devices. The system acts like a message broker and it does not keep or read any data passing through it. All the messages passing through the system are secured with an End-to-end Encryption method. So this system to can be used to connect private devices also without hesitating.</p> <p>The existing problems of the system are going to be solved and It is planned to modify with some extra features to improve its functionalities. And the system is going to be integrated with Akka Streams which is based on Reactive Streams to provide streaming capabilities.</p>
<p>The APSync project provides a convenient way to extend the capabilities of flight controllers by using companion computers such as the Raspberry Pi 3 and the NVidia Jetson X1. These companion computers can take on a variety of tasks such as onboard image processing, video streaming, telemetry, and autopilot modes.</p> <p>My project aims to improve the video streaming module of APSync by adding support for multiple cameras, video streaming which scales according to the available bandwidth, and a way to provision the GCS with the list of available resolutions of the connected video cameras.</p> <p>This project has been rebranded as APStreamline and will soon be included in an upcoming release of APSync.</p>
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.
<p>Let's imagine a FreeBSD server which collects audit records from machines that are not necessarily using BSM as the format of their audit records. The idea is to create a tool which would be able to load a module, read audit records in a non-BSM format and output audit records in BSM that misses as little data as possible due to the differences between format standards.</p> <p>I’ll focus mainly on the Linux Audit and Windows format.</p> <p>The aim of the project is to ease the maintenance of a network of servers with different audit format. The tool would allow to comfortably manage different audit log files collected from our servers and examine them using default FreeBSD administration tools which support BSM format.</p>
The Kolibri Design System contains resources for designers and developers building Kolibri products. With inclusivity at the heart of Learning Equality’s mission, the purpose of KDS is to reduce the time it takes to design & build products while ensuring accessibility, responsiveness, and cross-browser compatibility. Currently, Data tables in Kolibri and Studio are implemented using CoreTable and SortableHeader components. However, this implementation does not support adding sorting functionality to the tables, which is one of the most common tools for data management. Sorting helps arrange data meaningfully to make it easier to understand, compare, and visualize. Also, using these components leaves too much to the developer to ensure accessibility across all user sections. This project aims to develop a new KDS component, a sortable table to provide a solution to these problems.
The objective is to develop a machine learning model to tag sound effects in streams (like police sirens in a news-stream) of Red Hen’s data. A single stream of data can contain multiple sound effects, so the model should be able to label them from a group of known sound effects like a Multi-label classification problem. The first step would be to develop a baseline model using existing pre-trained deep learning models and add to the Red Hen’s pipeline. Then the performance can be improved using transfer learning and fine tuning the existing model to achieve better accuracy. In this process, the models can be trained on sound effects from noisy or human labeled data sets after they are pre-processed to avoid acoustic domain mismatch problems.
The llama nexus project is an API proxy to provide OpenAI-compatible and unified API endpoints for multiple downstream API servers, including LLamaEdge API servers running open-source LLMs. https://github.com/LlamaEdge/llama-nexus Currently, the Llama Nexus supports the stateless /chat/completions API endpoint for LLMs. We would like to expand this to support the /responses stateful API from OpenAI as well. https://platform.openai.com/docs/api-reference/responses https://platform.openai.com/docs/guides/responses-vs-chat-completions In particular, we aim to implement support for MCP Code interpreter Web search File search Browser use (optional) Expected Outcome: 1. New features for the Llama Nexus proxy server.