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 Lastest Development Code
The very latest code is available from the OpenSLP Subversion repository for read-only access. Patches made to the source code should be made to reasonably late trunk or branch revisions (preferrably HEAD) so they can easily be merged into the code base by an OpenSLP team member.
$ svn co https://openslp.svn.sourceforge.net/svnroot/openslp openslp
While the above command will work, it's probably not what you want because it will check out the entire openslp repository, including all branches and tags. To check out just the trunk line, for example, use:
$ svn co https://openslp.svn.sourceforge.net/svnroot/openslp/trunk openslp-trunk
This command will create a directory within the current directory called openslp-trunk containing just the trunk line code.
For Microsoft Windows users, a GUI tool like TortoiseSVN 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.
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 Subversion instructions above, check out a copy of the HEAD revision of the branch you're working on. Make another copy of the code to use as a baseline for your patch. For this discussion we'll call one of these copies modified and the other pristine. Make your changes to modified and then 'diff' modified against pristine and redirect the output to a patch file in this manner:
$ diff -urN modified pristine > 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.