Vendors increasingly control leading open-source projects
Given the momentum behind open source, and how it has grown through the economic downturn, it's not surprising that more and more vendors are getting involved to commercialize open-source projects. What is perhaps surprising, however, is how early in the open-source project lifecycle that commercialization is emerging, as Gartner indicates in a December 2008 report ("Predicts 2009: The Evolving Open-Source Software Model").
Gartner suggests that by 2012, "50% of direct commercial revenue attributed to open-source products or services will come from projects under a single vendor's patronage." What this means, however, is open to interpretation.
Here's Gartner's:
Driven by expanding mainstream IT adoption, open-source usage profiles are shifting to more-conservative, risk-versus-reward dynamics. As a result, new adopters now place an increasing premium on commercial support channels to establish service-level agreements on par with closed-source alternatives.
In response to commercial open-source demand, many new projects are being commercialized early in their maturity phases--often by a dot-com startup, and before a broad community "network effect" is firmly established. These projects are often under the patronage (if not authoritative control) of a single vendor that employs nearly (if not entirely) all key code contributors.
While Gartner suggests that this trend will lead to cost parity with proprietary solutions 50 percent of the time, the facts don't bear out this assertion. For example, Forrester finds that 87 percent of enterprises surveyed reduced costs through open source.
In part, this is due to commercial open-source vendors charging dramatically less than their proprietary peers. We can pass on sales and marketing cost savings in the form of maintenance savings.
It would be nice to discount this cost savings as transitory--a near-term phenomenon that dissipates once vendors control open-source projects--or related to community-based open source. But Forrester's Jeffrey Hammond, supported by IT executives from Virgin Mobile and San Francisco International Airport, argued at OSCON in July that open source, commercial or community-based, saves money in deployment costs, acquisition costs, and ongoing maintenance costs (if any).
Pixie dust comes and goes
Still, Gartner has a point. It's true that there are trade-offs that come with commercialization of open-source projects. Some of the magic pixie dust arguably evaporates when a company is behind a project.
But other "magic pixie dust" appears. Polish. Documentation. Enterprise acceptance. And more.
Was Linux hurt by Red Hat's involvement? Hardly. Linux has thrived in tandem with Red Hat's prominent role in developing the Linux kernel.
For those that think community-based support is the way to go, consider CentOS, a clone of Red Hat Enteprrise Linux. CentOS recently had its leader go AWOL. While the situation was eventually resolved, a serious vendor like Red Hat mitigates the vagaries of community whims, like Red Hat's Alan Cox deciding to stop working on tty development.
But it's not just Linux. Is Drupal adversely affected by Acquia? Lucene/Solr by Lucid Imagination? MySQL by MySQL? Jasper Reports by JasperSoft? And so on.
In every case, I'd argue that the projects have been significantly blessed by vendor involvement, not cursed. There are downsides to company involvement, but those are primarily the vendor's issues, not the customer's.
Regardless, Gartner is right to highlight the significant benefits of open source that transcend price tags.
Adopters will continue to receive benefits from open-source solutions, but these benefits will be increasingly realized by advantages in investment protection, innovation and technology alignments, rather than by simple cost savings alone.
Forrester, too, called this out at OSCON, articulating that while many companies adopt open source to save money, and do, they discover a myriad of other benefits along the way. Increased flexibility, higher quality, and more.
(Credit:
Forrester)
For example, the U.S. Federal Aviation Administration argues that "Being able to look at source code is a huge benefit, instead of just getting a black-box executable we can't even look at....[I]t's always nice to be able to modify something on our own. We count on [open-source vendor] Progress to do the heavy lifting, but we do keep our own options open." The FAA depends on Progress, without being dependent on Progress, and gets a great deal of benefit from both the open-source software and the open-source vendor.
I'll buy that. Frankly, whether it ultimately costs me more or less is somewhat immaterial. I don't buy Macs because they're cheaper. I buy them because they're better. In like manner, I buy open-source products because they are often much better, in several ways, than proprietary alternatives. Not always, but often enough that if you're not at least considering open-source alternatives, you're missing out.
Follow me on Twitter @mjasay.
Matt Asay brings a decade of in-the-trenches open-source business and legal experience to The Open Road, with an emphasis on emerging open-source business strategies and opportunities. Matt is vice president of business development at Alfresco, a company that develops open-source software for content management. He is a member of the CNET Blog Network and is not an employee of CNET. Disclosure. You can follow Matt on Twitter @mjasay. 
As the XFree86 to x.org transition demonstrated, the effect can be made to be so minimal that the 'leaders' can be discarded without any serious consequences and varies greatly from project to project.
I don't personally see this as greatly different from relying on one vendor over another; purchasing support from a badly managed company is no less a risk.
Alan Cox is currently an Intel employee.
http://lxer.com/module/newswire/view/114064/
You should consider correcting the text of the post to reflect that fact.
Matt, you have to do much better than this in terms of fact checking. Many individuals have been employed by Red Hat at some point and moved on to another company as open source developers.
God forbid you were told something in confidence by an unnamed source and misidentified that source as working for a company they don't actually work for any more and then repeated that information in one of your articles as coming from the company. If you can't even get Alan's current employment status correct, it makes me wonder if you have correctly identified your previously unnamed Canonical employee as correctly working for Canonical.
-jef
Open source software only comes in one edition: awesome.
http://www.codinghorror.com/blog/archives/001283.html
supported by IT executives from Virgin Mobile and San Francisco International Airport, argued at OSCON in July that open source, commercial or community-based, saves money in deployment costs, acquisition costs, and >>> ongoing maintenance costs (if any). <<<
----------------
When will people like this understand that for *most* companies IT is not a core competency? Do they really want to employ a team of expert C programmers to support an open source solution such as a database or OS they use that is mission critical to a business of making widgets?
- by appcrawler August 6, 2009 4:27 AM PDT
- ---------------------
- Like this Reply to this comment
-
(6 Comments)Thankyou for repeating myth #24. This is about _using_ open source, not _developing_ it. The idea that the former requires the latter just belies your complete and utter lack of clue. I do hope you're not in any form employed in IT because you're either so utterly clueless or disingenuous as to be a liability.
---------------------
I don't think I was clear. Are you suggesting that to _use_ (your emphasis) open source without any "maintenance costs" (which I would attribute to a support cost bucket) is good business sense?
If you believe you can _use_ open source without maintenance costs, where would you put a support contract? If you wouldn't pay for support, how would you *ensure* you could get it fixed?