I'm finishing up my presentation for the upcoming COSS.fi event next week (4/19/07), and was exploring an idea - how do you compete when the code is open? - when two things happened in quick succession.
One, I was reading the Bible and came across this interesting verse from Genesis:
...Cursed is the ground for thy sake; in sorrow shalt thou eat of it all the days of thy life;Thorns also and thistles shall it bring forth to thee; and thou shalt eat the herb of the field;
In the sweat of thy face shalt thou eat bread, till thou return unto the ground.... [Genesis 3:17-19]
In other words, it's good to have to wade through difficulty. That's where growth comes from. There are no magic shortcuts to prosperity.
Second, I read Mike Olson's response to some criticism that I and Stephen O'Grady had heaped upon his plate. Namely, that Oracle was siphoning dollars/value out of the Linux ecosystem rather than injecting dollars/value into that ecosystem.
Mike writes:
Because of the GPL, the source code for Linux is freely available to everyone. No vendor is able to assert control over its own version of the software. If your Linux-based business depends on having that control, you are in trouble....I don't believe that Red Hat ever relied on control of the bits. The company has built a tremendous brand and a growing business based on its services. Its success to date is due to those strengths. I believe that Red Hat has always planned to compete on brand and services, and not on exclusive access to the source code that it compiles.
I believe Matt wants to protect Red Hat from competition based on the bits. That's a bad idea. First, it's just impossible. The bits are free. More importantly, though, protectionism is an emotional and short-sighted strategy in any market, but especially one as dynamic as technology. Competition drives innovation and excellence. Its absence weakens companies. Whatever short-term pain you believe that open source licensing may cause Oracle -- or Red Hat -- the market will adapt to build new value at lower cost for customers.
I think I agree with Mike, but am a bit surprised that he conveniently forgets that his company's entire business depends precisely upon "protectionism." That is, proprietary software (with a dash of Linux to make the price of the database a little easier to swallow). What was that recent spat with SAP all about, if not protectionism? The minute you lock your code or content in patent/copyright/etc., you are a protectionist, aren't you? (Sometimes in the good sense, and sometimes in the not-so-good sense.)
The entire software industry has been built on protectionism, but is now giving way to competition on open terms, the way most industries work. I agree with Mike - this is good, and this is progress. I disagree, I think, with his implicit suggestion that Oracle (and other proprietary software vendors) competes in the same way. (Mike: I may have misread your argument. If so, let me know how.)
Why does this matter, and why do I stand up for Red Hat and other open source companies? Because I'm trying to figure out in real-time how competition works in this new world of open source. If open source can't hold off competitors, it has a very short shelf life as a standalone business strategy.
COSS.fi's representative asked me to speak to the following:
"What about the risk that someone captures your business (we now know that Oracle didn't manage to do this, but it challenged one of the best)."
He's referring to the InnoDB and Red Hat threats, and it's of concern to every single open source vendor. Alfresco recently went 100% GPL. What happens when we become a clear and present danger to the established vendors, taking hundreds of millions of dollars out of their pockets instead of tens of millions?
They will fight back. Perhaps they'll "screen scrape our bits," which they're legally entitled to do, and offer support for Alfresco. They'll become Pseudo-Alfresco, in other words. My question is how we prevent this (we gave up attribution, though that was a good way to mitigate copycat risk)? My larger question is how do we tolerate or even encourage this and still win?
Hence, how do you compete when the software is free?
Here are a few of my (early) ideas. which relate to something I posted before on value open source vendors can provide without going proprietary:
- Rely on brand (i.e., trademark law and sheer momentum). Mike alludes to this above, and I think it's very strong. The problem is that this protection doesn't extend to early projects, which almost by definition have no brand. Eventually, though, as Mike Moritz has said, "Lots of customers are better barriers to entry than lots of IP."
- Source of code, not source code. Savio Rodrigues (IBM) believes this ruins the 'open source provides more choice' idea, and he has a point. But my business is benefiting customers with great software and services, not enabling competitors. At any rate, it's still too early in the Oracle Linux battle to see if Oracle can out-support Red Hat.
I don't think it can, but if it can and does (and if this same success by Oracle or other vendors that are threatened by an open source upstart), then there would appear to be little incentive to invest in creating an open source project at all. I'm confident, however, that customers will buy from the source (who the "source" is in Linux is more complicated than with MySQL, as Mike points out, so maybe I shouldn't extrapolate too widely from forking in the Linux world).
- Completely shift the value conversation from software to service. This can be achieved through SaaS, but it's also what Red Hat, MySQL, JBoss, and others have done with their "networks." It's also where I think the future of open source businesses lies. I think a pure service business has maybe two or three years of life in it, before the product becomes stable and humdrum enough that support has less resonance as a reason to fork out cash. JBoss seems to have hit this wall. I've talked with large customers that happily standardized on JBoss...without paying a dime in support.
Enter the JBoss Operational Network, which shifted value to monitoring the systems, providing a support portal, etc. Suddenly, there was a real reason beyond the software to pay JBoss, and the company's revenue shot up. Significantly.
- Compete on speed. Both fast and slow. Split your product into "Hare" and "Tortoise." Both are 100% open source, and both are functionally equivalent (at least, initially), but wrap Tortoise in a contract that disallows forking and distribution, and keep Hare humming at a daily refresh rate, with bug fixes going immediately into Tortoise and relying on the community to provide quick fixes for Hare. Put Tortoise on a slower release cycle to appeal to enterprises.
A competitor can take the code for Hare, but they take it subject to its speed of development (and the bugs generally associated with it). They can fix those bugs themselves, of course, but they'll almost certainly never do it as well as the company itself (Source of Code). At major releases, pull all bug fixes back into Hare and start again. At major release time, then, the competitor has the best chance of competing...except that they will have to spend a few weeks/months getting up to speed (pun intended) on the newest release. In short, they're constantly playing catch up.
- Just allow forking. If an established vendor is desperate enough to attempt it, they have problems that your code won't solve. This is not applicable to Oracle and Linux, since Linux is complementary to its business, not competitive. But if a proprietary competitor decided to co-opt Alfresco's code and sell service around it, this would beg the question to all customers as to why the company can't compete with its own.
In the end, it may well turn out that Brand, Networks, Speed, and Source of Code are enough to mitigate credible threats on an open source business. I don't know. I'll let you know when we IPO. :-)
But it would be fascinating to have someone look at antitrust law on the topic; specifically, Eastman Kodak-related "aftermarket" law (here's a great overview). Just because I produce software doesn't mean I have an exclusive right to the aftermarket service/support/etc. Right? Open source says no. US antitrust law is more ambivalent on the issue. (Though, of course, this is a bit like comparing apples and oranges, since in open source you explicitly license the software in such a way to enable an aftermarket.)
Interesting times....