Funding Kea

Kea 1.2.0 was released a couple of days ago. You may have noticed that there are two new premium features available. We have received some questions.

Is Kea becoming commercial?

No. Kea is and will remain open source. Rumors that Kea is becoming a commercial product are simply not true. Our first commercial add-on - the Kea Forensic Logging library - has been available since 1.1. We simply started adding more commercial add-ons to it.

Kea has been in development since 2011. While we did enjoy one sponsorship grant and several custom development contracts and have recently signed a few support contracts, the vast majority of Kea development was internally funded by ISC. That means that for every single year since Kea’s inception, it was generating a loss for ISC. Sadly, ISC is not a wealthy company and this kind of funding is unsustainable in the long term. Therefore, we started looking at ways to improve the financial standing of Kea. One key point here is that the goal here is to break even, not make a profit from Kea. ISC is a non-profit entity and we can’t turn anything into a significant source of profit.

Why do you need money for an open source project anyway?

We like to think that the products we deliver are commercial-quality. Kea is a project that is run by a small team of skilled engineers (two engineers working full-time with two others contributing occasionally). We also have one person doing independent validation (he develops tests, runs them, and takes care of our server farm) and there’s some management and planning involved (we need to decide what are the goals of each milestone, which tickets go in, whether we’re on track or lagging behind, etc.).

There are other costs involved as well. We run an extensive build and test farm with around 20 machines, a mix of metal and VMs. Those systems do builds, run unit-tests, system tests, performance measurements, static code analysis, perform memory leak validation, sanity check the build release process, and many other things. They need maintenance, consume power, and need lab space.

Kea engineers are active in the community and attend conferences. This also costs money. We are involved in the IETF standardization process (see this list of published RFCs; some of them are authored by Kea engineers); therefore, you can meet us at IETF meetings. We also sometimes show up at other meetings, like RIPE or regional operator meetings (e.g. PLNOG or UKNOF), where we can meet users, get requirements, and talk about Kea.

What features will be premium features?

The question was raised as to what sort of functionalities are going to end up as premium features. This is always determined on a case-by-case basis, but the major determining factor is whether the feature is used by small deployments (will go into open source) or by big deployments (may possibly go into premium). Let me give you a specific example. Our recent addition, the Host Commands library, adds extra commands to manipulate (retrieve, add, and delete) host reservations. You can already do that in the open source in several ways: you can insert the record into the database, or you can update your configuration file and tell Kea to reload it. The reconfiguration usually takes fractions of a second, but may take longer if your configuration is extensive. Smaller deployments will most likely find that acceptable. However, if you happen to have many thousands of users and you constantly add or remove devices to your network, you will find host commands useful.

What about contributions?

The code available as premium is 100% developed at ISC. It does and will not include any contributed code. If we accept a patch, it is offered to ISC under a license (typically it’s MPL2, the same as Kea, but on one occasion we received code under Apache license). Whatever the license is, ISC received the code under that license and we can’t and won’t republish it under a different license.

What about donations?

We occasionally receive donations and we are very grateful for them. Unfortunately, they are not a realistic way of supporting Kea for two reasons. First, they’re completely unpredictable (as opposed to our electricity bills coming in regularly and our engineers’ families needing to eat and pay their bills). Second, they could perhaps cover part of the electricity bill, but that’s about it.

Isn’t there any other way?

There is, at least in theory. We could have all of the code as open source and ask people who run networks using Kea to share some of their profits by buying a Kea support contract. We tried that for almost 2 years and it wasn’t very successful. So we are trying to make the offering more attractive by adding more benefits to the support package. Once the Kea project gets into a better financial situation, we will gradually push more features into open source and fewer into premium.

What can I do to help?

The answer is different depending on your situation. Some engineers using Kea like it and they decide to donate some amount of personal money. That’s certainly a very nice gesture and we’re very grateful, but that is unlikely to help Kea survive financially. If you happen to work for an company that runs Kea and you have many customers, consider signing a support contract for Kea. Perhaps you’re an engineer who can’t make such decisions. In such case you can help by convincing your boss that getting a support contract is the right thing to do; you will get more out of the software and you will help develop Kea further. You may want to take a look at the Kea page of our website for more details. Also, feel free to contact us to get more information. You can also consider a custom development contract. See the next question for details.

If you’re a small company or perhaps you run a university campus without any significant funding, there are other things you could do. First, if your deployment is small, in the range of low thousands of devices, you are unlikely to absolutely require any premium features. If you deployed Kea and it works well for you, you can help make it more popular by coming forward and sharing your successful deployment story.

But I want to make sure that feature X goes into open source. Is there anything I can do?

Certainly. In the past we have completed several custom development contracts. We were approached by a company that wanted a feature; after a brief discussion we came up with a contract that contained written technical requirements and a note that the software developed would be published under an open source license. That’s how Kea got IPv6 prefix delegation support, for example.

Hopefully these answers have cleared up any concerns. If you have any further questions, please feel free to post a message on kea-users or feel free to chat with any ISC person if you happen to find us at a conference.

Tomek Mrugalski