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.
Apache Beam through its unified model for batch and streaming data-parallel processing pipelines, runners for executing them on a variety of distributed processing backends and ML specialized transforms within MLTransform (such as EmbeddingManager and other MLTransformProvider) make it uniquely positioned for building out RAG (Retrieval Augmented Generation) based applications. These applications are one of the most useful and commonly being built applications on LLMs (Large Language Models). For this project we will focus on building a knowledge base on a vector database for a text corpus, and enriching user's questions with matching text chunks using semantic search. This is a crucial part of any RAG applications and helps us in building the right prompt context for LLMs. We will implement the following deliverables to achieve this: 1. Build a Beam pipeline that takes in a batch text corpus from a public dataset as parameter to pipeline and uses MLTransform to generate and save Embeddings in batch mode to a vector database. - Initial scope: Wikipedia dataset with JinaAI Embeddings read from object storage and written to RedisIO to publish to known vector DB. 2. Build a Beam pipeline that takes in stream of text questions from clients and enriches it with related texts from the vector DB. - Initial scope: KafkaIO based reading of queries which is populated by producers independently and published in a different topic for results. 3. New enrichment handlers for vector database queries over Redis based Vector DB Stretch goals: 1. Implement enrichment handlers for OpenSearch (AWS supported)[4] 2. Implement enrichment handlers for Vertex AI Vector Search (GCP Supported)[5] The goal is to demonstrate semantic search building capabilities trivially using Beam and hence evaluation of search results is not tied to a broad benchmark (such as MTEB) for this project's scope.
High-fidelity detector simulations are critical for accurate analysis in particle physics, but traditional Monte Carlo-based methods are computationally expensive. DeepFalcon introduced a promising approach using Graph Variational Autoencoders (GVAE) that treat particle hits as graph nodes, enabling faster inference while maintaining high accuracy. This implementation used CMS Open Data of boosted top quark jets and considered only the ECAL layer of the detector, achieving a 400× speedup in reconstructing jets compared to traditional simulations. The model architecture employed GraphSAGE layers and mincut pooling, while training used Adam optimizer with a hybrid loss function combining MSE and KL divergence. However, the current approach is limited to single-layer detector responses and doesn't fully capture the correlations between multiple detector components. This project aims to extend DeepFalcon’s GVAE architecture to support multi-layer detector systems, specifically incorporating Tracker, ECAL, and HCAL layers simultaneously. The proposal is structured into two phases: Phase I will focus on enhancing the graph data representation by including all three detector layers and designing optimized connectivity patterns that capture spatial and inter-layer dependencies. Phase II will explore advanced pooling techniques and alternative message-passing strategies to improve latent representation quality and model generalization, while maintaining fast inference speeds. All components will be implemented using Python and relevant machine learning libraries such as PyTorch Geometric. Expected deliverables include a multi-layer GVAE model, benchmark comparisons against existing results, and detailed analysis of the architectural choices. This project contributes toward advancing fast simulation techniques in high-energy physics by enabling more comprehensive and scalable detector modeling.
PostgreSQL introduced Server API and ABI Stability Guidance to help extension authors understand compatibility expectations. The policy ensures ABI stability between minor releases (e.g., 17.0 to 17.1) but allows changes in major versions. Currently, committers rely on manual reviews to enforce this, which occasionally leads to unintended ABI changes. A recent example occurred in PostgreSQL 17.1, where an ABI-breaking change was shipped and later reversed in 17.2. This incident highlights the need for an automated process to catch such issues before release. To enforce ABI stability, this project will monitor PostgreSQL’s repository across STABLE branches, detecting any ABI breakage early. Since ABI changes depend on system architecture, OS, and compiler, the tool will be developed as an extension to PostgreSQL Build Farm, leveraging its infrastructure to handle diverse configurations. Git receive hooks are unsuitable as PostgreSQL does not allow them due to repository performance concerns. As the frequency of commits on the PostgreSQL stable branches is very low, build farm’s cron based clients (animals) can simply compare the latest commit build(which it already does) with the latest release tag or the most recent minor release to get the ABI breakage, if any. The Libabigail suite (abidw, abidiff) will be used for ABI compliance checks, currently supporting GCC and Clang, with future expansion planned for other compilers. The system will generate ABI compliance reports on every run and will send to the build farm server and notify the community about breaking changes. This project will include the development of a Build Farm Client Perl Module that generates ABI compliance reports and report any ABI Breaks to the community. This project will strengthen PostgreSQL’s ABI stability process, preventing unintended breakages and ensuring smoother minor releases.
Frameworks like PennyLane and Qiskit handle circuit construction and simulation well but provide almost no tools for measuring the quantum resources a circuit uses. No unified library exists to assess profiling entanglement, magic, or Bell nonlocality. I propose a PennyLane-based library computing four resource classes through a single resource_profile() API: entanglement (Meyer–Wallach, Von Neumann entropy, concurrence), magic (Stabilizer Rényi Entropy), mana (discrete Wigner negativity for qudits), and Bell nonlocality (CHSH values). Since PennyLane QNodes are differentiable, the measures inherit gradient access for tracking resource shifts during training. I also propose benchmarking across QAOA for MaxCut, Quantum Phase Estimation, VQE for molecular ground states (H₂, LiH), and quantum autoencoders for BSM event detection following Duffy et al. (arXiv:2407.07961). The study would record resource trajectories per epoch and test whether the resource decrease Duffy et al. observed generalizes, via Spearman correlations and Mann–Kendall trend tests. This project grows out of my prior work. My Quantum Encoding Atlas library (DOI: 10.5281/zenodo.18780936) benchmarks 16 encodings across PennyLane, Qiskit, and Cirq, and my 12 QMLHEP15 evaluation tasks span quantum circuits, GNNs, equivariant QNNs, RL for PQC optimization, and contrastive learning. Running those benchmarks I identified SRE as a missing diagnostic, which inspired me towards this project. Deliverables: 1. Python package on PyPI with entanglement, magic, mana, and nonlocality modules. 2. Circuit profiler for epoch-level resource tracking. 3. Benchmarking dataset for all four algorithms. 4. Resource–performance correlation analysis. 5. API docs and Jupyter notebook tutorials. 6. Two blog posts per ML4SCI requirements. Stretch: tensor network SRE approximations beyond 10 qubits and integration with Knipfer et al.'s agent-based VQC design (arXiv:2602.19387).
<p>OpenEverest is an open-source cloud-native database platform that helps developers deploy and manage PostgreSQL, MySQL, MongoDB, and other databases on Kubernetes. In V2 it uses a plugin architecture where database providers define their UI through declarative YAML schemas (UISchema in Provider CRD). Currently, plugin developers have no integrated tool for developing and testing these schemas — the only way to see the rendered result is to deploy a full Provider CRD into a running Kubernetes cluster, making the development cycle slow and error-prone. This project aims to build a Plugin Developer Playground — a page inside OpenEverest where plugin developers can write UISchema YAML, see the rendered form in real time, validate the schema structure, inspect the post-processed API payload, and save/share schemas, all without deploying to a cluster. The mentee must solve the CSP compatibility problem by either choosing a CSP-compliant code editor or proposing an isolation architecture (e.g., sandboxed iframe) that keeps the main application's strict security posture intact.</p><p><br></p><p>Expected Outcome:</p><p><br></p><ul><li>Split-pane YAML editor with syntax highlighting and live form preview using the existing `UIGenerator` component</li><li>Real-time schema validation: YAML parsing errors and structural validation against the `TopologyUISchemas` type, with inline error markers in the editor</li><li>Live form rendering with stepper navigation through schema sections and topology switching</li><li>Dynamic field support: existing API provider fields load real data from the running OpenEverest instance; new/unknown provider types can be mocked</li><li>Output panel displaying the JSON payload after form data post-processing</li><li>CSP-compliant solution</li><li>Unit tests for core logic (schema validation, persistence, mock data injection) and component tests for key panels</li><li>Plugin developer guide for using the playground and the UISchema format</li></ul>
<p>Kuadrant's MCP Gateway is an Envoy-based gateway for Model Context Protocol (MCP) servers. It currently handles authentication and coarse-grained authorization via AuthPolicy/Authorino, but has no built-in mechanism for tool-level authorization, e.g., allowing agent A to call `add` and `subtract` on a math server while agent B can only call `subtract`. The kube-agentic-networking SIG is defining a standard AccessPolicy CRD for exactly this. MCP Gateway is well-positioned to implement it because its ext_proc already parses MCP request bodies and exposes tool metadata via headers (`x-mcp-method`, `x-mcp-toolname`, `x-mcp-servername`). This project will design how AccessPolicy maps to Kuadrant's AuthPolicy/Authorino, then build an experimental implementation covering CRD definition, a controller that translates tool-level authorization rules into Authorino configuration, identity model integration (starting with OIDC), `tools/list` response filtering so callers only see tools they're authorized to use, and CEL-based authorization expressions. The mentee will work closely with mentors on the design doc, pair on implementation decisions, and engage with both the Kuadrant and kube-agentic-networking communities.</p><p>- Expected Outcome:</p><p> - Design document covering AccessPolicy-to-AuthPolicy/Authorino mapping, body parsing strategy (ext_proc vs Envoy MCP filter), identity model choices, `tools/list` filtering, and CEL-based authorization</p><p> - AccessPolicy CRD with status conditions and CEL validation rules</p><p> - Controller that watches AccessPolicy resources and generates/updates AuthPolicy resources with authorization rules based on `x-mcp-toolname` headers</p><p> - OIDC identity source support, with consideration for ServiceAccount and SPIFFE identity types</p><p> - `tools/list` response filtering so callers only see tools they are authorized to invoke</p><p> - CEL-based authorization rule support (e.g., `request.mcp.tool_name.startsWith("read_")`)</p><p> - E2E tests covering allow/deny scenarios for tool-level access control</p><p> - Documentation guide in `docs/guides/`</p><p><br></p>
<p>Kuadrant's MCP Gateway uses an Envoy external processor (ext_proc) to parse MCP JSON-RPC requests, extract metadata, rewrite request bodies, and route tool calls to backend MCP servers. This works but adds latency via a gRPC hop per request and requires maintaining custom MCP protocol parsing logic. Envoy has been rapidly adding native MCP support, as of v1.38, the Envoy MCP filter can parse MCP messages, populate dynamic metadata for downstream RBAC/ext_authz filters, handle session management, support SSE and Streamable HTTP transport, and aggregate multiple backend MCP servers. A previous investigation rejected the Envoy MCP filter due to missing body modification support, limited method coverage, and no aggregation, but the filter has since evolved considerably. This project will perform a fresh evaluation, produce a design document mapping each ext_proc responsibility to native Envoy capabilities, identify gaps (particularly around request body rewriting for tool prefix stripping and dynamic metadata consumption by Authorino), build a proof-of-concept demonstrating the native filter approach, and propose an incremental migration path. The mentee will work closely with mentors on the design, validate assumptions through prototyping with standalone Envoy, and engage with both the Kuadrant and Envoy communities.</p><p><br></p><p>Expected Outcome:</p><p> - Design document covering capability mapping of each ext_proc responsibility to Envoy MCP filter features, body modification strategy, dynamic metadata vs header trade-offs for Authorino integration, federation/aggregation comparison, session management analysis, and Istio version dependency chain</p><p> - Proof-of-concept demonstrating Envoy MCP filter parsing requests and populating metadata, downstream authorization consuming that metadata, and tool routing to multiple backends</p><p> - Clear identification of what still requires custom code after migration</p><p> - Proposed target architecture and incremental migration plan</p><p> - E2E tests validating the prototype against existing test scenarios</p><p> - Documentation of Istio version requirements and feature gates needed</p><p><br></p>
<p>Hyperledger Fabric-X introduces a new architecture for Fabric, with decomposed services for ordering, endorsement, validation, and committing, but its current developer workflow is still centered around dedicated deployment scripts and Ansible-based setup.</p><p>Fablo, on the other hand, is widely used to start Hyperledger Fabric networks quickly from a single configuration file for local development, CI, and experimentation.</p><p>This project will explore and implement the best path to support a simple local Fabric-X network through the Fablo experience. We will evaluate architectural options such as a new engine, a separate repo, or an extension/wrapper approach, then build a minimal but practical MVP that can generate configuration, bootstrap the required components, and start/stop a working local Fabric-X network. The goal is to reduce setup friction for contributors and users, and provide a repeatable developer workflow, examples, and documentation that make Fabric-X easier to try, demo, and extend.</p><h3>Learning Objectives</h3><ul><li>Understand the architecture and deployment model of Hyperledger Fabric-X, including how it differs from classic Hyperledger Fabric.</li><li>Learn how to design contributor-facing tooling for distributed systems with evolving architecture.</li><li>Gain experience in open source development across CLI/tooling, configuration generation, testing, and documentation.</li><li>Develop practical skills in Docker-based environments, and debugging multi-component systems.</li></ul><h3>Expected Outcome and Deliverables</h3><ul><li>A design proposal describing the recommended integration path between Fablo and Fabric-X (for example: separate repo, pluggable engine, or wrapper-based approach).</li><li>An MVP implementation that can bootstrap a simple local Fabric-X network and manage its lifecycle.</li><li>Example configuration(s) and sample workflow for running Fabric-X through the proposed Fablo-based experience.</li><li>Automated tests and/or validation scripts covering the supported MVP scenario.</li><li>Contributor and user documentation explaining setup, architecture decisions, and next steps.</li></ul><p><br></p><p>Lean more at <a href="https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/83" rel="noopener noreferrer" target="_blank">https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/83</a></p>
<p>Jaeger is the industry-standard platform for distributed tracing. As microservice architectures grow complex, finding root causes in massive trace data becomes increasingly difficult. While Phase 1 of this initiative established a baseline AI assistant for natural language search, the system currently relies on hard-coded capabilities. This project (Phase 2\) aims to transform the Jaeger AI agent from a static chatbot into an extensible, user-programmable platform. The primary objective is to implement a "Self-Service Skills" framework, architecturally similar to "Claude Code Skills." This will allow end-users to teach the Jaeger AI new debugging workflows (e.g., "Analyze Critical Path" or "Detect N+1 Queries") by simply adding configuration files containing system prompts and logic rules, without needing to recompile the Jaeger binary. The applicant will build this extension within the Jaeger v2 (OpenTelemetry-based) architecture, utilizing **LangChainGo** to orchestrate interactions with Language Models (SLMs/LLMs). This project bridges the gap between generic AI reasoning and domain-specific observability expertise.</p><p><br></p><p>**Expected Outcome:**</p><p> - **Skills Engine Implementation:** An approach compatible with our [BYOA (bring your own agent)](https://docs.google.com/document/d/1qD0OpyRfq-JbO6MCB5gmVxsdPcpPhxz1R_pPnKDdYOg/edit?tab=t.0#heading=h.qgr5ifum0a9m) direction that dynamically discovers, validates, and loads user-defined "Skills" (prompts and tool definitions) from configuration.</p><p> - **Smart Analysis Features:** A polished implementation of Natural Language Search and Contextual Trace Explanation that intelligently leverages these loaded skills.</p><p> - **Local-First Support:** Verified compatibility with local model runners (e.g., Ollama, Llama.cpp) to ensure deterministic performance without sending data to public clouds.</p><p> - **UI Integration:** Enhancements to the Jaeger React UI to expose these AI capabilities and visualize the "reasoning steps" taken by the agent.</p><p> - **Documentation:** A complete guide for users on "How to Author Custom AI Skills for Jaeger."</p><p>- **Learning Opportunities:**</p><p> - **Agentic AI Architecture:** Learn to design stateful AI agents in Go that utilize "Tool Calling" and "Reasoning Loops" rather than simple text generation.</p><p> - **OpenTelemetry Internals:** Gain deep familiarity with the OpenTelemetry Collector architecture, as Jaeger v2 is built directly on top of it.</p><p> - **Cloud-Native Engineering:** Experience contributing to a graduated CNCF project, including navigating code reviews, writing design docs (RFDs), and adhering to open-source best practices.</p><p> - **Full-Stack Development:** Practical experience bridging a complex Go backend with a modern React frontend.</p><p><br></p>
<p>Implement Authentication, Security and Streaming in gRPC for R Package</p>
<p>A server-side support platform for Peace Corps' mobile projects</p>
<p>A Recycler View component would be created which can display media along with text</p>
Lightweight, fast API testing environment supporting HTTP, GraphQL, WebSockets, and Server-Sent Events.
<p>ICE and TURN support for Jitsi, SIP message for Apache Camel, WebRTC server probe.</p>
Enhance the C++ LSP server to support parallel file re-indexing during live editor typing in large monorepos.
Implement physically based atmospheric scattering and dynamic planetary shadow cascades using modern OpenGL core profile shaders.
Description: To some extent, Terraform state is the most essential component for cloud resources provisioned by Terraform Controller. We need to better manage the state.
Build an interactive 3D WebGL orbital transfer trajectory tool for computing Hohmann and bi-elliptic transfer orbit energy profiles.