Backstory
Around 12 plus years ago I was in a predicament.
I had deployed a Java based Enterprise Service Bus (ESB) across our data centers so we could integrate content from our corporate partners into our sites. We had also purchased MarkLogic, an XML database with an XQuery front end, so we could serve contextual content into our sites.
The ESB architecture, if not product we purchased, was difficult to develop for. MarkLogic was great. XQuery, not so much. Regardless, I was tasked with integrating and cross promoting more contextually relevant content throughout our public portal.
I don’t remember the traffic numbers, but my unit was doing $100M a year in revenue, so it wasn’t a trivial amount. So after a self directed crash course in R, I was better positioned to do proper capacity planning for each new service deployment, either on our bus, or directly into our site. Scalability and robustness, by virtue of revenue and traffic, was a concern.
The predicament was simply this, writing and deploying new services that managed content on our ESB backbone or to our websites was too difficult. Making matters worse, we were in the midst of a shift from Perl based infrastructure to Java, creating a small skills vacuum.
Progress
About this time I came across Netkernel. I eventually “got” what they were up to and within a few months we had Netkernel deployed as a container for our content management services. Services our developers could easily build and deploy.
Netkernel had a some nice qualities.
One was that I could restart a new version of a service jar. That is, we could write version 1.1 of a 1.0 service, push the jar, and very easily reload the new version. If I remember correctly, the older version would still complete requests. We could also roll-back releases. (Yes, OSGI, but it wasn’t on my radar at the time, likely because enterprises weren’t adopting it yet.)
This change dramatically simplified of our deployment pipeline. Prior, there was usually a full restart of a new stack, more likely a parallel start of a new stack with the newer service. This required a lot more hand-eye-coordination than we could muster for frequent releases.
Also around this time Rhino began supporting ECMAScript release 4, specifically ECMAScript for XML (E4X). It’s worth noting release 4 was ultimately abandoned by the industry, JSON showed up in release 5.
Rhino was a Javascript engine written in Java, so it could be trivially embedded into Netkernel.
What E4X provided was a simple native Javascript syntax for creating XML data structures, not a bolted on library that serialized and deserialized POJOs as XML, with all the attendant ceremony the Java syntax expects.
Our developers could now quickly write a MarkLogic XQuery request, get a XML response, and transform it for inclusion on a web page (or message reply). And with a simple Ant build script, a new service or new version could be published in minutes, after its unit tests pass.
Netkernel also had some sophisticated internal request caching, so I do not remember if it was required to place a Squid proxy in front, but we likely did this anyway as it was pretty standard.
Dilemma
If I’m remembering all this correctly, Netkernel was dual licensed. At the time, I think we could have used the core of the engine for free, maybe not, but we needed the additional management and debugging features that were surely not free (as in beer). Now looking at the current licensing FAQ, I see there is a requirement limiting the execution of closed source applications.
I do, embarrassingly, remember my initial attitudes and thoughts. The gist was that I felt Netkernel was a niche tool, the company probably didn’t have much of a future, so why pay them if it was just going to be freely available anyway after they tried a new business model on the precipice of failure of the current one.
At this point after a few years at this company, I had spent many hundreds of thousands of dollars in licensing for enterprise, closed source software. But all of those projects had senior executive sponsorship. And as business folk, they made a clear case for the expense — even though it was me and my team making the recommendations.
Here I had no executive sponsorship, it was simply me pulling Netkernel into the company to solve a set of issues that I couldn’t paste charts of Gartner quadrants into Powerpoint to justify. I was fully accountable.
So maybe I didn’t want to pay so I didn’t have to make a business case for both the software expense and developer time from other projects. Or I didn’t want to call attention to the work, so someone wouldn’t be telling me I was wrong to solve it this way. Or that streamlining our development cycle, improving developer productivity, wasn’t a worthy enough effort to justify the expense.
Maybe, the dual license simply frustrated me, maybe it all felt ambiguous. I mean, you always paid for closed source, but this was “open”, so was the dissonance putting me off?
For whatever reason, I was having an internal dialog and debate that just never happened with the other proprietary software evaluation and procurement processes.
We did license Netkernel, it was the right thing to do. We had the money, the licensing fee was more than reasonable, and the product brought my team a lot of value.
Netkernel is a strong player in (what I believe to be) a niche market. The founders and employees, last I heard, are all doing great. They even hired a new CEO. I’ve no idea if they have taken funding, but I strongly suspect not, simply because they are still in business, for 10 plus years in a niche market. I also do know, from experience, it wasn’t likely an easy 10 years.
An Understanding
Is there a moral here? Yes.
More niche tools, products, and markets mean there will be a larger diversity of solutions.
As engineering leaders in need of these solutions, it is important for us to support business models that give other developers the incentive to invest in and create tools and products we may one day need. As developers ourselves, we are those future entrepreneurs with ideas we may want to pursue.
This diversity of ideas will prop up a stronger software economy on a foundation of healthy niche markets. Stronger from the fact that these markets aren’t precariously funded by venture capital and speculation, but by the users who find success in the tools they use, users who are willing to share in that success.
Or simply put, sharing in ones success with those who helped create it serves to only improve outcomes for everyone.