Contributing to ISC's Open Source
  • 18 Jan 2023
  • 4 Minutes to read
  • Contributors
  • Dark
    Light
  • PDF

Contributing to ISC's Open Source

  • Dark
    Light
  • PDF

Article Summary

Welcome!

ISC publishes free open source software. You can participate by sending bug reports, writing or fixing documentation, and submitting patches or even new features. Answering questions on the public mailing lists is another great way to contribute to the community.

How to Become a Code Contributor

We use the Managed Open Source development model: only our staff are authorized committers to the source tree. This has the advantage of maintaining the performance and quality of the code base, and the disadvantage of making it a bit harder for external developers to contribute directly to the source code.

  • Join our GitLab. Before you can create a merge request, you must get elevated permissions to create your own branch. Ask us for this on the relevant -dev mailing list, or email us at info@isc.org and let us know what you are trying to do and we will gladly upgrade your access.
New GitLab accounts must have activity

Please note, that to mitigate bot spam and other disruptive uses of our GitLab instance, we have configured GitLab to suspend new accounts after 1 day (24 hours) of no activity, and to delete accounts with no activity after a week (7 days). This policy is only in place for new accounts without activity; once an account has shown initial activity, it should no longer be automatically suspended or deleted due to this policy. In order to prevent your new GitLab account from being automatically purged, you must perform some activity on your account within 24 hours. Activities include setting up two-factor authentication, commenting on an issue, or being given a project allocation.

  • Create an issue to describe the changes you wish to make (but you want to fix). You can (next step) create your merge request directly from this issue, which will create a branch for you linked to the issue. In most cases, someone from the core team will review and comment on the issue within a week, or you can post on the appropriate -users list to ask for input.
  • Write your changes (this part is up to you, but please see the BIND Developer Guidelines, BIND Contributor Guidelines and BIND Coding style pages, or the Kea Developer's Guide for details).

We will review your contribution, ask you for changes (if appropriate), and commit it to the primary repository.

Get advice before going too far!

If you are attempting something complicated, or are investing a lot of your time and effort, you might want to consult some of the experts on the appropriate bind-usersdhcp-users, or kea-users mailing list for advice. Many of the frequent posters on bind-users are also occasional code contributors.

Useful information about our process

  1. Our software runs on many variants of LINUX and BSD operating systems. Please consider this. If your patch requires us to test and make changes for every other OS platform, we may not be able to accept it.
  2. The more information you can provide us about your patch, the better. If your patch fixes a defect, please give us a complete description of the bug, how to reproduce it, the version you found it in, whether you have verified it in other versions, etc. If your patch enables new functionality, please explain what you want to achieve, and if it isn't obvious, why.
  3. We prefer patches made to the current main branch, if possible. If you are submitting a patch for a defect only verified in a very old or unsupported version of BIND 9 or ISC DHCP, we probably won't accept it. We have to focus our efforts on supported code, and minimize changes of uncertain value.
  4. If you submit a new feature, we will have to hold onto it until the next major release goes out. We have a policy against putting significant new features into maintenance releases, for the obvious reason that they are de-stabilizing.
  5. We acknowledge new features that result from contributed patches in the release notes. We try to acknowledge contributed bug fixes, but if they are very small and don't merit a CHANGES note we may not.

Licensing

We accept two different types of code contribution: code intended for inclusion in BIND 9, Kea DHCP, or ISC DHCP itself, and code intended for the contrib directory.

  1. ISC does not require an explicit copyright assignment for patch contributions. However, by submitting a patch to ISC, you implicitly certify that you are the author of the code, that you intend to reliquish exclusive copyright, and that you grant permission to publish your work under whichever is the standard license agreement for the project you are submitting it for. (All current versions of ISC software are issued under the Mozilla Public License 2.0 (MPL2).)
  2. External contributions must be licensed under a BSD-style license in order to be included in the contrib directory in our software distribution.

Submitting Patches - Fixes and Features

To contribute to BIND, Kea, ISC DHCP or Stork, you will need an account on gitlab.isc.org. You may need to request a project allocation in order to fork the main project to create your own workspace; we are happy to give external contributors a workspace. You can look at the open issues in and select a bug or feature request to work on, or create an issue for the problem you want to work on. When you have a submission ready, then create a merge request. Please read the contributor guidelines and coding standards for the project you are working on. We will normally require a unit test and documentation for any feature change. If you are addressing a bug, please first verify that the bug exists in the main branch, in case it has already been fixed.