Facebook recently open sourced HipHop for PHP. According to Facebook engineers, the technology has been used to reduce Facebook Web server CPU usage by an average of 50 percent. 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 prevue 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 which 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 at: SavioRodrigues

PS: I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies or opinions.”

Dave interviewed Zend’s CEO Andi Gutmans.  I particularly found this part of the interview interesting:

Rosenberg: When you start talking about high reliability, security, and performance, it sounds like you’re working to disrupt traditional Java environments? Is my hunch correct?

Gutmans: The Java disruption by PHP is well under way.  PHP is everywhere, and Zend’s solutions are being used in business-critical deployments by companies such as Tagged, Fiat, BNP Paribas, and Fox Interactive Media, to name a few. The strategic adoption of Zend in larger accounts, often in favor of Java, is related to our strong return on investment and shorter time to market.”

To argue that PHP is disrupting Java usage is, if you ask me, missing the point.  You know something is wrong when Roy Russo is the voice of reason.  On Matt’s follow up to Dave’s post, Roy comments:

“The truth is that both PHP and Java have their place within an IT organization. The funny thing is that stories about the demise and disruption of Java still get published.”

There is an interesting discussion at Slashdot about Twitter shifting workload from Ruby on Rails over to Scala.  Readers have compared technology choices at Twitter versus Facebook. Slashdot reader mini_me writes:

“While Facebook uses PHP where Twitter uses Rails, Facebook uses a plethora of languages to make the whole system work. So Twitter really isn’t going to Scala any more than Facebook is going to Erlang. Which is the say that they use the best tool for the job, not one tool for every job.”

To be fair, the Java ecosystem made the error of recommending the Java language and platform as the right tool for every job in the past.  Today, Java infrastructure providers have shifted to offer a broader set of tools to help right-size the infrastructure to the project needs.  This will only continue.  And as it does, PHP, Groovy, Ruby, Java and several other languages will be used together to help customers drive business results.

The customers I speak with aren’t backing away from their Java investments when they ask for broader dynamic scripting language support within their enterprise application server.  Rather, they see value in using different language environments to extend the value of their Java investments.

Maybe I’m biased, but Java the language and Java the platform have little to fear from PHP or other scripting language environments.

What do you think?

Follow me on twitter at: SavioRodrigues