Contributing to ISC's Open Source
  • 07 Sep 2020
  • 3 Minutes To Read
  • Contributors
  • Print
  • Share
  • Dark

Contributing to ISC's Open Source

  • Print
  • Share
  • Dark


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.

  • Clone our read-only git for BIND 9, ISC DHCP, or Kea.
  • 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).
  • 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 and let us know what you are trying to do and we will gladly upgrade your access.

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-workersdhcp-workers, or kea-dev mailing list for advice.  Many of the frequent posters on bind-users are also occasional code contributors.

Useful information about our process

  1. BIND runs on Linux, Windows, BSD, OSX, Solaris, HP/UX and AIX. ISC DHCP runs on all of those platforms except for Windows. 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 master 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.


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 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 master branch, in case it has already been fixed.