Reading about HipHop for PHP, I was reminded about a post from Redmonk's Stephen O'Grady titled "When Your Customer Is Your Competitor: The Return of Roll Your Own." Stephen argues that the traditional definition of a "software company" is far too narrow.
Why do you think Facebook would sponsor the Apache Foundation? Because, like Amazon, they’re in the business of producing software. Software like Cassandra. ... Ruby on Rails came out of 37Signals' Basecamp, a Software-as-a-Service project management tool. Django? Extracted From the Lawrence Journal-World's website. Crane? Derived from Flightcaster. Git? Written by Linus Torvalds to manage the Linux kernel tree. None of this software, of course, would be all that interesting except for one important change: this in-house developed code is open source, and shared with others. Which has led to entirely new -- and entirely unanticipated -- business models.
I agree with Stephen's claim that interesting and popular software projects are no longer solely the purview of vendors whose financial future is linked to directly monetizing the software in question. One could argue that vendors in the business of producing software that is directly monetized are at risk of being marginalized by companies offering a competitive software solution without the need to directly monetize the software itself.
For instance, who could have guessed that Zend, the commercial vendor behind PHP, would face competition from Facebook? What's more, Facebook could care less about selling licenses, subscriptions, or extensions to HipHop for PHP. Therein lies the catch-22 and, potentially, the opportunity.
Note: I'll use Zend and HipHop for PHP as examples, but the argument could be applied to any commercial software vendor facing competition from an open source project whose sponsor is not in the business of directly monetizing the software itself.
Facebook's lack of business interest in the project makes it difficult for enterprises to select and purchase HipHop for PHP offerings. As a result, there is an opportunity for a third-party vendor to provide commercial support and products around HipHop for PHP. However, without control of the project and the project's copyright and trademark, it's difficult to monetize usage.
For instance, who and which company comes to mind when you think about of Ruby on Rails? If you said David Heinemeier Hansson and 37signals, you'd probably be in the majority. David Heinemeier Hansson founded Ruby on Rails, and his company, 37signals, uses it as the infrastructure to build applications that 37signals sells. Several third-party vendors offer support and related products for Ruby on Rails. However, none are as well known as 37signals, which does not offer support or commercial Ruby on Rails products.
Next, who and which company comes to mind when you think about Drupal? If you said Dries Buytaert and Acquia, you'd probably be in the majority. Dries founded Drupal and then co-founded Acquia to monetize the software itself. Companies can purchase Drupal support and commercial offerings directly from Acquia, which benefits from the awareness associated with Dries being co-founder.
Since Facebook likely owns the intellectual property, I doubt that Haiping Zhao, one of the HipHop for PHP creators, will leave Facebook to follow in Dries' footsteps. This leaves the possibility of a third-party vendor providing support and commercial offerings around HipHop for PHP. However, the vendor will face many of the awareness and monetization challenges that Ruby on Rails vendors face.
With all this in mind, I have to conclude that, while HipHop for PHP is competitive with Zend's commercial offerings on paper, Zend has little to fear from the project itself.
To generalize, it would appear that software vendor incumbents face minimal risk from open source projects sponsored by vendors who do not seek to directly monetize the software itself. I could be convinced otherwise, but that's my starting position.
Follow me on Twitter: SavioRodrigues.
p.s. I should state: "The postings on this site are my own and don't necessarily represent IBM's positions, strategies, or opinions."