Page tree
Skip to end of metadata
Go to start of metadata


General Information

The JBoss Community is planning to participate in Google Summer of Code in 2021.


All students & developers are welcome to participate in the https://summerofcode.withgoogle.com/   program with the JBoss Community (once JBoss Community is accepted by Google)!


You can take look on org page of Summer of Code website for proceeding with the application process.


If you are a student looking forward to participate in the GSoC 2020 with the JBoss Community, feel free to browse the growing idea list below. Please don't hesitate to contact the mentor(s) indicated in the proposal for any related clarification and to discuss proposals. Students can submit the proposals in 2020.

If you want to suggest an additional idea, please use the page GSoC 19 Student Ideas (you'll need a free JBoss Community account to edit the page). Interested mentors can check the student ideas page and sign up to be a mentor by moving the idea onto the main page.

You can also look at GSoC-16 Ideas2017 Ideas2018 Ideas2019 Ideas and 2020 Ideas for suggestions from last years.

A note to mentors

MENTORS: Red Hat employees can change this page directly to add ideas. Please be extra careful to not get other mentor's edits discarded.
Red Hatters should have linked their jboss.org account with Red Hat and can be checked on https://sso.jboss.org/login

Non Red Hatters can add a comment to the page and admins will make sure the idea is added to the page.


Table of Contents

Administrators and Mentors

We will list the potential mentors in this place. For now, if you have any questions, please contact the GSoC administrators:

George Zaronikas (gzaronikas) Ali Ok (@aliok_tr) and Anuj Garg (@KeenWarrior).

This years GSoC is different.

Previously GSoC was 12 weeks with 30 hours/week commitment by students but this year it is 10 weeks with 18 hours/week commitment. So, it is %50 reduced.

Please consider this in your idea proposals.


Communication channels

Gitter    : JBossOutreach/GSoC - Gitter 


Please take note - These channels are about generic doubts. For project specific doubts you will need to contact project mentors and channels specified in the project description.


Notes for students

Points to consider while choosing any project

1. You meet at least 50 percent of prerequirements. Remaining skills can be honed on the go, so don't worry if you lack some.

2. You can relate with the project idea and you have used something related to the project as user.

3. You are willing more toward learning the skills and less toward boasting about the skills you have already.


Suggested steps after choosing favourite project

1. Start to use product/tool/api as user or hello world client application.

2. Setup the development environment for project and start to use your own build.

3. Look for new comer bugs and try to get your head around them.

4. Let us know if you feel stuck at any stage.


Idea template (for mentors)

Project title

Summary of idea:

-Idea

-Feature A

-Feature B

Knowledge prerequisite: Languages/Technologies goes here

Github repo:

Skill level: Beginner/Intermediate/Advanced

Contact(s) / potential mentors(s): Mentor(s) name and contact details

Associated JBoss community project(s):


Idea Proposals


Thread support in Drogue IoT

Summary of idea:

The Drogue IoT project aims to support different types of connectivity to Drogue IoT Cloud. Although we have drivers and examples for WiFi, LoRa and Bluetooth LE at present, we would like to
expand support to protocols like Thread. There are several building blocks in Thread that is missing from the Rust ecosystem:


  • 6LoWPAN - One building block for data transport is the 6LoWPAN protocol that maps IPv6 on top of link layers like Bluetooth LE or 802.15.4 (used in Thread)
  • DHCPv6 - A DHCPv6 client is needed in order to configure a Thread device with an IPv6 address
  • DNSv6 - A DNSv6 client is needed for a Thread device to map hostnames to IPv6 addresses

Each of these building blocks are probably a project on its own, so its probably best to focus on one.

Knowledge prerequisite:

  • Embedded programming
  • Basic understanding of network programming
  • Reading protocol specifications
  • Rust (optionally)

Github organization: https://github.com/drogue-iot

Skill level: Intermediate

Project Chat: https://matrix.to/#/#drogue-iot:matrix.org

Contact(s) / potential mentors(s): Ulf Lilleengen (lulf@redhat.com)

Associated JBoss community project(s): Drogue IoT


CoAP protocol support for constrained devices in Rust

Summary of idea:

The Drogue IoT project aims to support different types of connectitiby to Drogue IoT Cloud with examples for embedded devices written in Rust. One such protocol is the Constrained Application Protocol (CoAP).

The goal of this project is to provide a CoAP protocol library that compiles and runs on constrained embedded devices (no_std). It is not expected that the entire protocol spec is supported, having a working CoAP client sending
requests to a cloud server would be a great achievement. Reusing existing open source crates and adopting them to support constrained devices is fine, so the first phase of the project would be to identify potential libraries that could be reused and/or adopted.

Knowledge prerequisite:

  • Embedded programming
  • Basic understanding of network programming
  • Reading protocol specs
  • Rust (optionally)

Github organization: https://github.com/drogue-iot

Skill level: Intermediate

Project Chat: https://matrix.to/#/#drogue-iot:matrix.org

Contact(s) / potential mentors(s): Ulf Lilleengen (lulf@redhat.com)

Associated JBoss community project(s): Drogue IoT


MQTT client support for constrained devices in Rust

Summary of idea:

The Drogue IoT project aims to support different types of connectitiby to Drogue IoT Cloud with examples for embedded devices written in Rust. One such protocol is the MQTT (Message Queuing Telemetry Transport).

The goal of this project is to provide a MQTT client library that compiles and runs on constrained embedded devices (no_std). It is not expected that the entire protocol spec is supported, having a working MQTT client sending
unacked MQTT messages to a MQTT server would be a great achievement. Reusing existing open source crates and adopting them to support constrained devices is fine, so the first phase of the project would be to identify potential libraries that could be reused and/or adopted.

Knowledge prerequisite:

  • Embedded programming
  • Basic understanding of network programming
  • Reading protocol specs
  • Rust (optionally)

Github organization: https://github.com/drogue-iot

Skill level: Intermediate

Project Chat: https://matrix.to/#/#drogue-iot:matrix.org

Contact(s) / potential mentors(s): Ulf Lilleengen (lulf@redhat.com)

Associated JBoss community project(s): Drogue IoT


New Drogue IoT protocol endpoint

Summary of idea:

On feature of Drogue IoT Cloud is to normalize the transport protocol from IoT specific protocols to Cloud Events. We currently have endpoints for MQTT and HTTP. However, there are much more protocols out there that could be added, like CoAP for example.

Choosing a protocol you would like to implement must be done as part of the project proposal, and not as part of the project. There is no need to implement whatever protocol you choose from scratch. The focus should be on the integration of the protocol to the cloud deployment, not on implementing the protocol itself.

The current protocol endpoints are written in Rust. However, implementing your protocol endpoint in Rust is not a requirement. Still, it would be a chance for you to learn about an awesome programming language, if you are up for that challenge.

Knowledge prerequisite:

  • Kubernetes
  • Knative
  • Rust (optionally)

Github repo: https://github.com/drogue-iot/drogue-cloud

Skill level: Intermediate

Project Chat: https://matrix.to/#/#drogue-iot:matrix.org

Contact(s) / potential mentors(s): Jens Reimann (jreimann@redhat.com)

Associated JBoss community project(s): Drogue IoT


Implement "Hey Rodney" Drogue IoT demo using Tensorflow (Lite)

Summary of idea:

In Drogue IoT we have an example/demo/PoC, which implements a voice assistant based on our Drogue IoT cloud deployment. There is wake-word/keyword/trigger-word detection, which initiates the audio recording. Once the snippet is recorded it will be processed by a speech-to-text backend and is further processed.

For the wake-word detection we are currently using Pocketsphinx. However, the detection rate is pretty bad. Also it doesn't run on embedded devices.

The outcome of the project should be to use Tensforflow (Lite) to create a model for wake word detection. Additionally a program (script) which continuously listens to audio input (microphone). Once the trigger is detected, it records for up to X seconds, or until it detects silence. A single command is sufficient ("hey rodney"), no full speech-to-text model is required. It is perfectly fine to re-use existing data sets and scripts, as long as they are open source, and we can build this ourselves.

This should be able to run on a Raspberry Pi like device, with the prospect of being able to run on embedded devices (microcontroller) using Tensorflow Lite. Bonus points for actually porting that to a micro-controller, but that is not required.

Knowledge prerequisite:

  • AI/ML - Tensorflow
  • Python (probably)
  • Linux
  • Embedded programming (optionally)

Github repo: https://github.com/drogue-iot/drogue-cloud, https://github.com/drogue-iot/hey-rodney

Skill level: Advanced

Project Chat: https://matrix.to/#/#drogue-iot:matrix.org

Contact(s) / potential mentors(s): Jens Reimann (jreimann@redhat.com)

Associated JBoss community project(s): Drogue IoT


EAT  - Testing Infinite Software Project Versions

Summary of idea:

The innovative part of EAT is creating the test once and testing with any version of the tested software. It may be firstly applied for the JBoss Servers, but, in general, a similar structure, can be used for creating tests about any software with multiple versions or for multiple software programs that have a part of the testsuite in common. EAT is a project under the ΙΔΕΑ statement.


Possible tasks for this project :

Go through the EAT workshop, extending the existing AT testsuites, creating a new testsuite using the AT Structures, etc (the students should make their proposals)


Github repo: https://github.com/EAT-JBCOMMUNITY/EAT

Contact / potential mentors: Panagiotis Sotiropoulos (psotirop@redhat.com)

Associated JBoss community project: EAT


Drools - Executable Model Compiler 2.0 

Summary of the idea:

Drools is a business rules management system that allows developers and business analysts to write business rules in an easy way and to evaluate such rules in the fastest way possible. With the “executable model” we provided a Java DSL to write such rules in a typesafe way, leveraging the javac compilation to get fast startup time while instantiating the engine. The original DRL (Drools Rules Syntax) language is supported: we provide a compiler to compile the DRL to Java Code.

The original executable model compiler needs some improvement: the idea is to generate the executable model code in the fastest way possible. 

We targeted correctness rather than speed in 1.0, and by rewriting the type checker and leveraging a multi phase approach we could theoretically support parallel compilation. We also have some known performance issues in lambda externalisation - as it’s implemented as a post processing phase it adds extra time to the compilation. We’d love to have a performance oriented approach, in which we measure the build time from the start so that it should be easier to track the wanted speed. Correctness is guaranteed by the current test suite that should be supported 100%. We should avoid JavaParser AST generation in the processing phase, as its AST is not optimized for sharing and cloning it’s an expensive operation.

Project references:

http://blog.athico.com/2018/02/the-drools-executable-model-is-alive.html

https://docs.jboss.org/drools/release/7.48.0.Final/drools-docs/html_single/index.html#executable-model-con_packaging-deploying

Knowledge Prerequisite:

  • The Java Programming Language
  • Basic understanding of Pattern Matching
  • Basic understanding of Rule Engine

Skill Level: Intermediate

Contact: Luca Molteni (lmolteni@redhat.com)

GitHub: 

https://github.com/kiegroup/drools

https://github.com/kiegroup

Associated JBoss community project(s): https://drools.org


3scale - Envoy proxy authorization cache

Summary of idea:

3scale is an API management platform that provides API lifecycle management, access control, developer portal, and gateway integration. This project aims to implement an authorization cache locally accessible from Envoy proxy-wasm modules that contains 3scale-specific knowledge to intelligently cache request authorization results in order to minimize request latencies while keeping the 3scale control plane periodically synchronized.

As with many cache implementations, there are trade-offs to be made. In this case we strongly lean towards lower latencies rather than high accuracy, so we can take some design decisions that leverage this fact. The main goal of this cache layer is that it becomes usable locally from proxy-wasm modules, but having it also work standalone deployed as a separate HTTP or gRPC service is a nice extra. Having it return information to the caller so that a proxy can return rate-limiting headers is a requirement. Learning about the 3scale data model and its Service Management API is part of the learning process involved in this project.

References:

Knowledge Prerequisite: 

  • Basic Envoy proxy knowledge
  • Rust
  • gRPC (optional)
  • WebAssembly (optional)

Github organization: https://github.com/3scale

Skill level: Intermediate

Contact(s) / potential mentors(s): Alex Martinez Ruiz (amr@redhat.com)

Associated JBoss community project(s): 3scale API Management


AeroGear - Apache Kafka and GraphQL quick-starts

Summary of idea:

Apache Kafka is a  popular messaging platform that can be used to build reactive backends.
This project aims to provide sample applications (quickstarts) for various programming languages that will use:

  • Postgres (or MongoDb) Databases
  • GraphQL Subscriptions 
  • Apache Kafka for eventing (might use Debezium for database driven events)


Candidates would also need to provide the modular architecture of the examples so they can be consumed with both REST (ServerSent events) and GraphQL subscriptions.

Knowledge prerequisite:

  • Knowledge one of the languages used to write example (Node.js, Python, Golang, Kotlin, ?)
  • Basic understanding of reactive programming
  • Knowledge of GraphQL
  • Familiarity AeroGear community projects like https://graphback.de

Github org: https://github.com/aerogear

Skill level: Beginner

Project Chat: https://discord.com/invite/mJ7j84m

Contact(s) / potential mentors(s): Wojciech Trocki (wtr@redhat.com)

Associated JBoss community project(s): AeroGear


AeroGear - KNative "Herd" CLI

Summary of idea:

Knative is an serverless platform offering ability to deploy your projects to kubernetes. 
In this project we would like to explore ability to build lighweight framework for connecting multiple serverless functions with underlying services and API gateway.
Candidates can work on providing new abstraction on top of the KNative offering ability to create "herd" of functions that can be written in more than one language.
Developers can provide custom configuration for functions and build wrapper for KNative CLI offering simplicity to build and deploy multiple functions as single application.

Serverless functions that can be automatically added to the API gateway serving both GraphQL and Rest endpoints. 

Suggested languages that can be used for building this ecosystem:

  • Node.js
  • Quarkus (Java)
  • Golang
  • Python

Candidates would also need to provide examples of using eventing and database access for at least 1 of the languages.

Knowledge prerequisite:

  • Knowledge one of the languages (Node.js, Python, Golang, Kotlin, ?)
  • Basic understanding of KNative
  • Knowledge of GraphQL
  • Familiarity AeroGear community projects like https://graphback.de

Github org: https://github.com/aerogear

Skill level: Intermediate

Project Chat: https://discord.com/invite/mJ7j84m

Contact(s) / potential mentors(s): Wojciech Trocki (wtr@redhat.com)

Associated JBoss community project(s): AeroGear

Debezium Schema History Compaction Tool

Summary of idea:

Debezium is an open-source platform for change data capture (CDC) and lets you stream data change events out of a variety of databases such as MySQL, Postgres, SQL Server, MongoDB and others. The idea of this proposal is to provide a stand-alone tool for compacting the schema history topic used by several Debezium connectors.

Your mission, should you decide to accept it, will be:

  • Develop a tool – based on the Quarkus stack – which "compacts" a given schema history topic; this tool should
    • Read a schema history topic from the beginning
    • Build up the in-memory represntation of the database schema
    • Serialize that schema into a new topic, only containing the current state of the schema
  • Test that tool
  • Document the usage of the tool, e.g. describing how to re-configure associated connectors, so to make use of the compacted topic, etc.
  • Create a demo (e.g. as a video) and blog post show-casing how that tool can be used

See Jira issue DBZ-747 for further details of this project idea.

Knowledge prerequisite: Java, Git, Maven, at least one of the databases supported by Debezium

Github repo: https://github.com/debezium/debezium

Skill level: Intermediate/Advanced

Contact(s) Gunnar Morling (gmorling AT redhat DOT com)

Associated JBoss community project(s): Debezium

Porting the Debezium Cassandra Connector to Debezium Server

Summary of idea:

Debezium is an open-source platform for change data capture (CDC) and lets you stream data change events out of a variety of databases such as MySQL, Postgres, SQL Server, MongoDB and others. The idea of this proposal is to port the existing stand-alone main class for the Debezium Cassandra connector to Debezium Server as its runtime environment.

Your mission, should you decide to accept it, will be:

  • Implement an outbound adaptor for Debezium Server which sends change events to Apache Kafka (similar to the existing adaptors for Apache Pulsar, Amazon Kinesis, Google Cloud Pub/Sub etc.)
  • Replace the existing stand-alone main class with the Debezium Server runtime
    • Adapt Debezium Server, so that it not only can be used with the Kafka Connect based Debezium connectors, but also with the Cassandra connector implementation
    • Replace means of configuration with those of Debezium Server (application.properties file, etc.)
    • Update tests and documentation accordingly
  • Optional: Refactor the Cassandra connector implementation to make use of Debezium's common connector framework as far as possible
  • Create a demo (e.g. as a video) and blog post show-casing how the connector can be used after this re-implementation

See Jira issue DBZ-2098 for further details of this project idea.

Knowledge prerequisite: Java, Git, Maven; ideally Cassandra

Github repo: https://github.com/debezium/debezium

Skill level: Intermediate/Advanced

Contact(s) Gunnar Morling (gmorling AT redhat DOT com)

Associated JBoss community project(s): Debezium

Knative Autoscaling: Experiment with different algorithms and improve the existing one

Summary of idea:

Knative Serving is a building block for creating a Serverless platform on top of Kubernetes. Its scaling capabilities are among the most important features. However, Kubernetes is not necessarily easy to deal with, when it comes to scaling pods especially if you want to minimize the so called cold-start latencies (a request having to wait until an entire container is spun up), that customers have to take.

Currently, Knative Serving collects traffic metrics from various sources, aggregates them by taking an average over all datapoints and generates its recommendation based on the resulting data.

Your mission is to come up with a much finer hammer than "average the data" that takes the Kubernetes environment into account (i.e. scales down slower than it scales up) and to make sure that the new algorithm doesn't break users of the existing algorithm. As such, the creation of a great experimentation harness will be necessary.

  1. Understand and analyze the environment (Kubernetes, Knative, Serverless) and understand the characteristics that the algorithm has to have.
  2. Create an experimentation harness that allows you (and us) to play with different algorithms.
  3. With that harness, come up with an improvement over the current algorithm.

Knowledge prerequisite: Golang, Statistics, Serverless/FaaS (optional), Kubernetes (optional)

Github repo: https://github.com/knative/serving/

Skill level: Intermediate/Advanced

Contact(s) / potential mentors(s): Markus Thoemmes (mthoemmes AT redhat DOT com)

  • No labels