Last year I wrote about how I was able to make my open source work sustainable through corporate sponsorship. It has been a great run but over the past six months, sponsorship dropped by over 60% and I no longer see it as a viable path forward.
I plan to introduce a commercial license for all of my open source work moving forward, including hapi. This is not just an additional option but something that will likely impact everyone using my open source work moving forward in some way.
Successful open source projects typically go through three phases.
First, the project is created to fill a need. It doesn’t matter if it starts as open source or becomes one later, the need is tied to a funded effort (usually by a commercial entity). It is also fueled by innovation and excitement and often driven by other, non-monetary motives like the pursuit of fame and glory (or maybe just a little recognition).
Second, the project reaches a critical mass of adoption, moving it past the single use case it was created to solve. It has an active community and a growing audience. Because it is a project on the rise, companies are more inclined to contribute to it, either directly with financial support or indirectly by engaging their employees in the work. People and companies want to be associated with the next big thing.
Third, the work feels largely finished. While bug fixes, security issues, and minor features continue, most users consider the project done. They rely on it as a critical part of their stack or infrastructure but no longer keep a close eye. In many cases, the raw interfaces are wrapped in custom code in ways that make you almost forget you are using the underlying work. They also assume the quality of the work is still as good. Sustainability hits a crisis point.
Most of my published work is now solidly in the third phase. Major corporations rely on my code to power economically significant applications. However, with the exception of 5 companies, everyone else is a freeloader.
Sponsorship is an impractical source to sustain a project in the third phase. I talk to developers eager to support my work on a weekly basis. They understand the pain and want to help until they hit the wall of corporate justification. The truth is, there is no justification for a company to give charity to open source maintainers in the third phase.
As long as the project is not dead, as long as there is someone to deal with critical security issues, it’s good enough. This is especially true for infrastructure components which reside low enough in the stack to no longer require daily engagement. It is also the reality of a well test, proven, and mature software. Sometimes, things do feel complete and done.
But as long as other pieces keep changes, in my case node, the operating system, and of course the language itself, there is going to be constant need to verify, optimize, and update.
Most projects in this situation resort to a few proven solutions. They offer paid added-value services like support contracts, custom work, training, or add-on components. This is best done while the project is in the second phase. It is very hard to do in the first when no one cares or premature monetization can kill momentum, and even more challenging in the third. By the time you reach maturity, expectations are set and attention moves elsewhere.
Looking for a way to sustain my work, I started focusing on the commercial license path. I don’t want to do paid training, write books, or record tutorial videos. But offering a commercial license has to add value, and in my case, those using my software require very little support even when it’s free.
After looking at the download statistics of my open source work in general and hapi in particular, I found the clue. 80% of current hapi users are on an older major version than master. From conversations with leading companies I learned that while they plan to upgrade at some point, there are logistical and economical reasons not to upgrade. Their current version provides enough value and an upgrade competes with adding business value.
hapi continues to evolve but for a large portion of its current user base, the real need is keeping older versions maintained. It is also an area where existing resources lack. If you keep up with the latest version of the framework, you know you have the best, most secure code running. But if you are stuck on an older version, chances are you are carrying some baggage.
I don’t currently deprecate unsupported versions. I simply stop supporting them a few months after the latest major release goes out (or when the node version they require goes out of LTS). There is usually a tweet and a GitHub issue announcing the change in support but other than that, you must rely on your own systems to identify issues with older versions (such as an npm install security scanner).
Starting next year, I plan to change how old version branches are licensed and maintained. Everything published on the current, open source licensed modules will remain unchanged. If you have a hapi dependency in your project using the latest version, it will continue to be updated and continue to be licensed under the same open source terms. Zero change.
However, as soon as a new major version is released (up to 4 times a year), the older versions will be locked and left unchanged. When a bug or security issue is identified in an old version, only then will the open source module be actively deprecated and no new version will be published. The only exception will be for catastrophic security issues to ensure the well being of the ecosystem (there have not been any such issues over the past couple of years, but plenty of bugs and minor security issues).
At the same time, under a different module name, a commercially-licensed version will be published. If a company cannot upgrade but still requires the fix, it will simply purchase a license and change the package dependency from the open source module name to the commercially licensed module name. No other changes needed.
Companies that actively ensures the quality of their stack will simply purchase a license proactively and switch to use the enterprise version for a risk-mitigated, worry-free deployment.
Unlike the more common commercial license scheme where the free version lags behind the paid one (e.g. community releases vs commercial releases), this scheme keeps the best version available free under an open source license. If you keep up with the latest version, you do not require a license (unless you want the additional benefits it will provide).
However, very few companies can quickly migrate every time there is a new major release of a core component. Engineering resources are limited and in most cases, are better directed at building great products than upgrading supporting infrastructure. The backwards license provides this exact assurance. You can stay on any version you would like knowing that you are still running supported, well-maintained, and secure code.
In practice, the “breaking change” here is just the active notification for those running older versions that they are running deprecated or insecure code. If you choose not to pay for a commercial license, you will be getting the exact same quality of service, but will be notified when it is no longer safe to do so.
And that, is something I expect companies to find real value in. Value that will justify allocating financial resources to, and is in line with every other software expenditure they make.
Unlike the sponsorship model where a few cover the cost of keeping the ecosystem healthy, in this model, the cost is paid by those who benefit from the piece of mind of using well-maintained software without the constant need to keep up.
I still have some details to work out. For now, this is just starting a conversation. My goal is to switch over to this new model on January 1st, 2019. Until then, no changes will be made. Once the new terms are published, there will be a transition period to ensure a smooth migration with plenty of flexibility.
The new commercial license will include additional benefits focused on providing enterprise customers the assurances needed to rely on these critical components for many years to come. It will also include new components and tools.
If you have a free minute, please fill out the hapi commercial license survey.
If your company relies on my open source work and you have any questions or concerns, please don’t hesitate to contact me at firstname.lastname@example.org.