I always told everyone I wanted to stays a "hands-on" software engineer and not go into management, so it's ironic I wound up a software engineer working on management software. --Douglas Hubler

History

In 2001 I got my first introduction into management software for a telephony system. A colleague of mine, Damian Kremenski, and I developed a small meta language in an effort to help handle management duties. This meta language turned out to be instrumental despite it being quite basic. Damian and I spent the next decade developing plugin APIs to allow third party developers to add services to the telephony system with the modeling language as a key component.

Proud of the management system we had developed, we also understood the barriers of entry; proprietary meta language and death by plugins.

In 2014, I found myself in the job market. To my delight, there was no shortage opportunities as a software engineer with infrastructure integration skills. Job descriptions all described integrating a collection of internal and external applications using a disparate stack of management utilities. I happened to pick a job in the networking field for no particular reason other than it sounded interesting. In that time, I came to know two management standards; NETCONF and YANG. YANG is a modeling language and NETCONF is the protocol that leverages a management model. I quickly saw the usefulness of YANG having built a management meta language before. NETCONF, while powerful, wasn't nearly as exciting to me as it's new REST-based cousin; RESTCONF because it was REST. As a consumer of these standards I saw they addressed interoperations quite nicely. It was then that I saw the potential for an open source implementation of these standards for general purpose application development. It would be just what the industry needed to break free of the churn of proprietary management tools and the plugin-hell I helped create.

I spent from 2015 to present day implementing the YANG and RESTCONF standards. Aside from an initial two month stint, I always implemented the spec while supporting it in a production environment ensuring the library was relatively stable and easy to use. As a consequence, FreeCONF does not implement specification completely but it also does not violate the specifications in any known or significant ways.

While developing, I kept the following goals in mind:

1. Do not get in a developer's way
2. Make easy things easy, hard things possible