If you're interested in contributing to the DNX project, this is the page for you. We're encouraging people with interest, talent and desire to contribute ideas, code and documentation to DNX.

Read over this short introduction to DNX development, and then take a look at the links in the sidebar on the right.

Mailing Lists

Some people approach an open source project with very specific goals in mind. Often these goals are imposed by the company they work for, or another project they are already working on. If they have a problem that can be solved by enhancing DNX in some way, they'll come up with a well-considered design, and then make a suggestion for the enhancement.

Others just want to help out with whatever needs to be done. Regardless of your persuasion on this issue, the approach is the same: You have to communicate your desires or intentions to other interested parties. With open source software, such communication is done primarily though mailing lists. The DNX project provides and supports four different mailing lists. (NOTE: These list references are not mailto links due to the unbelievable amount of spam we've received! Please reformat with appropriate email address syntax.)

The dnx-announce mailing list is read-only, and a good way to keep up on the progress of the project. If you subscribe to dnx-announce, then you'll get at most 1 message per month indicating major changes or releases of the project. Announcements are made about project releases, and about significant changes to this web site.

The dnx-commit list is also read-only. There is a bit more traffic on this list - perhaps 2 to 3 messages per month. Some open source projects might have more traffic on this list, as its intent is to announce each change committed to the Subversion repository, but the DNX project administrators have chosen to publish updates to the project ChangeLog on this list.

The dnx-devel and dnx-users lists have significantly more traffic, and are more or less discussion forums for developers and users regarding issues surrounding the project. If your interest is toward helping out with DNX project development, you should check out the dnx-devel archives for past issues, resolutions and overall project culture. If you're only trying to use DNX and have questions about the proper use and configuration of DNX, then you should subscribe to the dnx-users list.

Note that you may only post to the dnx-devel or dnx-users mailng lists if you are a subscriber. Strictly speaking, you may post to either of these two lists as a non-subscriber, but the list moderator will have to approve the post before it will appear on the list itself. As a subscriber, your post will show up immediately - or at least as fast as the network and list server can process the request.


In the OSS world, there are generally multiple ways to access the source code for a given project. One of the most common methods is to simply access the latest released tar balls. Often, however, there are several months between project releases. If you happen to download the latest tar ball days before a new release, you're probably accessing code that is too old. Patches made from these sources may not apply properly to the latest development branches due to significant differences between the source code in the tar ball and the source code currently under active development.

Even if your patch is targeted toward updating a specific release you may find that the code has branched and patches are being actively developed for that release, and thus the code has diverged too far from the last version of that release.

The solution to these problems is quite simple - access the same source code that the developers are using: The DNX Subversion repository on SourceForge.NET. One of the fundamental tenents of open source is world-wide simulataneous access to the most current source code. It's difficult to collaborate with people around the world on open source software without this feature. In fact, you can even browse the repository with your web browser.

To begin with, obtain and install a subversion client of your choice. If you're running a Linux system, and you've configured it as a development machine, then chances are you've already installed a Subversion client as part of the base installation. To find out, try this command:

$ svn --version svn, version 1.5.0 (dev build) compiled Nov 19 2007, 10:15:13 Copyright (C) 2000-2007 CollabNet. ...

If you're running Windows, then you may either obtain a binary distribution of Subversion for Windows, or use one of the popular GUI-based Subversion clients, such as TortioseSVN, the Eclipse Subversion plugin, or SmartSVN.

If you're new to Subversion, please download the subversion manual and read it. If you're planning to do any real open source development, you can't really get by without understanding at least the basics of version control with Subversion.

DNX Subversion Access

To access the DNX Subversion repository on SourceForge.NET, use the following Subversion URL's:

While this URL will get you everything, you probably don't need the web site content, or other branches or tags. To access just the latest trunk line dnx development code try this subversion URL:

From within your dnx development work area (say, ~/dev/dnx), use the following command to checkout the dnx source code.

$ svn co .

Building DNX from an SVN Work Area

Since DNX is a Nagios plugin, it can only be built and executed on Nagios target platforms. Nagios target platforms include Unix, Linux, FreeBSD and other Unix-like systems. Nagios does not support Windows, but Windows may be used for developing documentation, or other non-software related tasks.

Unless you're already familiar with GNU Autotools, you'll probably be scratching your head before long, wondering where the configure script is located in your DNX working copy that you've checked out from Subversion. To build the DNX source code from within a Subversion working copy directory, you'll need to have Autotools installed on your system. As with subversion, if you installed your Linux machine as a development machine, you probably already have Autotools installed. Simply execute the script found at the root of the DNX project working copy directory. This script will generate a configure script from Autotools configuration files. From there you can do the usual dance:

$ ./ $ ./configure; make

This command may also be run in a different directory; that is, you may use a relative path to the configure script to generate a build tree in the current directory. Assuming your current directory is the parent of the dnx project directory:

$ ls -l total 1 drwxr-xr-x 13 dev1 users 944 2007-12-15 13:36 dnx $ $ dnx/ $ mkdir dnx-release && cd dnx-release $ ../dnx/configure; make

You may use the sequence of commands following the 'ls' command and its output above to build dnx in a separate build directory. The nice thing about building in a separate build directory is that (except for a few autoconf droppings) the source directory remains fairly clean, which makes it easier to diff your modified source directory against a pristine work area.

In order to ensure that your changes don't break any of the existing DNX code, you can run the built-in unit tests making the 'check' target:

$ make check

Submitting Patches

Eventually, you'll want to submit a patch to the DNX project. To do this, you'll need two work areas; one that's been modified by you, and an original copy of the same work area or tar ball. Create a patch file using the GNU diff utility in this manner:

$ diff -Naur old-dir new-dir > mychanges.patch

Then send us your patch file. If you end up creating a lot of patches for DNX - and we like them - then we'll probably upgrade your rights to the DNX Subversion repository so you can check in your changes directly, rather than send us patches. If we develop a trust relationship with you, then granting you 'commit' rights to the DNX SVN repository will save us both time and effort.


Most people love quality documentation. Sadly, this sentiment sometimes conflicts with the culture of open source software. However, one of the nicer aspects of open source software is that if something isn't to your liking, and you have a little extra time, you can do something about it!

If you have the time and would like to contribute quality documentation to the DNX project, please do so. We'll gladly incorporate your efforts into the project so that others may take advantage of your experience.

Submit your documentation enhancements in any popular word processor format. We can accept Microsoft Word format, Open Office format, or even WordPerfect format. If you prefer to write in plain text, we can accept that as well; however, it would be nice if your plain text docs contained HTML markup so that we could post it on the web site. ;-)

DNX Web Site

Perhaps your passion is web site design. The DNX web site is stored in the same SVN repository as our source code. Following the above instructions for using Subversion, check out the web site content with the following command:

$ svn co .

This web site is currently formatted on a half dozen html pages, based on a single css-style sheet with about a dozen small graphics. It's very easy to update. If you'd like to offer enhancements to the existing site content, please feel free to do so. You may submit patches the same way as for source code. If we like them (we aren't too picky), we'll add them to the repository and update the site. We could end up granting you commit rights for web site management also.

If your ideas for our web site are more expansive, and you have visions of php-enhanced wiki pages, or more dynamic content, please email us and let us know what you'd like to see and how you'd like to contribute. We'll be glad to listen, offer suggestions, and ultimately discuss with you how we can consume your contributions.

DNX Mailing Lists

DNX Trackers

DNX Subversion

SVN Clients

GNU Autotools