After reading Matthew Aslett's followup to Matt Asay's original entry on the problem with open source revenue models, I started churning my wheels upstairs. And while I won't offer a futuristic view of what open source revenue models will look like in 20** or beyond it is obvious to me that their evolution shouldn't be held to expectations set by a proprietary software world view. Still, it strikes me as odd that the boundaries of thought surrounding the open source world don't seem to reflect the stark differences between the nature of the business and software development models employed within the two domains.
It's my perspective that the assumptions and guiding thought patterns garnered from the business of [proprietary] software are too inflexible to hold across the board for open source. The debate over revenue models is a perfect example. As I see it, sustained open source growth will not occur by mirroring what works for the Microsoft's and Oracle's of the world. Instead, open source success will, more than likely, be defined by how closely revenue models are to the realities of 1000's of companies like this one. So while we can recognize that it's the ReadyTechs of the world which represent the bulk of open source consumption by companies, questions about where monetization fits in are still outstanding.
As a result, open source vendors will become responsible for monetizing channels that connect them to the many companies who've built businesses around open source. Which, to be clear, is entirely different from pushing cheaper (and presumably open) products through the same channels fit with minor tweaks to service and support offerings. Reaching companies that have fully bought and invested in open source is the next step those vendors serious about continued growth. Along those lines, one of the main challenges surrounds constructing revenue streams which are composed of such entities. And typically, the thought has been that businesses don't always need to become customers in order to benefit from open source. Which is true, but isn't a blanket statement. Yes, for those organizations looking to cut IT costs, nothing beats a free product.
However, there are still a significant number of gaps associated with building around community supported open source. Gaps which represent pain points for the companies that choose to forgo purchasing traditional service and support contracts. The dominant mode of thought is that the drop off between free and supported use is endemic to the open source experience, yet I view them it as an opportunity to expand the notion of service and support delivery. If this sounds abstract, picture vendors supporting self-support through highly cost effective, flex "contracts" which would cover the middle ground between going it alone and purchasing the 24/7-type support which can prove to be overkill. Or maybe, vendors could offer the option of a pay-to-join shared space in which to exchange success stories, best practices, successful deployment projects and architectures for community editions.
Whatever the case, the open source revenue models which plan to thrive had better evolve to create a bigger monetization overlap with their user base. Will this require innovation? Of course. Perhaps even radical (comparatively) forms of service and support delivery. However, all of it should be done within the context of preparing to capitalize on the next wave of open source disruption...instead of being crushed by it.
Recent Comments