Contributing to ISC's Open Source
  • 02 May 2024
  • 4 Minutes to read
  • Contributors
  • Dark
  • PDF

Contributing to ISC's Open Source

  • Dark
  • PDF

Article summary


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. But we welcome external contributions to consider for inclusion. Here's how to get started:

  • To contribute to BIND, Kea, or Stork, you will need an account on 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. 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 and select a bug or feature request to work on, or create an issue for the problem you want to work on.
New GitLab accounts must have activity

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. 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 are suggesting. You can then 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 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.

We will review your contribution and ask you for changes if appropriate. If your suggestions are accepted, we will commit your merge request 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-userskea-users, or stork-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 the Linux and BSD operating systems, so please consider this as you write your contribution. 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 Kea, 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, or Stork itself, and code intended for the BIND 9 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 relinquish exclusive copyright, and that you grant permission to publish your work under the standard license agreement for the project you are submitting it to. (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.