History -
Diff -
Top of this page -
Last modified Mon Feb 28 10:39:47 PST 2022
Plan 9 and related technologies cover a huge range of topics. Below we've put together a list of some ideas which we think would be good candidates for contributors looking for GSoC-sized projects with us. Each idea includes at least a good description of the project; most also include one or more "sponsors" for the idea (people who've suggested it or volunteered to work with folks on it). Ideas are rated for estimated difficulty from 1 to 5 stars (1=easy, 5=hard) and may contain links to further information or discussion. New this year, GSoC supports two different sizes of project (~175 hours and ~350 hours), so we've split the list into "medium" and "large" lists. Several items could productively be expanded or trimmed down to move from one category to another; we've included some suggestions there. Each idea also includes a difficulty estimate, where ✪ = easy, ✪✪ = medium, and ✪✪✪ = hard.
If you're looking for additional ideas, you might check out Inferno's issues list, or Acme-SAC's issues list. These lists are much more general and not everything on them will all be a good size for a summer, but they are good sources of inspiration. There's also our prior editions of this page: gsoc-2021-ideas, gsoc-2013-ideas, gsoc-2012-ideas, and gsoc-2011-ideas.
If you're a community member and you have an idea you'd be willing to act as mentor for, please add it to this page! Just follow the format given and provide a good summary of the project. If you'd like, create and link a wiki page with as much detail as you'd like (but please don't swamp this page). Please only add ideas you're willing to mentor (or have directly spoken to whoever you're marking down as mentor).
These are expected to fill aboout ~175 hours of a contributor's time.
The Plan 9 windowing system is quite different from what's typical n other envronments. Rendering is handled by the kernel graphics driver itself, with a user-mode application responsible for window management issues like placement, sizing, labels, and visibility. Today, the only such program in the main distribution is rio(1), which is excellent but was designed with certain assumptions in mind (namely, a "traditional" workstation with a three-button mouse and a keyboard), and it doesn't hold up as well in other environments (most notably, touchscreens). It would be useful to have a few alternatives better talored to other environments. Design and implement an alternative interface. Some popular ideas include tiling interfaces (similar to acme(1) or X11's wmii or dwm), exploring keyboard-driven control, or touch-based interaction.
A good outcome here would be a usable system which can handle existing Plan 9 graphical applications. Getting to that point should be a relatively easy project, but could be made a bit more complex depending on the input models supported (e.g. adding gesture support).
A student looking to work on a project in this area should be familiar with Plan 9's existing windowing system, including rio(1) and draw(3), at a minimum. It would be good to also review some of the rio hacks found in the contrib index. Other potentially useful starting points are Anthony's nile and Sigrid's riow
Write a 9P file server that can be instructed to create a file tree and associate each node with external directories, files or processes. A good starting point would be to use the proto(2) format (hence the name) as used by mkfs(8) and others, although there are some obvious useful extensions for this application. Very roughly, the prototype file tree instructions might look something like:
/ fst/ = /usr/fst/www/ edit/ snarf > /dev/snarf paste < /dev/snarf mouse | fd0rw /dev/mouse
Your application should describe the set of extensions you think would be useful, and ideally your plan for adding those in after first establishing a working base model.
This should be a relatively easy project, although it could be a bit more complex depending on the specific extensions you support.
The wikifs(4) in both Plan 9 and Inferno understand a very small set of cues when generating HTML. That set can be limiting. Replace it with something better, like Markdown. Markdown engines in C already exist and a few have already been ported to Plan 9, for example Discount (version 2.1.8, among others); doing the Inferno version would most likely involve a new Markdown interpreter in Limbo. Ths project should also provde a method to convert existing wiki docs.
This project could be expanded to a larger size with some combination of doing both the Plan 9 and Inferno versions (rather than picking one), and possibly exploring different output types (Anthony has a draft of a version that generates gemtext, for example). In any case, it should still be farly easy, in terms of complexity.
The sending, and receiving, requirements of email have changed since upas smtp(8) became a part of Plan 9. As more restrictive filters are in place adding support for DKIM to outgoing messages would offer one option in providing more robust email services for Plan 9 users. This should be a relatvely easy project.
The LXR project has created some very useful tools for cross-referencing different source trees. This idea has been productively expanded by FXR to compare across operating systems (FXR includes various BSDs, Linuxes, and an old Plan 9 tree). As Plan 9 evolves, it would be very useful to tree maintainers to have an easy way to find, track, and explore differences between trees. This project would be to provide tools to scan different source trees (at least the final Bell Labs tree, 9legacy, 9atom, and 9front; possibly Inferno, Plan 9 from User Space, and others) and allow users to see specific changes, perhaps including changes over time.
Your proposal should describe the interface you're thinking about providing (file server? web application?), what you think some of the important issues are, and clearly define the scope of work (for example, will you be doing multi-way diffs, or just 1-to-1 comparisons?). Multiple Plan 9 sites would be happy to host the results of this work.
We estmate ths project at medum difficulty for a more conventional FXR-like web-based interface, and a bit harder if you want to define a flesystem-based interface. Your proposal should include a rough outline of your ideas for that part if you intend to include it.
Note that porting the existing FXR or LXR are almost certainly not good starting points.
These are more like the "traditional" GSoC projects, and are expected to fill about ~350 hours of a contributor's time.
fossil(4) implements console commands by a console service served through a pipe in /srv, often accessed manually using con(1). When the commands are scripted, expect(1) must be used to try to pattern-match any text written in response by the server. Venti(8) provides an unauthenticated HTTP service that gives access to a range of statistics. The venti protocol itself implements one or two control requests, notably "sync". The aim is to replace the command and status interfaces in each program by a 9P service. (In fossil's case it would be a different tree from the file storage trees.) That tree can then be mounted and accessed using ordinary commands such as cat and echo, but with proper error reporting (as part of 9P). If there's enough time and interest, we could do the same for cwfs(4). The Plan 9 Ports implementations should also be updated. As a small side-project, when fossil talks to a venti running on the same machine, connect them using a pipe instead of TCP/IP(!).
We estimate this project as easy difficulty. There are a fair number of capabilities to provide, but internally all this functionality already exists.
It would be nice for Plan 9 to be able to speak mDNS/Bonjour. When in heterogeneous networks, there are various devices that utilize mDNS/Bonjour for discovery that Plan 9 currently misses. Get the protocol working and integrate it with Plan 9's existing ndb(8) infrastructure.
We estimate this as medium difficulty. Most of the complexity comes from the mDNS side of things, rather than Plan 9's ndb/cs infrastructure, so contributors who've worked with that in other environments might find it a little easier.
syzkaller is a fuzzer written by Dmitry Vyukov. It's been used to fuzz lots of things, including Akaros, an operating system which includes a large amount of Plan 9 code. It would be good to bring it to Plan 9 proper. We estimate this as difficult, but someone with strong pre-existing syzkaller experience might find it a bit easier than that.
Edwood is a reimplementation of acme in Go. It is currently fully functional but has a number of shortcomings. Most of these are probably decent large-sized but easy-to-medium difficulty projects on their own, but some might be productively combined:
Syntax coloring
Support for colored glyphs is probably a decent mid-sized project on its own; support for external coloring servers might be large on its own.
Rich textAcme's always had just a single font in each frame; adding support for variable fonts in a single frame would be a good large project. Supporting external layout servers could be another interesting large project.
GPU-based rendering (large)
Remote display [split like Sam]sam(1) has long had a "-r" which lets you run the display portion of the proogram on a different host than the actual edting, which is useful in lots of envronments. Acme's never had this, which is a shame. Add it.
It could also use a port back to Plan 9. Win needs a decent Go implementation.
Often, the things you're most motivated to do are the ideas you come up with yourself.
Feel free to apply with your own suggestions!
