Google Summer of Code 2026 proposed ideas

Contributors interested to participate should check which of the following projects fits their interests and skills.

Τo communicate with the mentors and ask questions about the projects, students should subscribe to this list and post relevant questions. Please follow the Proposal Template

For practical information, developers should visit this page.

VS Code pluggin for CScout

Brief Explanation

The objective of the proposed project is to create a Visual Studio Code plugin for accessing the functionality of the CScout source code analyzer and refactoring browser for collections of C programs.

CScout can process workspaces of multiple projects (a project is defined as a collection of C source files that are linked together) mapping the complexity introduced by the C preprocessor back into the original C source code files. CScout takes advantage of modern hardware (fast processors and large memory capacities) to analyze C source code beyond the level of detail and accuracy provided by current compilers and linkers. The analysis CScout performs takes into account the identifier scopes introduced by the C preprocessor and the C language proper scopes and namespaces. CScout has already been applied on projects of tens of thousands of lines to millions of lines, like the Linux and FreeBSD kernels and the Apache web server.

Having VSCode act as a front-end to CScout’s existing batch analysis will work as follows.

• Trigger explicit runs (command palette / tasks), not on-save analysis.
• Present results as:
  • Navigable diagnostics
  • Cross-reference views (definitions, uses, dependencies)
  • Refactoring previews as diffs
  • Project-wide facts (identifier scopes, file coupling, macro effects) that are otherwise buried in textual reports

This will offer the following advantages

• Lower adoption barrier: developers are far more likely to try CScout if results appear inside their editor instead of via reports or bespoke UIs.
• Natural fit for whole-program analysis: VS Code already supports long-running, cancellable tasks with progress reporting.
• Superior comprehension UX: jump-to-definition, peek views, code lenses, and diff previews make CScout’s semantic information immediately actionable.
• Safer refactoring workflow: preview-first refactorings reduce fear of large, semantics-preserving transformations.
• Separation of concerns: keeps CScout as a standalone engine while the plugin handles visualization and navigation.
• Research leverage: enables realistic user studies (e.g., acceptance of large-scale refactorings, tolerance of latency).
• Longevity and reuse: the same backend can serve CLI, CI, and IDE use; the plugin becomes a thin, replaceable shell.

Thus the plugin will combine CScout’s strengths (macro-aware parsing, precise identifier resolution, and whole-system reasoning) that are hard to appreciate via static reports and tricky to use through the existing rudimentary web front-end. The VSCode plugin combines two open source software projects to provide immediate developer value.

Expected Results

A VS Code plugin that can act as an interface to CScout

Duration of the Project

Large Project – 350 hrs

Related Repositories

https://github.com/dspinellis/cscout

Knowledge Prerequisites

Typescript, C/C++, VS Code API

Mentors

Diomidis Spinellis

OpenTRIM

Brief Explanation

OpenTRIM is an open-source code for simulating the passage of energetic ions through materials and calculating the associated modifications and damage that they cause to these materials. It is based on the kinetic Monte-Carlo method and employs the Binary Collision Approximation to describe the interaction between ions and target atoms. OpenTRIM comprises a set of C++ libraries, a command-line program for executing simulations in batch mode, and a Qt-based graphical user interface for configuring, running, and evaluating simulations. Several parts of the codebase require improvements and extensions.

Expected Results

Real-time 3D visualization tool for simulated ion tracks

Python bindings for running simulations and retrieving results directly from Python

Duration of the Project

Large Project – 350 hrs

Related Repositories

https://github.com/ir2-lab/OpenTRIM

Knowledge Prerequisites

C++

Python (optional)

OpenGL (optional)

Mentors

George Apostolopoulos

Michail Axiotis

Eleni Mitsi

Open-Source AI Framework for Thermal Satellite Payload Data Analysis

Brief Explanation

This project aims to develop a general-purpose open-source AI framework for extracting high-level semantic information from thermal sensor payloads onboard satellites. The framework will support multiple application scenarios such as nighttime cloud detection and thermal event or anomaly monitoring on land and sea.

The project focuses on building a reusable pipeline covering dataset creation and augmentation from real and synthetic thermal imagery, model training and benchmarking, and advanced analysis tools such as uncertainty quantification and explainability. The goal is to provide a practical and reproducible platform for thermal remote sensing applications in Earth observation and small satellite programs.

Expected Results

Modular AI pipeline for thermal satellite data processing

Dataset extraction, preprocessing and labeling workflows

Baseline and benchmarked ML/DL models

Uncertainty quantification methods

Explainability tools

Public open-source releases with documentation

Duration of the Project

Large Project – 350 hrs

Related Repositories

https://github.com/Orion-AI-Lab

https://github.com/Orion-AI-Lab/TIRAuxCloud

Knowledge Prerequisites

Python

Machine Learning / Deep Learning (PyTorch or similar)

Image processing fundamentals

Geospatial / satellite imagery familiarity

Interest in remote sensing and explainable AI

Mentors

Christos Chronis

Alexis Apostolakis

Simon Vellas

Command & Data Handling Software for Open-Source CubeSat FlatSat Testbed

Brief Explanation

The CubeSat FlatSat testbed is a ground-based platform for deploying and testing onboard AI algorithms, end-to-end processing pipelines, and avionics software/hardware. It supports onboard processing validation and serves as a development platform for university student projects and future open-source CubeSat missions.

Expected Results

C&DH flight software on STM32 with FreeRTOS

Inter-subsystem communication using CSP over CAN

NASA cFS-inspired modular architecture

Zenoh middleware for high-bandwidth payload data

Unit tests and integration tests

Architecture documentation and developer guides

Public open-source release on GitHub

Duration of the Project

Large Project – 350 hrs

Related Repositories

https://github.com/omega-space-group

https://github.com/omega-space-group/orion-cubesat-testbed

Knowledge Prerequisites

Python and C

Embedded systems development

FreeRTOS

CAN bus & networking protocols

STM32 toolchain familiarity

Interest in satellite systems and flight software

Mentors

Christos Chronis

Simon Vellas

GlossAPI: Needs-Driven Evolution of the Dataset Production Pipeline for Greek Language Data

Brief Explanation

This project focuses on improving the GlossAPI dataset production pipeline by addressing practical limitations and gaps that emerge as new datasets are processed and published.

As the scope and volume of Greek-language datasets handled by GlossAPI continue to grow, the pipeline must evolve to remain maintainable, reliable, and adaptable to new use cases. The contributor will work on the reconstruction and evolution of parts of the pipeline, guided by operational needs encountered during dataset ingestion, processing, and publication.

The work will emphasize improvements to the pipeline’s maintainability and usability, while enabling richer interaction and input scenarios that better reflect how Greek-language data is accessed and processed in practice. This includes exploring enhancements related to workflow execution, interaction mechanisms, data acquisition paths, and challenges specific to Greek-language and OCR-derived content.

Expected Results

• Improved maintainability of the GlossAPI pipeline codebase
• Targeted improvements addressing real usage issues in dataset ingestion and processing
• Enhanced support for diverse data sources and interaction patterns
• Incremental improvements tailored to the characteristics of Greek-language data
• Documentation and usage notes supporting long-term sustainability and onboarding

Duration of the Project

Large Project - 350 hrs

Knowledge Prerequisites

Applicants should have good knowledge of Python, Git/GitHub, experience with data processing pipelines

Mentors

Dimitris Athanasopoulos, Nikos Tsekos

GlossAPI: ML-assisted Anonymization Layer and Targeted Pipeline Improvements for Greek Datasets

Brief Explanation

This project focuses on extending GlossAPI with a production-ready anonymization layer for Greek text datasets, addressing a critical need for privacy-preserving dataset publication, while also contributing targeted updates to the existing pipeline based on requirements that emerge during its evolution.

The core of the project is the design and implementation of an ML-assisted anonymization module that detects and masks sensitive personal information (such as names, emails, phone numbers, and organizations) in Greek text. Due to the linguistic characteristics of Greek and the presence of OCR noise in many datasets, the anonymization layer will explore and evaluate multiple approaches, including rule-based techniques and ML-based methods such as Named Entity Recognition, potentially using transformer-based or other state-of-the-art models depending on empirical results.

Expected Results

• Integrated anonymization module for Greek text datasets within GlossAPI
• Detection and masking of common personal identifiers (names, emails, phone numbers, organizations)
• Targeted updates to specific parts of the GlossAPI pipeline, limited to what is necessary to support anonymization
• Documentation and usage examples for maintainers and future contributors

Duration of the Project

Large Project - 350 hrs

Knowledge Prerequisites

Applicants should have good knowledge of Python, Git/GitHub, Basic NLP/ML concepts, and Regular expressions.

Mentors

Myrsini Ioannou, Nikos Tsekos, Dimitris Athanasopoulos

FOSSBot Platform: Simulation Enhancements and AI Integration

Brief Explanation

The FOSSBot Platform aims to enhance robotic simulation environments by integrating AI-driven capabilities and improving simulation realism. The project focuses on extending existing open-source robotic simulation tools with advanced features that support experimentation, education, and research in autonomous systems. Emphasis is placed on modularity, extensibility, and reproducibility within open-source ecosystems.

Expected Results

The expected outcomes include enhanced simulation modules, AI-assisted decision-making components, improved documentation, and example use cases. The project will deliver code contributions upstream, along with benchmarks and demonstrations showcasing the improvements in robotic simulation fidelity and usability.

Duration of the Project

Large Project - 350 hrs

Related Repositories

https://github.com/eellak/fossbot-platform https://github.com/eellak/fossbot https://fossbot.gr

Knowledge Prerequisites

Applicants should have good knowledge of JavaScript, Python, robotics simulation environments, and basic AI/ML concepts. Familiarity with open-source workflows and collaborative development is required.

Mentors

Christos Chronis, Eleftheria Papageorgiou, Irida Ntinou

AI assisted KMC

Brief Explanation

This project explores the integration of machine learning techniques into Kinetic Monte Carlo (KMC) simulations. The goal is to accelerate simulations and improve predictive accuracy by leveraging AI models trained on simulation data. The project targets scientific computing and materials science applications.

Expected Results

Deliverables include AI-augmented KMC algorithms, performance evaluations against traditional methods, and a reproducible pipeline for training and inference. Documentation and example experiments will accompany the final implementation.

Duration of the Project

Large Project - 350 hrs

Related Repositories

https://github.com/nixeimar/Apothesis

Knowledge Prerequisites

C++, working knowledge of machine learning techniques, numerical methods, and statistical modeling. Prior experience with scientific simulations is a plus.

Mentors

Cheimarios Nikolaos, Vissarion Fysikopoulos

Unified SBOM Management via RDF Database Abstraction

Brief Explanation

Software Bill of Materials (SBOM) documents, specifically in the ISO standard SPDX format, are becoming the cornerstone of software supply chain security. As the volume of SBOM data grows, simple file-based storage is no longer sufficient for complex analysis and cross-referencing. This project aims to develop a suite of tools to ingest, store, and extract SPDX documents using RDF databases (Triplestores). By utilizing the triplestore Python library, these tools will remain database-agnostic, allowing users to seamlessly switch between backends like Apache Jena, AllegroGraph, Blazegraph, GraphDB, and Oxigraph without changing the codebase.

Background information

Triplestores are a type of database specialized in storing triples, a data structure for representing information in a subject-predicate-object format. They are crucial in semantic web technologies, such as RDF, SPARQL, and OWL. However, there are numerous triplestore alternatives available, each with its own strengths and weaknesses. For GSoC 2025, a Python library abstracting some commonly used databases was developed.

SBOM data in SPDX format can be serialized in RDF, and therefore can be stored in such databases.

Project Description

The current SPDX ecosystem relies heavily on flat files (JSON, RDF/XML, or even Tag-Value for SPDXv2). While effective for transport, these files are difficult to query at scale—for example, when looking for a specific vulnerable component across thousands of SBOMs. Since SPDXv3 is natively based on an knowledge graph model, storing it in a RDF Triplestore is the most logical and powerful way to handle this data. However, different RDF databases have varying APIs and connection protocols.

This project will leverage the triplestore library (which provides a high-level Python abstraction) to build tools that:

- Ingest: Parse SPDX documents (multi-format support) and map them to the unified RDF store.

- Extract: Reconstruct valid SPDX documents from the database based on specific queries (e.g., "Export the SBOM for Project X version 1.2").

- Manage: Provide basic management functions like listing stored SBOMs, deleting old versions, and validating data integrity.

Expected Outcome

By the end of the project, we expect to have a number of well-documented tools that can operate on SBOM data. These will allow users to seemlessly move between SPDX documents and RDF databases.

An indicative list of tools and deliverables is:

- SBOM-to-Store Ingestor: A CLI tool to upload SPDX documents (v2 and v3) into any supported triplestore.

- Store-to-SBOM Exporter: A tool to query the database and output a standard-compliant SPDX file.

- Database Management Utilities: Tools for basic CRUD operations on the stored SBOM data.

- Test Suite: A comprehensive set of tests to verify the abstraction works.

- Documentation: User guide for the CLI tools and developer documentation for the API.

Duration of the Project

Long (350 hours)

Related Resources and Repositories

- https://github.com/eellak/triplestore

- https://github.com/spdx/tools-python

- https://github.com/RDFLib/rdflib

- https://spdx.github.io/spdx-spec

Knowledge Areas

Python3, RDF, SPARQL, SPDX specifications.

Tip for your application: Study SPDX v3 (and v2): SPDX is heavily RDF-centric. Demonstrating knowledge of how 3.0 maps to triples will make your proposal stand out.

Mentors

Alexios Zavras, TBD

Using SWHID to Identify Software Components

Brief Explanation

This project addresses a critical gap in software supply chain security and reproducibility: the connection between package-level identifiers (like package-name@version) and content-level identifiers (SWHIDs).

Background information

Software Hash IDentifiers (SWHID) are a standardized way to identify software artifacts, based on content. The definition is officially adopted as ISO/IEC 18670:2025 and is available at https://swhid.org.

However, most developers interact with software through package managers like Cargo (Rust), PyPI (Python), Maven (Java), or APT (Debian/Ubuntu). There is currently a "semantic gap" between the package version (e.g., requests 2.31.0) and its corresponding SWHID, which depends on its contents.

Project Description

The goal of this project is to develop tooling that automatically computes, verifies, and publishes the SWHIDs for components across major package registries. By creating a verifiable mapping between package releases and SWHIDs, we can enable better SBOM integration, improved vulnerability tracking, and long-term reproducibility of the global software supply chain.

This project will involve three main phases:

- Computation and Archival: Build a pipeline to fetch packages from registries (like Crates.io, PyPI, Maven Central, etc.) and compute their SWHIDs locally to ensure integrity.

- Mapping & Verification: Generate a high-quality dataset that maps registry data (URL and version) to SWHID. This will require handling the specific packaging quirks of each ecosystem.

- Publication: Publish these identifiers in a way that makes them useful to the community. This could include: contributing to a public lookup service or API; exporting mappings to SPDX format; or proposing metadata additions to the package registries themselves.

Expected Outcome

- CLI Tool: A reusable utility that takes a package name/version and returns a verified SWHID.

- Public Dataset: A comprehensive mapping of the most popular packages across ecosystems to their SWHIDs.

- Documentation: A guide on how package maintainers can include SWHIDs in their own release workflows.

- Upstream Contributions: (Stretch goal) Integration with tools like cargo-swhid or pyproject.toml plugins.

Duration of the Project

Short or Regular or Long, depending on breadth and depth.

Related Resources and Repositories

- https://swhid.org

Knowledge Areas

Python and bash scripting (for the solution), knowledge of other ecosystems (Rust, Java, etc.) is required to understand their packaging.

Tip for your application: Study SWHID and the different ecosystems. Demonstrating understanding of ecosystem specific challenges will make your proposal stand out.

Mentors

Alexios Zavras, TBD

Who is who: Alexandria3k entity disambiguation extentions

Brief Explanation

The alexandria3k Python package supplies a command-line tool and an API providing fast and space-efficient relational query access to several large scientific publication open data sets. Data are decompressed on the fly, thus allowing the package's use even on storage-restricted laptops. This project will enhance Alexandria3k by integrating a scalable, high-precision author and affiliation disambiguation pipeline over Crossref metadata that does not rely on ORCID or ROR, using probabilistic clustering optimized for large-scale bibliometrics. We will implement aggressive normalization and blocking to control candidate growth, represent authors as paper-level mentions, and fuse lightweight, interpretable signals—name similarity, affiliation token overlap, co-author graph structure, venue/topic coherence, and temporal constraints—into conservative merge decisions that favor precision over recall. Disambiguation will be incremental and auditable, with stable cluster IDs, merge provenance, confidence scores, and an explicit “unknown” class to avoid over-merging common names. In parallel, we will cluster affiliation strings into canonical organization buckets using country-aware token blocking and city/org matching, enabling robust institution-level analyses even with noisy or missing data. Together, these additions will materially improve the reliability of author- and organization-centric metrics in Alexandria3k while remaining scalable, reproducible, and resilient to incomplete identifiers.

Expected Results

New Alexandria3k actions to dissambiguate authors and organizations by adding corresponding fields in the populated database.

Duration of the Project

Large Project – 350 hrs

Related Repositories

https://github.com/dspinellis/alexandria3k

Knowledge Prerequisites

Python; machine learning; SQL

Mentors

Diomidis Spinellis

Python bindings for Apothesis=

Brief Explanation

This project focuses on creating modern Python bindings for Apothesis to seamlessly connect its high-performance C++ core with Python-based AI workflows. While the existing C++ implementation delivers speed and efficiency for large-scale computation, the lack of native Python integration limits accessibility for researchers and machine learning practitioners who primarily work within Python ecosystems such as NumPy, PyTorch, and TensorFlow. The bindings will expose Apothesis’ core functionality through a clean, Pythonic API, preserving performance while ensuring memory safety and ease of installation. By bridging efficient C++ algorithms with Python’s flexibility and extensive AI tooling, this work enables rapid experimentation, smoother integration into machine learning pipelines, and broader adoption within the research community.

Expected Results

The expected results of the project are the delivery of fully functional Python bindings for Apothesis that provide seamless access to its C++ core from Python. The bindings will expose the main computational components through a clean and intuitive API, while preserving the performance and efficiency of the underlying C++ implementation.The project will also include comprehensive documentation, usage examples, and unit tests to ensure reliability, maintainability, and ease of adoption. Overall, the outcome will be a stable, extensible interface that lowers the barrier to entry for researchers and developers, enabling faster experimentation, improved interoperability with machine learning pipelines, and broader community engagement.

Duration of the Project

Large Project – 350 hrs

Related Repositories

https://github.com/nixeimar/Apothesis

Knowledge Prerequisites

C++, python

Mentors

Cheimarios Nikolaos, Vissarion Fysikopoulos