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

I completely agree with Matt Aslett’s view that 2009 will see consolidation in the open source arena at the hands of established software vendors (e.g. IBM, Oracle, Microsoft, SAP).  Aslett writes:

“As proprietary vendors will be looking to open source to extend their reach into new potential customers, many open-source vendors will be looking to proprietary technology as a means of converting community interest into revenue.”

Matt Asay also agrees with Matt Aslett, and Asay predicts that Microsoft will make its first open source acquisition in 2009, probably Zend.  Indeed, folks at Microsoft have, at a minimum, considered this acquisition.  I think it’s a bad idea, here’s why:

IBM was long considered an open source supporter before we made our first “open source acquisition“.  Sun was considered an Open Source company well before acquiring MySQL.  Oracle’s acquisition of Sleepycat didn’t really add to its Open Source credibility.  Intel and HP are considered open source supporters, without open source acquisitions.  Simply put, a Traditional vendor can support the open source movement without acquiring an open source company.

Now, considering Zend specifically; the problem with buying Zend is that the acquisition delivers very little customer value or impact to the acquirer’s top/bottom line.

What would Zend deliver to Microsoft (or another suitor, be it IBM, Oracle, SAP, or even Red Hat)?  Two key items that come to mind, first control over the PHP language, and second, revenue that Zend drives from Zend’s enterprise PHP products.

Control over the PHP language is a red herring.  Customers can be well served without control of the PHP language.  IBM and Oracle both have PHP-based offerings without having control over the language.  If Microsoft were to buy Zend, what could Microsoft do with the PHP language?  Microsoft couldn’t make any language-specific changes that would favor the Windows environment or allow native access to Windows resources without users fearing that their PHP applications will be locked into the Windows OS.  One great thing about PHP is that I can develop on my Windows desktop and deploy to my hosting service provider running Linux.  If this changes, Microsoft (or any Zend acquirer) should expect an uproar from millions of PHP users.  Also, we shouldn’t neglect the possibility of another vendor or “the community” forking the PHP interpreter under the guise of protecting PHP users from Microsoft’s commercial interests.

Next, let’s consider the revenue potential through Zend.  Today, the revenue is nowhere close to impacting Microsoft’s growth targets.  The reality is that PHP use is so widespread that the “community PHP” has become solid enough for all but a few usage scenarios.  So, the need to pay for a “production ready PHP” or advanced management, scalability, etc. for “business critical PHP” is minimized by the quality and breadth of community driven PHP offerings.

Having PHP in its toolbox isn’t going to help Microsoft grow revenue in the enterprise market.  Let’s not ignore the fact that the PHP language hasn’t been able to attract developer interest at the enterprise level.  This has been a surprise to me considering the level of PHP use outside of the enterprise.  Yet, Python and Groovy have had a lot more traction than PHP in the enterprise.

This leaves us with Microsoft using PHP to further penetrate small & medium sized business (SMB) and partners.  Microsoft already owns this segment, and VB is the lead-with language here.  So, adding PHP into the mix isn’t going to drive a lot of net new revenue.  Unless Microsoft is experiencing VB losses to PHP, which I doubt.  And even if these losses are occurring, then I’d argue that Microsoft’s current partnership with Zend delivers the same benefit to Microsoft that owing Zend would.  In both cases, the likelihood that the SMB is paying for the use of PHP, e.g. Zend-driven revenue, is minimal.  In both cases, the likelihood that the SMB is running the PHP application on Windows is very high.

Maybe it’s just me, but I see a lot more risk than upside for Microsoft in this particular deal.

What do you think?