'Open Source' does'nt mean what it used to

Does your interpretation of an "open source product" match your vendor's? If you don't know, you may not be getting what you expect.

Lately there's been lots of blog and Twitter chatter about recognizing an open source product. While an interesting intellectual exercise, the debate could also have a real-world impact on IT purchasing decisions.

Open source "purity"

I used to spend time debating the open source "purity" of a given open source vendor. I moved on when Shaun Connolly, with JBoss at the time, wrote a post titled "Open Source Community and Barack Obama." In 2010, it's incredibly difficult to define an "open source vendor," because virtually every IT vendor uses open source in its products, contributes to open source, or provides services around open source.

The recent debate about open source "purity" extends beyond the vendor and instead focuses on products. The debate is being spurred by the increasingly popular open-core licensing approach and the delivery of software products through cloud offerings. The 451 Group's Matt Aslett writes:

It ought to be simple: Either the software meets the open source definition or it does not. But it is not always easy to tell what license is being used, and in the case of software being delivered as a service, does it matter anyway? The ability to deliver software as a hosted service enables some companies that are claimed to be 100 percent open source to offer customers software for which the source code is not available.

In the perfect world, customers would pay vendors for the value they receive from usage of free and open source products. Because that hasn't really panned out, open-core licensing and cloud delivery of open source software are gaining attention as leading approaches to capture revenue around open source products.

Keep an eye on freedom of action

Customers using or considering a product that falls into the open-core licensing category, take note: The enterprise commercial product you purchase probably won't offer the same freedoms as the open source community edition that the developers likely used and became advocates for.

Some enterprise open-core commercial products don't even offer source code access. This obviously limits freedom of future action versus using the open source community edition. Other open-core commercial products do provide source code access, but only as long as your subscription license is current. As such, it's important to understand how easily your company can shift from using the enterprise commercial open-core product to using the open source community edition. You'll need to figure out if the enterprise features are really product extensions or if they are integral to your usage.

Gartner analyst Brian Prentice has argued that customers will eventually need to evaluate and price the enterprise commercial version of an open-core product. This is all the more true if there isn't a clear distinction between which kinds of features fall into the open source community edition versus the enterprise open-core commercial product.

Customers using or considering an offering that falls into the "cloud delivery of open source" category need to keep in mind two elements of freedom of action. First, is it possible to run the product on another cloud infrastructure or within the customer's own data center? Second, and often more important, is the customer's data locked into the vendor's cloud offering?

While usage of open-source-licensed products is heading in one direction, it's important for decision makers to understand that "open source" is utilized in many shapes and forms. With no malice intended, your interpretation may not match your vendor's interpretation.

InfoWorld.com