Summer of Code projects for GNU
This page has the project suggestions for GNU's participation
in Google Summer of Code 2008. Project proposals for 2006 and 2007
are archived separately.
The ideas here are listed in alphabetical order by project. Many
projects have more than one suggestion.
AutoOpts has the ability to produce a variety of program
documentation, including man pages, html, .texi, and .txt.
Right now, AutoOpts puts "plain text" into its output formats. We'd
like to have a framework where we can at least begin to support some
sort of "tags" where we can put information into different fonts (like
using ntpd when documenting the ntpd command, perhaps "declaring"
that we are using a mandoc style and using .Nm whenever we want to see
ntpd). We'd also like the ability to document configuration
keywords, and perhaps some support for simple tables.
If the "source" for the documentation is used to produce a man page,
the output would be a decent-looking man page. If this same source is
used to produce .texi page, the resulting .info page should also look
good (and perhaps contain appropriate cross-indexes).
Requirements: C, possibly Guile. More info and
links. (As you might guess from the above, the first user for this
feature would be the excellent NTP free
bashdb, debuggers, and Emacs
In the last couple of years, a large number of Integrated Development
Environments (IDE:s) has emerged. So far, none has come close to the
editing capabilities of Emacs, but on the debugger side, Emacs has
As many people still use Emacs as their preferred editor, an ideal
situation would be that Emacs also would be used as a debugger
front-end with windows for, say, the call stack, local variables, and
Some work in this area has been done, most notably gdb-ui.el, which
provides a multi-window debugging environment for C and C++ and
gdb. In addition, the
project is doing similar work for Ruby.
This project would:
- define guidelines for the look and feel for multi-window debugger
- refactor and unify the existing code base (gdb-ui and rdebug), to
make it easier to implement support for other debuggers.
- Analyze the underlying Emacs layers , and maybe restructure
parts. Especially, the gud.el layer is a candidate for this.
- Implement support for other languages and/or debuggers, for example
Bash and Python.
For more information, contact
GNU Classpath is a GNU project to create a Free clean room
implementation of the core class libraries for use with virtual
machines and compilers for the java programming language. In addition
to the ideas presented here, you may also find some more on
- Support the Java
This is needed to run JConsole locally (which would be the end goal of
this project). Having it as part of our VM interface has general
usefulness as VMs will need this for OpenJDK too.
BrandWeg is our attempt to integrate parts of OpenJDK into Classpath
to provide some of the missing functionality to VMs using the
Classpath interface. This is actually capable of spawning a number of
sub-projects depending on student interest:
- Using OpenJDK's java.util.Scanner
- Using OpenJDK's Swing HTML implementation
- Using OpenJDK's native ZIP implementation
- Using JAXWS from OpenJDK
- Support JBoss
JBoss should run well on GNU Classpath. There are a number of open
bugs for this:
- Support TomCat
Likewise, TomCat should run.
- Support Batik
Classpath should be able to run Batik.
as the native layer
We could simplify the portability glue code by using glib underneath.
We're using glib implicitly in the GTK peers already, and it would let
us delegate the responsibility for portability wrappers out of
classpath, while at the same time making the native code work
transparently on win32.
- Rewrite Qt peers using Jambi
Our Qt peers are rotting away, and that means it's time for someone to
come in and rewrite them. Qt Jambi are the official bindings for Qt
for Java code, so it could be both fun and useful to rewrite our Qt
based AWT peers in pure Java.
- Update GJDoc to support the 1.5 language constructs
Within the GNU Classpath Free Java stack, there remains one
component that can not yet fully handle the 1.5 language constructs
such as generics, enumerations and annotations. A development process
of approximately two years ensured that the main code base and VMs
supported these extensions, but our documentation generator has so far
simply being patched so that it can at least generate documentation
for the current codebase. The documentation for our latest
release illustrates some of the problems, notably in classes like
java.lang.Enum. GJDoc really needs a new parser to handle the 1.5
constructs and then appropriate adaptation to render them correctly in
the HTML doclet.
- Add file output support for the sound API
Last year's Google Summer
of Code saw a successful proposal to add support for reading and
playing sound files using a GStreamer implementation of javax.sound.
Support for writing sound files is still missing however.
- Implement java.util.Scanner
A skeleton implementation is available from Tom Tromey. This has
been a long-suffering hole in GNU Classpath.
- Complete the CLISP multithreading interface;
see design spec and partial
implementation. Essentially, one would have to have a good
knowledge of Lisp, C, and threading and to: abstract some memory
management code to be reusable by thread creation functions;
implement the lisp interface to thread creation and management;
audit clisp code base for thread safety.
- Convert CLISP build infrastructure to Automake.
- Finish the implementation of libJIT support for ARM or x86-64
For this project, you should be familiar with
compiler implementation techniques and the particulars of the target CPU's
instruction set. The
libJIT manual describes the steps needed to for porting libJIT to new
architectures. We can provide access to ARM and x86-64 machines, and indeed
machines with other CPUs too.
- Finish libJIT ELF writer (Complexity: medium)
libjit rationale for instruction and rationale for the DotGNU
JIT Library (libJIT). The libJIT library contains routines that
permit pre-compiling JIT'ed functions to an on-disk
representation. This representation can be loaded at some future
time, to avoid the overhead of compiling the functions at
runtime. We use the ELF format for this purpose, which is a common
binary format used by modern operating systems and compilers.
GNU/Linux uses ELF. However, it isn't necessary for your operating
system to be based on ELF natively. We use our own routines to read
and write ELF binaries. We chose ELF because it has all of the
features that we require, and reusing an existing format was better
than inventing a completely new one.
- Port libJIT to a new architecture (Complexity:
You could port libJIT to a new architecture, for
example OpenRISC, SPARC, MIPSEL and so on. For this project, you
should be familiar with compiler implementation techniques and the
particulars of the target CPU's instruction set. The libJIT
manual describes the steps needed to for porting libJIT to new
- Porting Application (Complexity: medium)
There are a
number of Free applications using .NET which currently do not run
under DotGNU. Pick any non-trivial Free application and propose a
Summer-of-Code project to make it work under DotGNU. The CodeProject contains many
software projects that are interesting, but they are likely small.
Ports should aim to create a helper class library to assist in the
porting. Basically, every time a P/Invoke is found in one of these
applications or a dependency exists on a third-party control or
library, some stubs or primitive implementation should be exposed in
this "helper" library. This includes Windows.Forms, XML, and
- Enhance Windows.Forms (Complexity: medium)
Portable .NET Windows.Froms library implements much of .NET 1.1, but
many are still missing. None of the .NET 2.0 specific Windows.Forms
is implemented yet. This project would significantly enhance the
completeness of implementation of at .NET 1.1 or .NET 2.0.
- Replacing CIL with native code. (Complexity: very
contains a code generator that can be used for Just-in-Time compilation at
runtime. Code can also be compiled ahead of time to produce native
JIT compilation is more commonly used, but for some systems where
memory is restricted or where startup time is important,
pre-compiling the code can be a significant win. The goal is to
modify the runtime and compilation so that the bytecodes can be
safely removed from a program and a single image is shipped
containing both metadata and native code.
- Implement any C# 2.0, 3.0 feature. (Complexity: very
The Portable .NET C# compiler is based on the treecc
Last year the GNOWSYS project participated in the GSoC project
successfully and the project is moving closer to a stable release from
a developer only version.
Last year's project contributed a framework
for and an implementation of a version control system. This
eventually led to its implementation in
where GNOWSYS is used as a distributed knowledge base.
For 2008 we suggest the following projects, and we're looking forward
to mentoring students who would like to work on them.
- Automated harvesting of free knowledge sources like TLDP, man
pages (nroff/troff), texinfo, DocBook, ODF, wikisource, LaTeX, SCORM,
IMSLD and other such structured document formats into the GNOWSYS
knowledge base. (Good knowledge of XML and text parsing are prior requirements here.)
- Exporting the harvested knowledge (as well as the directly authored
knowledge base) into other document formats (OWL, XTM, SCORM, LaTeX,
DocBook), provided that these formats are free/open document
(As with the previous suggestion, good knowledge of XML and text parsing are prior requirements here.)
- GNU Emacs client integration. This might make use of
Org-Mode, for example.
(requires prior knowledge of working with Emacs and XMLRPC.)
- Collaborative authoring and organization of knowledge. Also
graphical representation of the GNOWSYS knowledge base, using
frameworks like pyGTK or Sugar (you should have some experience of these).
More details about GNOWSYS can be obtained from
GNUnet is GNU's P2P system. It is designed as a framework and does not
use any centralized or otherwise trusted services. A first service
implemented on top of the networking layer allows anonymous
censorship-resistant file-sharing. All link-to-link messages in the
network are confidential and authenticated. The framework provides a
transport abstraction layer and can currently encapsulate the
peer-to-peer traffic in UDP, TCP, HTTP or SMTP messages.
GNU libextractor is a library used to extract meta-data from files of
arbitrary type. The goal is to provide developers of file-sharing
networks or WWW-indexing bots with a universal library to obtain
simple keywords to match against queries.
The team would like to receive students' own ideas on how to improve
both projects (including of course the subprojects gnunet-gtk and
gnunet-qt). Talk to us! You can find us on the IRC channel #gnunet
and on the gnunet-developers
Grub is a part of the GNU system and is participating in the Summer of
Code program as part of the GNU project. However, the Summer of Code
project ideas for GRUB
are listed on a separate page.
IceCat (part of Gnuzilla) is a completely free version of Firefox,
with a few additional features. More information on the Gnuzilla web page. Talk to us on the bug-gnuzilla
Add UDF support in libcdio, which has been asked for a number of
times. Blu Ray for example uses a UDF filesystem. You can find us on
phpGroupWare is a fully featured, web based messaging, collaboration and
enterprise management platform. It comes with over 50 applications that can
be mixed and matched according to your needs.
All improvements will include accompanying unit tests
- Implement a database to track metadata of fetched files;
- Improved international support:
- Support for IDNs (Internationalized Domain Names): RFC 3490
- Support for IRIs (Internationalized URIs): RFC 3987
- Locale-aware handling of filenames and command-line URL
- Convert current scan-from-huge-buffer model to a streaming
- HTTP/1.1 support in Wget (needs Transfer-Encoding support,
- Various opportunities for code restructuring.
- Regex (instead of wildcard) accept/reject lists; generic Content-Type
- Pick and choose from the list of bugs
and feature requests in our bug tracker!
Each of the ideas for GNU Smalltalk projects includes a guideline as
to how hard the project is likely to be. These guidelines assume you
are already familiar with Smalltalk, though not necessarily GNU
Smalltalk. You can find help and advice in the places listed in the
- GnuTLS bindings, including adding to Swazoo support for serving
HTTPS. Other common libraries, such as GD, GSL or Expat would be
interesting. In a project application you probably want to propose a
coherent set of libraries to work on, with an example of an application
that would tie them together. (Easy)
- Work on the GUI. You could write a Gtk or Blox back-end for
OmniBrowser, or add the ability to develop in the GUI and sync the files
on the file system. (easy if you have previous experience in Gtk or
- Develop a system to port changesets
from other Smalltalks. The idea is to have a merge-like command that
takes two foreign source code files (e.g. from SqueakSource) and merges
the code into a GNU Smalltalk source file. (medium)
- Or, you could implement a "remote browser", i.e. something that
could browse an already running system. In other words, the
view/controller and the model would reside on two different instances of
the VM. This requires implementing or porting some kind of distributed
messaging system. The same could be done for debugging; you cou
investigate possibly if the protocols that are used by Java debuggers
are suitable to Smalltalk. (medium)
- Work on command-line tools. You could port parts of the Refactoring
Browser and make a command-line version of Smalllint for example. (hard)
- Create a build tool that allows one to coordinate builds with
Smalltalk scripts, like Rake or SCons (see also this
for an example of what I mean). (medium)
- Build a continuous integration server using Seaside, with code
reports. This could have many directions: building an interface to
version control systems (svn, CVS, git) that can be used from Smalltalk,
analyze what problems would limit the uptime of a web application
written using GNU Smalltalk and Seaside (memory leaks, etc.),...
(easy if you have previous experience in Seaside)
Submitting ideas to this page
- If you are an eligible student and have an idea that is not listed
here, you should propose it
normally through the Google
Summer of Code web site. Please discuss it with the package
- If you are a GNU package developer, have an idea for a Summer of
Code project for your own package, and can mentor it yourself, please
email the idea at email@example.com and one
of the administrators will add it. (Simple HTML fragment in plain text
preferred.) Please also recruit a backup mentor and tell us who that
will be. Make sure that the description of your idea contains enough
information (perhaps in the form of pointers to other information or
mailing lists) for students to research the feasibility of them
implementing your idea. More
- In all other cases (e.g., you are a developer with an idea for
another package), please contact the maintainer for the package. If you
can find a mentor for the project (or, hopefully, can mentor it
yourself), then we will add it if it is feasible. The project must meet
the Summer of Code criteria; see the