Real Time View

“Son, before you leave the table, don’t forget to put things away. Remember, open sauce bottles are not a good idea! They might spill and worse, turn bad!” I recall being chastised as a youngster after leaving the dinner table with tomato sauce bottles uncapped. Today, the thought of having to deal with open sauce bottles is but a dim memory. However, what has replaced any thoughts of wrongdoing just happens to be a sauce of a different flavor, that being the source. As in open source.

A simple transition to a complex topic. Wow, open source was controversial even from my time at Tandem Computers in the product management team. Temptations, indeed tensions, mounted over whether we would be compromising the very essence of what today we refer to as the NonStop essentials, even, as in truth, we often referred to these essentials as the special sauce that delivers the fault tolerance that is at the foundation of NonStop. These are essentials that continue to be the foundation even today.

Should we port open-source programs to NonStop? Might we consider incorporating selected open-source elements into key subsystems—communications software stacks are always a consideration. What of the BSD licenses? The Apache licenses? Additional licensing models have appeared, including the GNU General Public License (GPL), the GNU Lesser General Public License (LGPL), and the Mozilla Public License (MPL). So, what do we make of these propositions, and is anyone better than the other?

After I had written this, an exchange with Bill Honaker, Committee Chair of the ITUGLIB Technical Committee within Connect Worldwide and an authority on all things open source, highlighted several items regarding open source and NonStop. These can be best summarized – and for the OSS community, it is particularly relevant – CLIMs rely on the Debian Linux distribution, where you will find a number of open-source components, NonStop HTTP, NonStop Java, the API Gateway, and probably more if we dig deep enough. So, while we may be considering this topic and wanting to do a deep dive, once the surface is scratched, it may be a surprise to find how far we have moved down the open-source path, all the while noticing how big the Apache Software Foundation is playing a role.

Ultimately (and glossing over many endless debates), the Apache license model seems better aligned with the development needs of NonStop, and particularly when it came to porting new features. In this case, and returning to comms, Apache Tomcat was probably the first port from open source that turned into a supported deliverable that I believe is still attracting advocates to this day.

Perhaps the even bigger question began making the rounds within Tandem. Should we hand the very core of NonStop, the special sauce that has differentiated NonStop from competitors for many decades, to the open-source community? In so doing, could we achieve a broader, possibly more encouraging reception among developers, even as we would be able to leverage a pool of expertise that might accelerate the acceptance of NonStop, cementing its place in the world order of sustainable operating systems?

Taking it in another direction, what about burying the essentials within layers atop a true Linux supervisor? Perhaps, picking an acceptable Linux, Apache, MySQL, PHP, or Perl (LAMP) stack with which NonStop could leverage additional capabilities? Having moved on from Tandem Computers to ACI Worldwide via its acquisition of Insession, the then-CTO gave me the assignment to evaluate LAMP vendors in preparation for a broader porting of BASE24, and I surprised many when the winner of such evaluation turned out to be IBM. You can’t argue against IBM, particularly as stories were circulating that they would use DB2 at the back-end.

Little did I know at the time that there were deals in place within ACI to deliver BASE24 on IBM Mainframes. As news of that circulated, I found it was time to plan an exit. My time with ACI ended shortly thereafter as I moved on to GoldenGate. But open-source didn’t go away. What began to develop traction was the inclusion of many open-source routines, code-stumps, and macros within popular products and subsystems. As developers familiarized themselves with the licensing models, nearly everything new being embraced contained some open-source.

Intellectual Property (IP)? Well, for a time, that didn’t bother anyone until enterprise users started challenging vendors, asking them for full disclosure on the extent of usage of open-source, together with insight into the licensing model being used. However, this was a tsunami that was too great to stop or even legislate, and today, so much of what is delivered as software leverages open source. While this was all happening, the push for modernization (of enterprise solutions) came to the fore, with it, an almost overnight revolution in how code was developed.

Ignoring the move to a DevOps model, development tools burst onto the scene, empowering developers to build new applications almost from scratch. Everything became visual, aided by powerful version control and code collaboration products, and the emergence of the likes of GitHub began to dominate conversations. It was as if overnight, open-source became legitimate and all previous reticence to bring open-source to bear on real business problems disappeared. Whereby business had a need, there was a routine out there in the ether that would fill that need.

The script appears to have been flipped. Rather than asking if you are using open source, it’s becoming more of a case of why you aren’t using open source. It has become hard to ignore just how far open source has come in underpinning the modernization of IT. However, as good and revealing as it is, open source is not a panacea, and for many enterprises, finding that they were now becoming software product companies, needing to add all the soft infrastructure that regular software companies have put into place, is proving worrisome to these enterprises. There is value in letting an intermediary do the heavy lifting of ensuring delivered software products could be supported at the levels previously expected – yes, looking around the NonStop vendor community today, this is their own special sauce.

Tomato sauce, mustard, mayo – it matters little. All of them will go bad over time if you leave the caps off, facilitating open sauce. Fortunately, in matters far more critical, the caps have certainly come off and lids blown sky-high – open source is a part of the everyday life of modern developers. For that, the very fact that we can include NonStop and open-source in the same sentence is not only a testament to the resilience of NonStop.  Not to be confused with open sauce, there’s nothing bad here or left to spoil. It is a reminder, too, that after fifty years, the NonStop essentials can be leveraged in ways that truly can be described as being modern, and isn’t that something we all want to hear from the NonStop vendor community and indeed the NonStop development team at large?