Open Sound System
Developer Community

Making contributions to Open Sound System

First of all this guide doesn't cover simple changes such as bug fixes. Just send them (diff -c or diff -u) to the oss-devel mailing list or to We will check the changes and apply them to the source tree if possible.

We are opening a source code repository (Mercurial) for OSS 4.1. This document was written for the period before Mercurial.

Quick steps

Here is a short summary about the procedure for submitting contributions to the Open Sound System project. However you should read the entire guide before submitting anything.

  1. Join the oss-devel mailing list.

  2. It is recommended that you propose the changes you have planned to do. There may be somebody else already working on the same feature or driver. In particular changes to the OSS API itself (soundcard.h) should be approved in advance.

  3. Follow the rules for OSS programming (below).

  4. Sign the contributor agreement and send it to 4Front Technologies.

  5. Post your diffs (diff -c or diff -u) to the oss-devel mailing list. If this is a new driver then you can also post the whole driver directory as a tarball (do not include any other files of the OSS source tree). After the Mercurial site is up it will also be possible to make changes directly to the repository.

If the change is acceptable it will appear in the development sources within few weeks.

More details

Programming style and practices

The programming style used in OSS is “legacy Unix”. It is different from Windows. It's also somehow different from Linux (not much). However there are just few strict rules.

The above rules are are mandatory. You have to follow them if you like to contribute anything to OSS. Here are few more rules you should follow if possible.

What you must never ever do

Initial comment

Each source file should have an initial comment in the beginning. This comment gives a subject for the file (visible in the source code index on the web site) and some other information about the source/module. Optionally it can contain a list of the authors who have developed or modified the file. Also a short change log is permitted (however change logs should preferably be kept in the .changelog files).

For example:

 * Purpose: Driver for ACME123 turbo sound booster chipset
 * This driver supports both the original ACME123 chip and the updated EMCA321 one.
 * Authors: Me        Original version, 2002-2003
 *          Myself    Support for EMCA321, 2005
 *          I         Modified for OSS 4.0, 2007

Copyright tag

OSS source files included in the official (golden) source tree are not permitted to have any copyright statements or license restrictions mentioned in the comments or embedded in variables or display statements. When you sign the contributor agreement you give 4Front Technologies to redistribute your contribution under multiple different licenses. The corresponding license statement will be etched to the source files when the export tarball for that license is cut (as you have seen we have separate tarballs for GPL, CDDL and BSD licenses).

Each source file should have a copyright tag line after the initial comment. This line marks the location where the final copyright statement will be inserted. For example:

#define COPYING © Me, Myself and I, 2002-2007. Licensed to 4Front Technologies.

The above line is sitable for the C source files (.c). Header files (.h) cannot define the COPYING macro again because that may cause warnings about conflicting defines. Instead driver's private header files should use the COPYING2 to COPYING8 tags.

Other reading

Take a look at the internal documentation of OSS. It explains how to write new drivers for OSS.