JBoss is not accepted to GSoC for the 2023 program. Thanks everyone for your interest. |
The JBoss Community is planning to participate in Google Summer of Code in 2023. All contributors & developers are welcome to participate in the https://summerofcode.withgoogle.com/ program with the JBoss Community. See https://opensource.googleblog.com/2022/11/get-ready-for-google-summer-of-code-2023.html for more information. If you are a contributor looking forward to participating in the GSoC 2023 with the JBoss Community:
Contributors: Please read the list above and also read our contributor guide.
Table of ContentsAdministrators and MentorsWe will list the potential mentors in this place. For now, if you have any questions, please contact the GSoC administrators: George Zaronikas (gzaronikas) and Ali Ok (@aliok_tr) . Communication channelsGitter : 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. Idea template (for mentors)Project titleSummary of idea: -Idea -Feature A -Feature B Knowledge prerequisite: Languages/Technologies goes here Github repo: Project size: medium (~175 hours) or large (~350 hours) Skill level: Beginner/Intermediate/Advanced Contact(s) / potential mentors(s): Mentor(s) name and contact details Associated JBoss community project(s): Idea ProposalsProof of Concept of Kroxylicious implementing Kubernetes Ingress or Gateway API specificationsSummary of idea:
Knowledge prerequisite: Github repo: https://github.com/kroxylicious/ Project size: medium (~175 hours) or large (~350 hours) Skill level: Intermediate/Advanced Contact(s) / potential mentors(s): Mentor(s) name and contact details Associated JBoss community project(s): EAT - Testing Infinite Software Project VersionsSummary 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 :
Project size: large (~350 hours) Github repo: https://github.com/EAT-JBCOMMUNITY/EAT Contact / potential mentors: Panagiotis Sotiropoulos (psotirop@redhat.com) Associated JBoss community project: EAT Horreum - Migrate project to use the latest web stackSummary of idea: The task of this project is to migrate Horreum from the current web stack to the latest version, f.ex. React 17 to React 18. Tasks for this project :
Difficulty level: Medium Project size: Long (~350h) Github repo: https://github.com/Hyperfoil/Horreum Contact / potential mentors: Jesper Pedersen - jesper (dot) pedersen (at) redhat (dot) com Horreum - Security modelSummary of idea: The task of this project is to create a security model for Horreum that will allow for an improved multi-tenant platform. The initial task is described in https://github.com/Hyperfoil/Horreum/issues/78 Tasks for this project :
Difficulty level: Hard Project size: Long (~350 hours) Github repo: https://github.com/Hyperfoil/Horreum Contact / potential mentors: Jesper Pedersen - jesper (dot) pedersen (at) redhat (dot) com Knative - Multiple Knative Eventing control planesSummary of idea: We see more users asking for complete isolation in Knative Eventing deployments. While there are Knative Eventing components that support isolated data planes, we are interested in to see isolated control planes as well. There were discussions about this in the community before and many of the asks were left unadressed. However, we have tools that support multitenancy today, such as kcp. We see this project as an experiment. Expected outcome is finding issues blocking multiple control planes, and possibly fixing them. More info available at https://github.com/knative/eventing/issues/6601 Knowledge prerequisite: Golang, Kubernetes, Knative, Kubernetes Controllers Github repo: https://github.com/knative/eventing/ Project size: 350 hours Skill level: Advanced Contact(s) / potential mentors(s): Ali Ok - aliok AT redhat DOT com, Christoph Stäbler- cstabler AT redhat DOT com Associated JBoss community project(s): Knative / OpenShift Serverless NOTE: This idea is also listed on CNCF GSoC ideas document for more visibility. Knative - Dataplane migration for Apache Kafka communications: From Vert.x to Project LoomSummary of idea: The Knative Broker's data-plane communication with Apache Kafka for consuming and producing records is currently done via the Vertx Kafka client library. The library is basically a wrapper for communications with Apache Kafka inside of the Vertx threading model.The project requires an evaluation the OpenJDK 19 "Project Loom" itself and how to leverage it for efficient communications with an Apache Kafka cluster. The goal of the project is to migrate the usage of vertx for any communications with Apache Kafka to pure OpenJDK 19's Loom, and reduce the number of 3rd party frameworks, such as vertx for Apache Kafka communication. Expected outcome is having a Knative Kafka Broker data plane implementation working on Java 19, leveraging the Project Loom APIs while communicating with Apache Kafka. No usage of the vertx-kafka-client, since all Kafka comms are done via Loom. See https://github.com/knative-sandbox/eventing-kafka-broker/issues/2928 for the upstream ticket. Knowledge prerequisite: Github repo: https://github.com/knative-sandbox/eventing-kafka-broker/ Project size: 350 hours Skill level: Advanced Contact(s) / potential mentors(s): Matthias Wessendorf - mwessend AT redhat DOT com, Pierangelo Di Pilato - pierdipi AT redhat DOT com Associated JBoss community project(s): Knative / OpenShift Serverless NOTE: This idea is also listed on CNCF GSoC ideas document for more visibility. Knative - Porting Knative Serving to MicroshiftSummary of idea: More and more workload is moving towards running on the edge. We saw experiments running Kubernetes on vehicles, fighter jets, 5G antenna and various far edge, near edge and fat edge environments. We would like to see what the challenges are when Knative is run in a resource limited environment. While there are multiple edge-friendly Kubernetes distributions, we would like to see Microshift used as the base platform. Knative consists of Serving and Eventing modules but focusing on Knative Serving as a first step should be more approachable. Stages:
Expected outcome for this project is having Knative Serving with an ingress layer running on top of Microshift. Having a Hello-World Knative Service running on top. Finding issues blocking the edge setup, and possibly fixing them. See upstream ticket for more information: https://github.com/knative/serving/issues/12718 Knowledge prerequisite: Golang, Kubernetes, Knative, good understanding of networking, good understanding of CI/CD Github repo: https://github.com/knative/serving/ Project size: 350 hours Skill level: Advanced Contact(s) / potential mentors(s): Stavros Kontopoulos - skontopo AT redhat DOT com, Reto Lehmann - rlehmann AT redhat DOT com Associated JBoss community project(s): Knative / OpenShift Serverless NOTE: This idea is also listed on CNCF GSoC ideas document for more visibility. Knative - Self-Balancing Knative Kafka Broker partitionsSummary of idea: Creating a Knative Kafka Broker requires developers to specify the number of partitions the backing Kafka topic should have, however, this is not an easy decision to make and it requires planning based on the expected load the Knative Broker could receive. Expected outcome for this project is having a Knative Kafka Broker can be created without setting the number of partitions and the number of partitions for a topic backing the Knative Kafka Broker increases or decreases based on the observed load received. See https://github.com/knative-sandbox/eventing-kafka-broker/issues/2917 for more information. Knowledge prerequisite: Kubernetes, Apache Kafka, Go, Java Github repo: https://github.com/knative-sandbox/eventing-kafka-broker/ Project size: 350 hours Skill level: Advanced Contact(s) / potential mentors(s): Pierangelo Di Pilato - pierdipi AT redhat DOT com, Ali Ok - aliok AT redhat DOT com Associated JBoss community project(s): Knative / OpenShift Serverless NOTE: This idea is also listed on CNCF GSoC ideas document for more visibility. Project Starfix - Open anything anywhere in any IDE/editorSummary of idea: StarFix is a cross-platform client-side application that lets you open a file in the Editor of your choice (vscode, eclipse, intellij, emacs, vi, etc.) and other commands locally directly from the browser or file system. This will enable an option to “Open in IDE” through browser extension on various websites like Github, Gitlab, etc. Moving forward we intend to add more features and capabilities. You can learn more about Starfix at : https://github.com/starfixdev/starfix Possible Tasks for this project:
You can look at more tasks/issues to work here : https://github.com/starfixdev/starfix/issues Knowledge prerequisite:
Github repo: https://github.com/starfixdev/starfix If you want to explore/work in this area and show your experience/interest you can look into contributing to projects like JBang, Quarkus or to Project Starfix directly. Basically any project that relates to developer tools, desktop tools, scripts or browser extensions will be useful experience. Skill level: Beginner/Intermediate Project size: Short (~175 hours) Contact(s) / potential mentors(s): Fahad Israr (fahad00cms@gmail.com) (Can also reach out in the "gsoc" stream at Zulip-Quarkus: https://quarkusio.zulipchat.com/ ) Associated JBoss community project(s): Quarkus, vscode extensions, JBoss Tools 3scale - Proof of Concept: authorino for role-based accessSummary of idea: Authorisation of 3scale using authorino
Knowledge prerequisite: Go or Ruby experience. Github repos: https://github.com/3scale/porta, https://github.com/Kuadrant/authorino Project size: large (~350 hours) Skill level: Intermediate/Advanced Contact(s) / potential mentors(s): Thales Miguel thmartin@redhat.com Associated JBoss community project(s): 3scale 3scale - Auto-generate OpenAPI v3 API DocsSummary of idea: We are migrating our API Docs from OpenAPI v1 to v3. As part of this, we need to have a way to automatically update OpenAPI json files every time a change is made in any endpoint. We are currently using the source2swagger gem for that, but it's abandoned and doesn't support OAS3. A possible way to implement auto-generation for OAS3 is by using the rswag gem, which creates the docs based on the test suite. Knowledge prerequisite: Ruby experience. Github repos: https://github.com/3scale/porta, https://github.com/rswag/rswag Project size: medium (~150 hours) Skill level: Intermediate Further info: https://issues.redhat.com/browse/THREESCALE-8904 Contact(s) / potential mentors(s): Joan Lledo: jlledo@redhat.com Associated JBoss community project(s): 3Scale Proof of Concept of an MQTT to Apache Kafka bridge for producing messagesSummary of idea:
Knowledge prerequisite: Java, MQTT protocol (not mandatory but to be learned) Github repo: It would be part of the CNCF Strimzi project https://github.com/strimzi Project size: medium (~175 hours) or large (~350 hours) Skill level: Intermediate/Advanced Contact(s) / potential mentors(s): Paolo Patierno (ppatiern@redhat.com) Associated JBoss community project(s): Strimzi https://strimzi.io/ WildFly Elytron - A GUI to simplify client side security configurationSummary of idea: The WildFly Elytron project is a security framework for Java clients and application servers. Within the WildFly application server, Elytron is used to secure applications that are deployed to the server and to secure management access to the server. Banks, retail stores, and governments are just some examples of end-users of the enterprise version of the WildFly application server. The WildFly Elytron Client allows remote clients to authenticate using Elytron. When a connection is being established, the WildFly Elytron Client makes use of rules to determine the information that should be used when attempting to authenticate. This includes things like the username, credentials, and authentication mechanisms that should be used. The WildFly Elytron Client also makes it possible to specify TLS configuration. For example, it’s possible to specify the client certificate to present to the server. The configuration used by the WildFly Elytron Client can be specified using an XML file, as described in detail here. The purpose of this project is to create a GUI (graphical user interface) that can be used to generate this XML file automatically rather than requiring a user to write this XML file on their own. The idea is to walk the user through providing the various types of information that can be specified and to use that information to write the XML file. Possible tasks for this project include:
The WildFly Elytron team is a diverse, distributed team that has a lot of experience working with interns and junior engineers. Knowledge prerequisites:
Github repo: https://github.com/wildfly-security/wildfly-elytron Other useful links: Project size: Large (~350 hours) Skill level: Intermediate Project chat: https://wildfly.zulipchat.com/#narrow/stream/173102-wildfly-elytron Contact(s) / potential mentors(s): Farah Juma (fjuma@redhat.com), and Diana Krepinska (dvilkola@redhat.com) Associated JBoss community project(s): WildFly Elytron General purpose programming language that transpiles to C++Summary of idea: Liam is a strongly typed compiled language intended for high performance. It is intended to give the control and speed of languages such as C or C++ but removing the headaches, over complexity and difficult to use build systems. Liam gives modern features without the legacy weighing it down like generic types, function expressions and union types. Possible tasks for this project :
Project size: Medium (~200 hours) Github repo: https://github.com/jackdelahunt/Liam Contact / potential mentors: Jack Delahunt (jdelahun@redhat.com) |