Open Sources | Rodrigues & Urlocker » The proprietary/open source continuum for ISVs

February 05, 2007 | Comments: (0)

The proprietary/open source continuum for ISVs

TAGS: Open Source

Larry Augustin was in town over the weekend, so we met up at Deer Valley for lunch and gossip. We then spent a half-hour talking through the different licensing models available to open source software vendos, and their relative merits/demerits. (No wonder Larry's wife and daughter got bored and left. ;-)

The core question up for discussion? Is 100% free source software the best model for any software vendor? I went into it wanting to say 'Yes,' but left wondering.

First off, we identified a range of strategies/services a vendor can offer that fall between a pure support model and a pure proprietary license model. Look around at many open source companies (and virtually all proprietary software companies), and you notice, as Larry said, a distinct lack of trust that free software will sell. Why do they keep code back? Because they don't believe that customers will pay them, otherwise. In some cases, they're probably right.

For example, it's unclear to me that someone focused on the SMB market is going to succeed as readily with a free source model as a company focused on the enterprise market - enterprises have a different risk profile, and so will pay for things like support/certification/documentation/etc. more readily than an SMB, generally speaking.

At any rate, we discussed a range of things that vendors can sell that don't require proprietary licenses, but do effectively give a vendor "proprietary" services to distinguish between the code and the total package:

• Documentation. A thriving community will self-produce good, and sometimes exemplary, documentation. But not often, because it's not the primary concern of most developers with most projects. So, having the company provide certified documentation that is only available to paid subscribers smells like a winner.

  (As a sidenote, the vast majority of my company's support calls don't relate to bugs, but rather to questions about configuration and such. In other words, things that documentation would fix.)

• Automated updates/patches. A la Red Hat Network, JBoss Operations Network, MySQL Network Monitoring and Advisory Service, etc. It's code, yes. But it's really a service wrapped in code.

• Support. Standard fare, but important. It's critical, however, that a company's services be much more than someone answering a phone when things break. That scales, but not impressively well.

• Certified binaries. Red Hat, MySQL, Alfresco, and others provide certified binaries to their customers as a way to help them get from code to solution faster. One strategy might be to provide bug fixes between product releases in source code, and reserve the certified binaries incorporating those fixes only to paid subscribers. The packaging up of that code, in other words, is a service that customers should pay to access. If someone wants to compile their own, no problem. But for those who value time and want to reduce risk, certified binaries are a good way to go.

• Immediate bug fixes. Related to the above, vendors could allow their communities to be a bit better about self-healing by reserving bug fixes (except critical ones) between product releases. This raises the value of commercial support without withholding access to source code.

• Best practices. One of the primary things my customers ask me for is insight into how other Alfresco customers have deployed our open source content management solutions. This sort of insight could be usefully deployed through a network-type subscription, just as MySQL is doing. It's a great way to bring extensive experience in-house, without the overhead of staffing it.

• Third-party software certification. Related to some of the bullets above, this is arguably Red Hat's biggest historical advantage over Novell. Early on, Red Hat figured out that managing all the moving parts that needed to run on a Linux OS would be a real advantage. They've been printing the money ever since. Customers don't want to have to guess that your application will run on DB2 - they want you to guarantee it. That guarantee is a sales opportunity. It's not clear that this kind of certification is as compelling at the applications (or even middleware + database layers) of the software stack. But it helps.

• More? I'm sure there are others, but my kids are going to wake up soon.

Importantly, all of the things mentioned above are additive to the software experience. Proprietary software is basically about removing rights to push would-be customers to buy them back. But these value-adding services are just that: added value to the software experience.

This is what I love about open source software. It's a way to focus the customer experience on a vendor to vendor relationship, rather than a vendor to code relationship. The value is in helping customers extract value from the software, not in a license. Licenses do nothing for customers. Services do.

Posted by Matt Asay on February 5, 2007 05:09 AM

RATE THIS ARTICLE: