Contributing to OpenSLP

OpenSLP is an ongoing effort to create a standards-compliant, enterprise-quality, open-source implementation of the IETF Service Location Protocol. This project is a continuation of an SLP implementation started by Matthew Peterson at Caldera Systems, Inc. (since renamed The SCO Group) in late 1999.

The current maintainers represent a diverse group of companies and individuals. If you'd like to be a part of this project, we encourage you to follow the long-established open-source community pattern of joining our mailing lists and voicing your opinions.

Reporting a Bug

If you just want to report a bug or suggest an enhancement then we encourage you to use our SourceForge project trackers:

The OpenSLP developers use these trackers internally to assign bugs, review enhancement requests, and determine future release road maps.

Joining Our Mailing Lists

The OpenSLP project provides the following mailing lists:

  • openslp-announce (archive) - general announcements (low traffic).
  • openslp-users (archive) - for developers using OpenSLP to write SLP enabled applications or for OpenSLP installation, configuration, and maintenance issues.
  • openslp-devel (archive) - for discussion of development issues interesting to those working on the OpenSLP implementation.

We recommend you check the list archives before asking questions. The OpenSLP project has been around for a long time and many common questions have already been answered. Use the parenthesized "archive" links above to access the list archives directly, or use the OpenSLP archive search page to search the archives.

NOTE: Please be aware that our mailing lists do not accept posts from non-members. Open source mailing lists are targeted by spammers all the time. If we leave the list open, no one will join because doing so would be like opening a firehose of junk mail. If you post a message without joining, the message will end up in the moderator queue where we may or may not get around to pushing it to the list within a week or two. If you want a timely response, please join the list before posting.

SourceForge uses GNU list server software so you may configure your account to receive as much or as little of our list traffic as you desire. If you want to keep the traffic to a minimum, try the digest form, wherein you get one consolidated message per day.

Getting the Latest Development Code

The very latest code is available from the OpenSLP Mercurial DVCS repository for read-only access. Patches made to the source code should be made to reasonably late branch revisions (preferrably at the tip) so they can easily be merged into the code base by an OpenSLP team member.

To check out the source code from the OpenSLP Mercurial repository, install a Mercurial client for your operating system and issue the following command from a command shell prompt:

$ hg clone http://hg.code.sf.net/p/openslp/mercurial openslp-mercurial

This command will create a directory within the current directory called openslp-mercurial containing a local copy of the entire openslp repository.

For Microsoft Windows users, a GUI tool like TortoiseHG, or another tool of your choice, may be used to accomplish the same task. Follow the instructions for the tool, using the above URL in the proper location, to check out OpenSLP source code with a Windows-based graphical tool.

Building the Code

Instructions for building the OpenSLP source code from a downloadable archive are included with the archive. Building the OpenSLP source code from a repository is just a bit different. To build on a Linux system from a repository work area, you must first boot-strap the autotools. First, ensure you have reasonable up to date versions of Autoconf, Automake and Libtool installed. Then simply run the following command from the openslp-mercurial/openslp directory:

$ autoreconf -i

This command will put your work area into a state similar to the code you will find in a downloadable archive, building a configure script for you so you can then run configure and make to build the project.

Submitting Patches

If you find a bug in the OpenSLP source code you may certainly fix it in your copy. We encourage you to go the extra mile and submit a patch to the OpenSLP project.

Using the Mercurial instructions above, check out a copy the OpenSLP repository and update to the branch you're working on. Make your changes to your repository and then capture a 'diff' of the changes to a patch file from the root of the repository in this manner:

$ hg diff > bug-fix.patch

Now, simply email bug-fix.patch to the openslp-devel mailing list along with a short explanation of the nature of the bug and how you fixed it.

Please consider the following before you submit a patch:

  • Is it really a defect or is it simply an implementation-specific interpretation of an ambiguity in the SLP specification? If you're not sure, check with the openslp-devel mailing list. These folks have been working on OpenSLP for years. If there's an ambiguity, they probably already know about it.
  • Does the bug exist in the Subversion repository or only in the most recent release? Perhaps we've fixed it already.
  • Is your fix generic in nature, or specific to your use of OpenSLP? In the long run, a generic fix will make everyone happier - including yourself.

Requesting Commit Rights

OpenSLP is an open source, community-driven project. This means that you and others like you are the primary contributors to the code base. Members of the OpenSLP development team voiced their interest in service advertising, Service Location Protocol, and OpenSLP on the OpenSLP mailing lists. When it was apparent to the existing community members that they were going to contribute significantly to the project, and that their contributions were of good quality, they simply asked for commit rights to the project.

Having multiple developers with commit rights has advantages and disadvantages in open source projects like OpenSLP. In general, the advantages are that efforts to enhance the project are parallellized to a greater degree: Changes need not funnel through a single developer with write access. The disadvantages are manifest through design disagreements which happen as a matter of course on more free-form projects. Since OpenSLP is based on an IETF Standards Track specification, most design decisions have already been fought over and set in concrete by the IETF SrvLoc working group.

Our point is this: If you think you'll be contributing heavily to OpenSLP, submit a few patches to the developer mailing list and then ask for commit rights. The team will vote (on the mailing list), based on their assessments of your patch submissions, but if you write decent code chances are good you'll be granted write access.

Other Ways to Help

There are many ways to help with open source projects, including writing documentation, maintaining the project web site, answering forum and mailing list questions. If you're not a coder, but you have a solid understanding of the Service Location Protocol specification, please feel free to jump in and help in any of these areas. If you have ideas about other ways you can help, don't be bashful. Speak up on the mailing lists and we'll consider your request.