OpenDNP3 was released as open source over 10 years ago. This post describes where I believe the project has succeeded, where it hasn’t, and why Step Function I/O is using a different licensing model for our new libraries going forward.

In many ways, OpenDNP3 has been a success. We are constantly learning of new companies that have successfully used the library to add DNP3 functionality to their product or service offering. Some metrics for the project reflect this success:

• Mailing list with over 400 members, and almost twice as many threads

• 50 watchers and 198 stars on Github

• 41 tagged releases

• 22 different contributors

That’s pretty good for a niche industry-specific library! That said, there are some areas where the project hasn’t fully succeeded in my eyes.

Low Third-Party Contribution

Wait, I thought you said there were 22 different contributors? While technically true, third-party contribution has been a tiny portion of the overall work done to extend and maintain the library.

The first non-staff author is sidhoda contributing 29 commits consisting of some small features and a couple bug fixes. Approximately 98% of all contributions were made by paid staff.

This is frequently the reality of Open Source Software (OSS), where a small team of maintainers do the vast majority of the work. Sometimes they can justify this free engineering because being the subject matter expert (SME) brings them associated consulting work. This has been the case with OpenDNP3, and the contribution statistics alone don’t tell the full story.

Sponsorship and Consulting Opportunities

As expected, the majority of users (companies) consume the library and don’t need to sponsor feature additions or pay for support. This is a good thing in that it reflects that the library and its documentation are fairly self-contained. Some users hired Automatak and those engagements fell into several categories:

• Sponsored feature additions

• Support, debugging, or DNP3 subject matter expertise

• Platform/plugin development

Some corporate users found that they needed additional features in the library as their products grew. I’d estimate that Automatak performed ~75K USD worth of feature additions under contract to various customers over the years. While it’s nice to be paid to work on open source, 75K over 10 years isn’t very significant.

An even smaller amount of consulting revenue was derived from pure support, e.g. helping customers by training them on the library or DNP3 in general. This was the smallest and least profitable aspect of our consulting practice around DNP3. The vast majority of the support provided was done for free via the project mailing list.

The largest amount of consulting revenue was derived by engaging with customers on larger projects. This frequently involved integrating the library into larger service offerings. We’ve integrated OpenDNP3 into platforms, gateways, and microservices for customers with diverse applications such as demand response, customer voltage reduction, and unidirectional gateways (diodes). These engagements frequently involved broader software engineering expertise and grew beyond the scope of acting as a DNP3 expert. These types of engagements have been the primary source of DNP3 related consulting income.

Commercially speaking, all of the work that has been put into OpenDNP3 can be viewed as a loss leader which has enabled the paying work. Because OpenDNP3 has helped me build an independent consulting practice, I view the project as a commercial success. That said, I do not believe it is a model that you can build a larger company on in the power industry.

Cumbersome Technology

Back in the mid-2000s when the earliest internal version of OpenDNP3 was written, C++ was a reasonable choice to write a platform independent library that needed to run efficiently on embedded Linux. Over time, .NET and Java bindings were added to integrate with more products and platforms.

In 2020, however, C++ is looking very old, complex, and error prone. Writing asynchronous C++ has always been extremely error prone. Our new technology stack based on Rust allows us to crank out code in a fraction of the time and with much more confidence that it is correct. Our new methodology for modeling APIs and generating language bindings reduces maintenance and bugs simultaneously. After having tasted the freedom this offers, I am just not interested in continuing to add features to OpenDNP3 and then manually expose them in multiple language bindings.

Our new technology offers security and correctness guarantees that just can’t be achieved with C++. We can bring efficient and secure libraries to more languages and platforms.

New Licensing Model

Beginning with our Modbus and DNP3 libraries written in Rust, we are introducing a new licensing model which I believe blends some of the most compelling aspects of traditional commercial licenses and open source.

Our new libraries may be found on GitHub, under a non-commercial license which allows applications such as R&D, evaluation, and training. It explicitly prohibits the use of the software in production systems. Users wishing to deploy the software in production must purchase a commercial license. Even though the software is “open” in the sense that anyone can see the source code, it is not “open source” per the strict definition put forth by the open source initiative.

This revenue model will properly reward us for bringing a high quality product to our customers, but still retains some nice things in common with open source:

• Companies considering using the software don’t need to apply for a trial or take our word on anything. They can evaluate the software freely.

• Academics, national labs, and other non-production/non-commercial users can use the software as is without paying for a license.

• Security researchers have full access to the source code. We can use this access to build confidence in our libraries and development methodologies.

• We can develop our libraries transparently using lots of free infrastructure.

• Customers can obtain source and builds of our software as if it were open source making integration painless.

Going Forward

OpenDNP3 will remain a viable open source library, but our attention will now be shifting to our commercial libraries. In the near future, we will stop offering commercial support of OpenDNP3 to new customers. We will no longer perform feature additions to the library on our own time or under contract. We will, however, fix any bugs or issues that turn up, and we will continue to provide paid support to customers who have purchased it for the library in the past.

We expect that OpenDNP3 will still see lots of usage as the library is pretty mature, but explicitly stating on the project homepage that commercial support is no longer available will likely deter some potential users. That said, it’s open source, so in theory any interested party could support it in this manner.