Available Theses in the FOSS area

This is a preliminary list of subjects that you can pursue. It should be a subset of the theses offered at the SE group. If you feel that you have a project idea that would fit into this research, feel free to contact Christopher Oezbek.

Pattern Documentation in Free / Open Source Projects

Design Patterns are a well established development tool that facilitates good style, improved readability and maintainability, makes communication about source code-easier and can structure a project in a natural way. The goal of this project is aimed to inspect the existence of pattern use and documentation in Free / Open Source Projects, come up with a guideline for the free / open source community of how to improve their software with patterns and perform an empirical validation of the work.

How to get involved with a Free / Open Source Project

Both the adjectives free and open suggest that Free / Open Source projects are based on freely accessible or open communities that everybody is allowed to join or leave at will. This project aims to investigate how easy it really is to get involved and get patches and code changes into the code.

Taking a shot at standardizing Linux

As part of a recent discussion on Slashdot on the problems of Unix this project is taken: Since years people have been complaining about the lack of standardization of Linux configuration files and input/output behaviour of commands but nobody has done anything major. Our idea now is to modify three standard Linux command-line utilities (suggested: ls, ping, grep, passwd) to use standard xml configuration files and input/output in addition to the existing solution. XML has a lot of advantages that could help prevent version conflicts from occurring (for instance using XLST to translate the output of a tool into the old format).

This is a very implementation oriented project but also includes the social part of getting these changes into the existing codebase.

Usability Enhancements for the Linux Command Line

The command line interface (CLI) is the main input mechanism for controlling and using Unix style operating systems. While at the same time power-users fell attracted by its strengths like flexibility, speed and power of expression, those strengths turn into impediments once beginning users are concerned. Windowing environment like KDE and Gnome have tried to hide CLI complexity behind configuration tools and distributions like SuSE and Redhat's success is based on graphical installation tools like YaST and Red Carpet which make it possible to sidestep the command line interface.

This thesis aims to implement an user interface enhancement for the command line by adding an graphical interaction panel to the KDE and/or Gnome console application that displays information and offers help about the usage of currently entered commands. A large amount of work has already been achieved by doing evaluation and designing a prototype which is described in the following document (Skinning the Command-Line (PDF)). The thesis therefore mainly focuses on implementing the given idea, evaluating the found solution and advertising the solution to improve the learnability and usability of the CLI.

End user Software Engineering

Since computers have become widespread tools for end-users, programming-language designers have been dreaming about the day that those end-users might be able to write their own programs for themselves. Similar to home improvement and do it yourself non-computer scientists are seen as tinkering with their existing programs and building new tools and customizing their PC.

This project is meant to look inside the open source community and identify areas where this has been possible by collecting the most popular little programs people have been writing. These should be bash-scripts, little perl-hacks and patches to favorite applications.

Performing a OS wide separation of concern (a common file-dialog library)

The problem is most familiar to any adept Linux user: Since the file-dialog-box is something that is implemented in the windowing-toolkit (GTK, QT, etc), it is impossible to have platform-wide consistency between applications in their file-dialog behavior. If you are an avid fan of XMMS you know how much you suffer from there usage of GTK 1 file-dialogs, which cannot compare to state of the art KDE or GNOME file-dialogs.

This project attempts to cross cut the whole Linux-platform to separate the concern of file-dialogs into a central location. The implications would be that you could use any Linux program, be retained a platform-wide standard dialog which could be switched to match the user's preference. Of course doing something like this requires quite some hacking of the libraries involved and somebody interested in this project should bring along a solid set of Linux knowledge.

Techniques for performing library-wide cross-cuts are not readily available so we would set foot upon unchartered territory with this project.

Assessing the risk and benefits of forking

With the freedom of the GPL comes the natural risk of forking. With this project we want to have a look at the risks and benefits of performing such an operation. To do this, we will inspect past attempts of forking and how they turned out. We will try to gather sources from mailing lists about the root-causes of the fork, who moved to the new project, who stayed behind and how the projects defended themselves in public and created new identities for themselves.

Promoting the role of the "Coach"

After having come up with the "Mediator" with the ThesisFOSSIM-Project we are interested whether there are other roles that might be benefitial for a FOSS-enterprise. An example idea would be role of the coach who takes care of new developers and newbies to perform directed coaching, hiring and task assignment during the beginning stages of a members contact to a project.

For instance the coach could be lurking on the IRC and try to hire people who have asked questions to write up the result of their inquiry for the homepage.

Here an example from the OpenCms mailing-list:

I'd like to start contributing to the codebase. What's the best way to go about doing so? I'd like to not only contribute new code, but help clean up existing code. I find as I go through the code looking at how things are going, that there are some design issues in the code.

So: how is new code contributed, and how is refactoring contributed?

Thanks.

This developer would be an ideal candidate for coaching.

Comments

Please leave your comments below (CS login required) or send email to Christopher Oezbek.