I’ve spent the last couple weeks researching, and parts of the last several months pondering, whether it would make sense for us to open up our licensing. Obviously this is a fundamentally important decision for a small company like ours. When I get into fundamentally important decisions, two of the things I really like to do are…

  • Go to the people I respect on the web and look for relevant thoughts, we’ll call these folks “the anchors”. People like Seth Godin and Joel Spolsky often write things that resonate for me, and so I go and “ask” them virtually what their thoughts on the subject are.
  • Put the thought through “the public eye”, or at least pretend to do so. Mike and I often ponder how a decision we would make would play out publicly. This isn’t to say we’re unwilling to make unpopular decisions. To the contrary, we’re happy to do so. But we have to feel comfortable enough with our rationale that we’re willing to share that rationale publicly. It is, in some ways, comparable to the “do no evil” edict Google issued upon themselves long ago.

[Pausing for a moment to caution the reader… this is a complicated issue for us… I’m sharing a lot here, so this post will undoubtedly be longwinded. I apologize now and offer you the right to bail at any time.]

Full Disclosures

  • This is a for profit business. We are in the business of making money.
  • We have no doubt that the SCORM Engine is the best SCORM delivery mechanism in the world, and we believe that broader usage of the SCORM Engine will increase the utility of online learning as a whole. We want as many people and software applications as possible to use the SCORM Engine.
  • By accomplishing the second point, we hope to benefit. See point 1.

Why we wouldn’t do it

We are here to make money, and I’m not convinced that we can make more money by giving away our software to a portion of the community.

The anchor: Jason Fried, 37signals. One of many articles he’s written on the subject of making money relates here. In my words, he’s admitting what I did in the “Full Disclosure” above… we’re in this to make money, and the way you do that is to “charge your customers” for the right to use your product.

The open source zealots have failed to convince me that software should be unencumbered.

I’ve read a lot of open source propaganda over the last few weeks. Richard Stallman, for example, espouses the virtues of what I prefer to call “unencumbered” software (he calls it free, as in libre). I get that to a degree, but it isn’t compelling to me. I’ve grown up around software that was closed source, admittedly. He makes an argument along these lines, “If your toaster breaks, you are able to make an effort to fix it… You know how it works and can address problems.” Well, here’s my thing… if my toaster breaks, I’m the guy who goes out and buys a new one. I don’t care all that much if the innards, the core parts, are inaccessible. Sure, I like certain things to be transparent and direct, but I don’t insist on having diagrams of the inner workings.

Why we would do it

Greater penetration

An open source version of our product would eliminate the cost barrier and allow more, potentially _many more_ applications to make use of the SCORM Engine.

Open source is customer friendly… and we are too.

Incentives for an open source provider are well aligned with customers’ needs. (Red Hat regularly espouses this virtue.) If an open source provider fails to provide useful, valuable services, then that customer will cease to pay for those services. In the traditional model (term licenses), the software provider can require that payment.

Questions we’ve been asking ourselves

Q: Would making the SCORM Engine open source (say, GPL), increase adoption significantly?
A: Likely. Moodle, Sakai, Dokeos, and any other GPL LMS would likely (or at least should) integrate it at that point.

Q: Would open source adoption increase revenue substantially?
A: Doubtful. If the SCORM Engine were part of Moodle, for example, would any Moodle user come to us for a support arrangement? Or would they go to a Moodle host? Would we continue to appear to be a distinct entity in the eyes of a user? We don’t think so, and given that, what’s the positive impact for us? (It is, after all, about us, in some respects.)

Q: How could we provide this service to Moodle-type products while maintaining our sovereignty?
A: We can (and will) offer a pre-built Moodle plugin, in addition to other plugins that integrate out of the box. Pricing and usage options have yet to be determined, but we want to solve the SCORM problem for the open source LMSs, or at least those willing to integrate with a non-GPL product (it would be separate).

Q: Do we live up to Red Hat’s definition of providing value? Is the work we’re doing after software delivery important enough to merit the ongoing fees we charge.
A: We’re confident that we do. Our willingness to solve problems that may or may not be of our making is valuable. Our contribution to the evolution of the standards is real. And our products continue to evolve and solve a difficult problem. If nothing else, having us on call eliminates the need for our customers to own SCORM expertise.

Q: How do you justify costs to someone who has elected to go with an open source software solution?
A: For this and other reasons, we intend to offer a hosted solution (the SCORM Cloud), one that will have the SCORM Engine’s fantastic compatibility in addition to pre-established connectivity. Down the road, the ability to share information between LMSs as accepted by our customers could allow this to be the first step toward centralizing best of breed content delivery in a way that many LMSs will use.

Conclusions

We want to find ways to work with open source software providers. We absolutely recognize the value they provide and their increasing relevance in our industry broadly (software) and specifically (online learning). We believe the SCORM Cloud and associated connectors (plugins or modules for Moodle, et al) will allow us to integrate with these software packages in a way that allows their users to take advantage of our best of breed content delivery. This service, we believe, will be worthy of the associated cost.

I hope the snapshot of our approach here is useful. Electing to maintain our current licensing structure was not a trivial decision for us… it was considered carefully. Building a piece of software (SCORM Cloud) that will allow us to service these products (and others) effectively wasn’t trivial either. But as I’ve mentioned on Twitter the last few weeks, I’m feeling pretty good about the approach and the initial levels of interest.

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