1. Home
  2. Community
  3. Google Summer of Code
  4. GSoC 2024
  5. GSoC project ideas

GSoC project ideas

For information about Haiku's participation in GSoC this year, please see this page.

Qualifying students can apply for a Haiku project (see the list of suggested projects below). For details about how to apply, please check out How to Apply for a Haiku Idea.

The most successful Google Summer of Code projects are often those proposed by the participants themselves. The following list represents some of our ideas and wishes for the project. However, suggesting your own idea is always encouraged!

Be aware: API design and kernel-related work requires a higher level of skill, and user interface design usually involves a lot more thought than other work. A significantly more convincing proposal is required for tasks involving those. Getting started with the design early (before the application period ends) is recommended, to maximize your chances of being selected, and allow a larger part of the coding period dedicated to coding tasks.

If you find one of the "big" ideas interesting, but feel that you cannot complete it within the allotted coding time, feel free to suggest splitting it into smaller parts for your proposal.

Students that intend to submit applications on ideas which are also part of other accepted mentoring organizations must coordinate with both Haiku and the other mentoring organization beforehand.

Project Areas

Applications

Improving Haiku's WebKit video and audio support

Idea description

The WebPositive browser bundled with Haiku uses the WebKit engine (shared with Apple's Safari and a few other browsers) to render webpages. This engine allows several parts of the work to be implemented using existing system libraries, allowing better integration with the existing operating system and reduced overhead.

In particular, the audio and video support for Haiku should be implemented by using Haiku's Media Kit, which is a framework designed for such tasks. This would allow WebPositive to play audio and video on websites such as Youtube.

The current experimental code in WebKit uses the Game Kit and only some parts of the Media Kit, it has problems such as blocking the web browser while downloading the video, out of sync audio and video, and unability to seek inside a video.

  • Project size: 175 hours with possible extensions for 350 hours (adding for example fullscreen video support, work on WebRTC, ...)
  • Difficulty: medium
  • Skill set: userland development, multimedia (audio/video) programming
  • Possible mentors/knowledgeable people: PulkoMandy
  • Expected outcome: working video and audio support, including fullscreen video, without freeze of the browser during media loading.
  • Sourcecode of WebKit ported to Haiku

Improving Haiku's WebKit2 port

Idea description

Haiku has a native WebKit port which uses the WebKit1 API. This port is not complete and there are several bugs and minor problems which need to be fixed. The plan is to replace this with a more up to date port based on the WebKit2 API. Based on the work completed in GSoC 2019, WebKit2 on Haiku is now able to render some web pages. The goal of this project is to continue this work, making the WebKit2 port more reliable, render all pages, handle input events, etc, and make it usable for the WebPositive browser.

Why we need this

The web browser is an important part of the operating system today. It is difficult to attract and retain users if we don't provide a good web browser. When we started our efforts with WebKit, WebKit2 wasn't ready for our use yet, but today it is more mature and it is time to migrate to it.

Further reading
  • Skill set: userland development, exploring a large code-base (WebCore)
  • Possible mentors/knowledgeable people: PulkoMandy
  • Project size: 175 hours with possible extensions for 350 hours as there is always more things to do in WebKit
  • Difficulty: medium
  • Expected outcome: working version of "MiniBrowser" test browser, able to load and render websites using WebKit2
  • Sourcecode of GSoC 2019 work
  • GSoC 2019 blog
  • Opened tickets

Better XMPP instant messaging client for Haiku

Idea description

XMPP is a modern communication protocol for instant messaging. It has open standards and several free software client and server implementations.

Currently, the available native clients for Haiku are quite simple and don't even allow to replace all IRC features. The goal of this project is to improve Renga, one of such clients, to make it possible to migrate Haiku discussion channels over to XMPP instead of IRC.

The main features to implement are more complete support for multi-user chat (in particular, moderation aspects, allowing to manage channel permissions, kick and ban users, etc) as well as any other feature considered useful: message history browsing, message reactions, activity notification, pictures and file sharing, whiteboard collaboration, …

Why we need this

Most of Haiku communication channels are currently hosted on IRC servers. IRC is a simple protocol, but it lacks modern features and is difficult to use from unstable connections or using mobile phones. As a result, IRC is less popular, and a part of the Haiku community doesn't use it anymore.

Since we prefer to support open source software and usage of Haiku, XMPP is a good candidate, if we can have a working native client allowing to use it. We don't want people to instead use closed-source software or undocumented protocols.

Further reading
  • Skill set: userland development, user interface design
  • Possible mentors/knowledgeable people: PulkoMandy, waddlesplash
  • Project size: 175 hours or 350 hours depending on the XMPP feature set being implemented
  • Difficulty: easy
  • Expected outcome: improvements to the Renga XMPP client, implementing the full MUC (Multi-User Chat) XEP including moderation aspects, and/or a selection of XEPs (XMPP extensions specifications) to be determined during the GSoC application period.
  • Renga XMPP client for Haiku

VirtualBox port to Haiku

VirtualBox is a virtual machine allowing to run an operating system inside of another. Porting it to Haiku would allow Haiku users to run another system, such as Windows or Linux, when they need to run an application that is not yet available for Haiku. This would make using Haiku as their primary operating system a viable approach for more people.

Starting from this preliminary work, continue and complete the port. This includes writing a native GUI for VirtualBox, getting it to run, and more importantly, work on the virtualization driver which will allow virtualbox to run the emulated machine using the native CPU. This makes the emulated system run at close-to-native speed, whereas a software emulation would be unbearably slow.

  • Skill set: userland development, kernel development, possibly x86 assembly
  • Possible mentors/knowledgeable people: mmu_man
  • Project size: 350 hours
  • Difficulty: hard
  • Expected outcome: a version of Virtualbox that runs on Haiku and is able to run other operating systems.

Hardware acceleration for Haiku's QEMU port

QEMU is a virtual machine which allows running an operating system inside of another. While there already is a Haiku port, it currently does not support any acceleration system through native virtualization (through Intel VT-x and AMD SVM.) This makes it too slow for many uses. Fixing this would allow Haiku users to run another system, such as Windows or Linux, when they need to run an application that is not yet available for Haiku. This would make using Haiku as their primary operating system a viable approach for more people.

Various systems exist on other operating systems for this, such as KVM on Linux, bhyve on FreeBSD and recently (in 2019) NVMM was added to NetBSD. Intel also has a cross-platform framework called HAXM which only works on their CPUs. All of these work with QEMU, while only some work with other virtual machine technologies like VirtualBox. Of all these NVMM seems to be the easiest to port to Haiku. Bhyve might also be viable, and has been ported to MacOS and Illumos (a Solaris derivative.) A student interested in this project should research NVMM, bhyve and some of the other virtualization systems and describe how they would approach a port to Haiku. Many times these systems make use of kernel technologies that Haiku lacks and so much of this project might involve adding those to Haiku's kernel.

  • Work on a virtualization driver which will allow QEMU to run the emulated machine using the native CPU.
  • Skill set: kernel development, userland development, possibly x86 assembly
  • Possible mentors/knowledgeable people: mmu_man, waddlesplash
  • Sourcecode (QEMU for Haiku)
  • NVMM Sourcecode
  • Project size: 350 hours
  • Difficulty: medium/hard
  • Expected outcome: NVMM driver ported to Haiku, demonstration of QEMU using said driver to accelerate virtual machines.

Devices preferences/Hardware manager

Haiku is meant to be an easy to use graphical operating system. It should provide a GUI to manage devices and drivers. This is currently implemented in the "Devices" preferences, however it does little more than listing devices found on the machine.

The goal of this project is to extend the functionality of Devices preferences to make it a more complete and useful tool. This includes working on the following features:

  • Telling wether a driver is loaded for a given device and where the matching /dev entry is
  • Giving user readable information on the device type and subtype
  • Allowing to block/disable the driver for a given device
  • Support for bluetooth devices (currently not listed at all)
  • Improved support for USB devices, allowing to inspect interface descriptors (like listusb -v), HID report formats, ...)
  • Generation of a "compatibility report" to help populate a hardware compatibility database for Haiku

Note that a lot of the work may be in making the required information available from the drivers and existing device management infrastructure, and not just in building the GUI itself.

  • Skill set: user interface, kernel and drivers interfacing (ioctl, devfs...)
  • Possible mentors: PulkoMandy, waddlesplash
  • Existing code: "Devices"
  • Project size: 350 hours
  • Difficulty: easy/medium
  • Expected outcome: finalized version of Devices application, showing extra information about devices, including but not limited to the driver in use for each device.

Other applications

There are many open source 3rd party applications for Haiku that could use improvements. Whether it is resolving bugs, adding features, updating the coding style, updating them to use the Locale and Layout Kits, or anything else imaginable! Writing applications from scratch is also possible.

  • Skill set: userland development, user interface design, exploring an existing code base, others depending on the application retained.
  • Possible mentors/knowledgeable people (depends on chosen application): PulkoMandy, Scott McCreary, Sean Healy, waddlesplash
  • Project size: 175 or 350 hours depending on the application being worked on
  • Difficulty: easy, depending on the application chosen
  • Expected outcome: new release of the chosen application, including fixes to existing tickets from the respective application bugtracker, and/or other features discussed with mentors and the Haiku community during the application period.

Drivers

GPU acceleration support

Haiku does not currently support GPU acceleration, for 3D or otherwise. Reusing most of the DRM drivers from Linux, and Mesa's Gallium userspace components, the goal of this project is to enable the use of GPU-accelerated OpenGL, and eventually also OpenCL and Vulkan.

Haiku's current video drivers are mostly modesetting-only, and split in two parts: the driver itself, which is quite minimal and only provides low level access to the video card, and the "accelerant", which runs inside app_server and communicates with the driver in order to configure the card and use its features.

Porting the DRM drivers from Linux will be a rather daunting task, as they use a large subset of the Linux kernel APIs. It may be possible to reuse OpenBSD's or DragonFlyBSD's work rather than writing our own Linux API compatibilty layer; more investigation is needed here.

  • Skill set: kernel and driver development, Mesa graphics stack
  • Possible mentors/knowledgeable people: waddlesplash, PulkoMandy
  • Project size: 350 hours
  • Difficulty: hard
  • Expected outcome: proof of concept running an accelerated 3D rendering application based on the ported driver.

Kernel

Power Management

Haiku already has some power management support in the form of a CPU idling driver. This is however clearly not sufficient, and there is room for improvements in several areas in order to make Haiku use less power and make laptops running Haiku last longer on battery.

Some investigation is required to identify the main issues in Haiku leading to suboptimal performance. There are however a few already known problems:

  • Some subsystems such as the network and wireless stack wake up the system at regular intervals (10 or 100 times per second) to perform some tasks. Whenever possible they should be modified to trigger these tasks in an event-driven way (triggering them from hardware interrupts for example).
  • Some applications (such as the always-running DeskBar) are polling for events in a similar way. The APIs should be adjusted where possible to make those applications wait on notifications instead.
  • None of the device drivers in Haiku include powersaving modes. When a device is idle, it should be put to sleep and powered off until it is needed again.
  • Skill set: kernel development, general C/C++, userland development, debugging, power management / measurement
  • Project size: 350 hours
  • Difficulty: hard
  • Expected outcome: improved power management in Haiku code (applications, drivers, ...) with benchmarks to measure the results (this may involve also developping the tools needed for benchmarking)

Improving the btrfs filesystem

Haiku has great support for its own file system, but most others are only available read-only. It is way better for interoperability with other systems to be able to write to these disks from Haiku.

The goal of this project is to complete the btrfs filesystem, to allow it to write btrfs volumes (reading works already). During GSoC 2017 and 2018, students got as far as creating directories, but it is not possible yet to write files. The first part of the work is to review the existing code, and report on the current status and the work needed to get everything in place.

After completion of this project, it should be possible to read and write files to btrfs volumes, making sure they are interoperable with Linux (mount without errors, file data is accessible, fsck detects no problems). Stress-testing should also be performed using bonnie++, and other test suites may also be used.

Adding write support for more filesystems

Idea description

Some filesystems can only be read, but not written, from Haiku. The goal of this idea is to add write support for one of these filesystems (of your choice, from the list below).

  • XFS (Development community, homepage) is a filesystem originally developed for the IRIX operating system. Today it is commonly used by Haiku developers who build Haiku from Linux, because of its better support for extended filesystem attributes (unlike ext4). The read-only support is generally complete but does not use any caching yet. Adjusting the filesystem to use the block and file caches would be a good way to start this project.
  • UFS2 (FreeBSD implementation, u2fstools for windows) is the default filesystem in FreeBSD, commonly used by some Haiku developers as well. It is closely based on the original Unix filesystem, which is implemented in many other operating system. The original design is quite simple, however the different implementations in various systems make it a bit more complex to handle all cases. Focusing specifically on the FreeBSD variant is acceptable for this project if needed. In its current state, the UFS2 driver works in fs_shell but crashes when used as an actual filesystem in Haiku, investigating and fixing this problem would be a good way to start this project.
Why we need this

In its current state, Haiku is rarely used as the single operating system on a computer. It is common to dual boot it with other systems such as Linux or FreeBSD. In this setup, it is very convenient when each system can access and modify the other's files. Disk partitions and data can then be shared more easily.

Further details
  • Skill set: data structures, C++
  • Possible mentors/knowledgeable people: PulkoMandy, waddlesplash
  • Project size: 175 or 350 hours (in 175 hours only partial progress will be possible)
  • Difficulty: medium
  • Expected outcome: write support for the selected filesystem

Filesystems benchmarking and stress-test

Some of the filesystems (or specific features of them) in Haiku are relatively new, and not considered perfectly tested and stable yet. The goal of this project is to define a procedure for testing the filesystems and identifying bugs (especially leading to on-disk data corruption) and performance bottlenecks.

Tools like bonnie++, xfstests, and the existing tests in src/tests/add-ons/kernel/file_systems in Haiku sources should be explored to determine their respective usefulness. Then, an automated way to run the tests should be defined (unit tests, integration tests on a running system, etc.)

Then, the filesystems should be modified to fix the performance problems and/or bugs that were found in the process.

  • Skill set: C++ development, testing
  • Possible mentors/knowledgeable people: PulkoMandy
  • Project size: 175 hours
  • Difficulty: easy
  • Expected outcome: benchmark results, analysis of bottlenecks, implementation of changes to improve the filesystem and related code (VFS, caches, ...) in Haiku.

ARM port and device tree support

Unlike x86 systems which have a PCI bus, most ARM devices have peripherals at hardcoded addresses. This means automatic hardware discovery is not possible. The Linux kernel developers designed a solution called "flattened device tree". It is a static description of the hardware, telling the kernel where devices are located and which driver to use.

Haiku plans to use device trees to support several ARM devices with the same kernel. This requires updating our drivers and driver infrastructure to not rely so much on the PCI bus. This work should start with the USB EHCI driver, in order to provide at least one mass storage solution to the ARM port of Haiku.

The ARM port of Haiku is currently in an early state. This project may involve debugging other issues in the port to get it running further, so that the device tree part can be tested. Several parts of the early boot code should be reviewed to make use of the device tree and remove hardcoded addresses (RAM mapping, framebuffer, serial port, etc).

  • Skill set: kernel development, ARM architecture/assembly
  • Possible mentors/knowledgeable people: PulkoMandy, kallisti5
  • Project size: 175 hours
  • Difficulty: easy
  • Expected outcome: the ARM port of Haiku is bootable on at least one reference hardware (or emulated hardware).

Network

Bluetooth Stack Improvements

Haiku's Bluetooth stack implements a basic subset of general Bluetooth functionality. This functionality needs to be completed and Bluetooth 2.X and later possibilities explored. This task involves investigating the current state of the Bluetooth code, improving the existing code on newer devices (pairing, etc), and improving the stack to make it more useful by implementing driver(s) for Bluetooth device(s) of your choice (file transfers, audio, HID, networking, etc).

  • Requirements: Bluetooth-enabled Haiku system
  • Skill set: C++, kernel development, userland development, global bluetooth stack knowledge (optional)
  • Possible mentors/knowledgeable people: waddlesplash
  • Project size: 175 hours or 350 hours (depending on how much of the stack is added)
  • Difficulty: medium
  • Expected outcome: the Bluetooth stack can be used for more than just pairing devices. For example, bluetooth audio or bluetooth HID drivers can be used.

Integrate our PPP implementation

Finish porting the PPP implementation to our new network stack. Add phone-line modem support, including HDLC framing and VJC compression (porting both algorithms is sufficient, but make sure the license is compatible to MIT). Implement CHAP authentication, and add support for configuring these to the new network preflet GUI. Find and fix bugs.

  • Tickets: #812, #869, #873, #922, #923, #1059, maybe: #1057, #1058
  • Skill set: multi-threading basics, maybe network protocols and some kernel/drivers development, maybe UI development
  • Project size: 175 hours
  • Difficulty: easy
  • Expected outcome: it is possible to connect Haiku to a PPP modem

IPv6 finalization and stabilization

The base framework for IPv6 support was implemented as a Google Summer of Code 2010 project. Even so, there remains a lot of smaller cleanup/finalization tasks that can be done as a project.

  • Tickets to be investigated as part of this project (non-exhaustive list):
    • Trac tickets for IPv6
    • #7228 -- RFC: BNetworkInterfaceAddress needs to store auto-configuration flags
    • #8319 -- Haiku needs IPv6 duplicate address detection during link scope ip configuration.
    • #11862 -- Net server multi-protocol rework
  • Skill set: IPv4 and IPv6 protocols, kernel and network stack development
  • Possible mentors:
  • Project size: 175 hours
  • Difficulty: easy
  • Expected outcome: IPv6 auto-configuration works, and it is possible to access website and other internet services over IPv6

MDNS / Bonjour / Avahi network discovery

Idea description

MDNS (known as Bonjour for Apple devices and usually implemented using Avahi on Linux) is a protocol allowing to discover devices in the local network and their capabilities. The goal of this project is to implement MDNS in Haiku and integrate it in our name resolution system and user interface.

Why we need this

MDNS is part of the IPP Everywhere and Airprint specifications, which allow to use networked printers with a single generic driver, instead of a specific driver for each printer. Having an implementation in Haiku would allow easier setup and use of printers, a required feature for a desktop operating system.

Further details
  • Skill set: network programming (UDP, IPv4, multicast)
  • Possible mentors: PulkoMandy
  • Project size: 175 hours (350 hours with extra goals such as UI integration, IPP printers support, etc)
  • Difficulty: medium
  • Expected outcome: proof of concept application listing MDNS machines and services as they are discovered. Other machines on the network can also see the Haiku machine as it advertises itself.

User Interface

Tracker query window user interface rework

Queries are one of the special features differenciating Haiku from other operating systems. They allow instant search of the complete filesystem, using it like a database. While this is very powerful, it is not always easy to use due to limitations in the user interface.

Starting from existing user interface mock-ups found in Haiku bugtracker here and here, the goal of this project is to improve the "Find" panel in Tracker to make it easier to use queries and manage files with them.

This project can be extended with further changes to the Find window, for example, allowing to filter search results to a subdirectory (currently it is only possible to filter by disk volume).

  • Skill set: C++, user interface
  • Possible mentors: PulkoMandy
  • Project size: 175 hours, 350 hours possible with extra goals
  • Difficulty: easy
  • Expected outcome: the new query window interface is implemented and working as documented in the linked tickets (or a refined version after discussion with the mentor and community).

Modular edit view (BIG)

The current solution for text editing in Haiku is the BTextView. It is a rather simple view providing basic text editing features and limited styling. This is, however, not powerful enough for most serious uses. The goal of this project is to design a complete replacement for BTextView, which should be designed to cover more use cases.

The edit view design should be modular and extensible to make it easy to implement e.g. following features:

  • Advanced text decorations and formatting: wavy underlines, strikethrough, exponents, ...
  • spell checker, line numbers, ruler
  • working on an input stream rather than on an input file, e.g. to be able to open files ~100Mb without loading them into memory in one go
  • Including pictures in the text flow
  • Automatic line breaks using locale specific rules (insertion of word breaks, handling of language with no whitespace between words)
  • Ability to load and save data in different formats such as RTF, ODT, ... (using the Translation Kit)

Existing work

The HaikuDepot application includes preliminary work on a rich text view, which it uses to provide the description of packages. This could be used as a starting point for this work.

  • Skill set: C++, API design, UI development
  • Possible mentors: waddlesplash, Sean Healy, scottmc
  • Project size: 350 hours (175 hours if working only on a much smaller subset)
  • Difficulty: hard
  • The edit view is more widely available for Haiku applications, and implement a selection of the items outlined in the list above (to be selected during the application period after discussion with the mentors and community)

Ports

Porting the Go Programming Language to Haiku

Go (or Golang) is a popular cross-platform general-purpose programming language which is known for its direct compilation to static executables, concurrency model used in its goroutines and its enforced standard style of programming. It has been used by many developers to create command-line tools, static site generators, high-performance servers and many other applications requiring Go.

Existing work
There was a previous GSoC student who originally ported Go 1.3 to Haiku, but unfortunately it was unmaintained and was broken over the years. In 2018, the port was later updated to Go 1.4.3 but only for 64 bit. Work has been attempted in bootstrapping higher versions like 1.5 and 1.11 but the bootstrap process have produced binaries that are broken and don't work. An attempt with Go 1.18 went further, and is able to cross compile executables from Linux. Now, this can be used to attempt to build Go itself so the tools (compiler and other related tools) run on Haiku themselves. Please note that this port may require diving into the low-level components of the compiler and Haiku internals.

Links:

  • Skill set: C, Go, Go assembly, low-level programming, ELF-internals
  • Possible mentors: return0e, BGA
  • Project size: 350 hours
  • Difficulty: medium
  • Expected outcome: an up to date version of Go running on Haiku and packaged in HaikuPorts

Other

Add Haiku support to Allegro 5.0

Allegro is a gaming library. Older version (4.4) did support Haiku, but this support was dropped from the newer versions (starting from 5.0). The library should be ported to Haiku, allowing to run the bundled examples and possibly port some other software using it.

  • Skill set: C++, userland development
  • Possible mentors: scottmc
  • Alternative projects: porting SFML or another similar library
  • Project size: 175 hours
  • Difficulty: easy
  • Expected outcome: Allegro 5 running on Haiku with all features

Multiple monitors output in app_server

app_server is Haiku's graphics server and the equivalent of X11 or Wayland on other UNIX systems. It currently supports only one video output, but should be able to do more.

While the API already allows this for the most part (with the BScreen class), there is no actual implementation behind it and parts of the code assume only a single screen.

Some drivers implement minimal support for multiple displays, but not all of them. This task may involve updating the video drivers to handle multiple monitors correctly.

  • Skill set: C++, graphics development
  • Possible mentors/knowledgeable people: PulkoMandy
  • Project size: 350 hours
  • Difficulty: medium/hard
  • Expected outcome: implementation of the needed changes in app_server APIs and accelerant APIs to properly support multiple displays. Reference implementation either in test_app_server or in one of the existing graphics drivers on real or emulated hardware.

Complex font rendering in app_server

app_server is the graphics server in Haiku. It handles the rendering and display of application windows, desktop, and everything that is shown on screen.

Freetype (in combination with agg) is used to render text. While it provides good results for latin and cyrillic alphabets, Freetype is not enough on its own to properly render other scripts with more complex rules, such as Devanagari or Arabic.

The goal of this task is to integrate Harfbuzz into app_server, so that the complex rules for text rendering are properly applied. This would allow rendering of complex languages as mentioned above, as well as mixing different languages (picking appropriate fonts automatically).

This task can be further extended with investigations of API changes required in the interface kit (and in particular BView and BFont) to properly handle right to left text.

  • Skill set: C++
  • Possible mentors: stippi, PulkoMandy
  • Project size: 175 hours
  • Difficulty: easy/medium
  • Expected outcome: working font rendering for arabic or devanagari or other script with "complex" rendering rules.

Menu