My recent vacation seems to have inspired Tim to write a few blog posts. I love that he did, but I think he missed an important point in his post about why we chose not to release the SCORM Engine under an open source license.

While Tim may be the kind of guy to replace the toaster when it breaks, I’m a bit more inclined to do a bit of tinkering before giving up on it entirely. While I certainly don’t agree with the entirety of Richard Stallman’s philosophy, I do agree that a user has the right to tinker. This is something we’ve embraced since the very beginning of our company; nearly all of our licenses include access to the source code of the purchased product. We do not offer a no cost license nor do we offer a license that requires unencumbered distribution. We do most definitely however provide licenses with open source code.

We don’t provide this access out of the goodness of our heart or because we think there is a moral imperative for software to be free. We do it because it makes good business sense.

Here’s why:

1) We’re a small company, when we sold our first SCORM Driver license (then known as RSECA), we were two guys working out of a spare bedroom. We’re a bit more established these days, but on the grand scale of things, we’re still a small software company. Small vendors make big clients nervous. Let’s face facts, the odds are against the long term survival of any small company. Nobody wants to be stuck with a product from a defunct company. This is especially true for our products since so much of the value we provide comes from our continued enhancement of the products to track the continued evolution of the standards. Providing our source code in one way to greatly mitigate the concerns that big companies have in doing business with small companies. Even if we disappear, our clients will always be left with something they can continue to work with.

2) Our products are generally very tightly integrated into our clients’ products. To achieve this level of integration, some coding is almost always required. While we’ve isolated all of this work to our integration options, it is often quite nice to be able to reference the core source code directly to see how things work and explore what methods are available.

3) We sometimes get “free” help from our clients. Our clients are typically software developers themselves, many of whom love to track problems down all the way to their source. On the very, very, very rare occasion that there is a bug in our software, our clients can sometimes point us right to the problem and right to the fix they have already implemented in their system. We welcome anything that makes our lives easier, so thanks!

4) The biggest challenge we face when deploying the SCORM Engine is the fact that every LMS is slightly different. While there are many commonalities, each system has its own set of features and quirks that make it unique. For the SCORM Engine to be tightly integrated, it must be able to reshape itself to be consistent with each of these quirks. Over the years, we’ve seen enough of these that in most cases our integration options are flexible enough to handle whatever requests are thrown at it. Occasionally however a client has a need that requires a customization. Providing them with the source code allows us to be able to make the required customization just for them while we build the flexibility to make that customization through the integration option into our core product. Being so tightly integrated, clients occasionally want to modify the SCORM Engine to be implemented consistently with the rest of their code base. We generally discourage any customization since it hinders our ability to provide clients with future updates, but by providing the source code, we are able to let clients make the best decision for their particular needs.

5) Our products are at the very core of our clients’ products and they are vital to the operation of the products they serve. We provide very important and very visible functionality to our clients. It is important enough that it is worthy of examination. We recognize that the decision to outsource vital functionality can be a hard one (but also the right one!). We want to do everything in our power to make our clients feel comfortable with the quality and implementation of our products.

Mike is the Founder and was President of Rustici Software until 2016. Most recently he was the CEO of Watershed Systems. He helped guide the first draft of the Tin Can API (xAPI) and believes ice cream is the "elixir of life."