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.”

Around the time that the GPLv3 was being finalized I decided to read up on the Affero General Public License.  Most of you are probably familiar with the AGPL (so skip to the next paragraph), but for those that aren’t here’s a crash course.  The GPL requires derivative works based on GPL’d code to be released publicly.  However, this requirement only applies if the person/company that developed the derivative work decides to redistribute the code (in binary format).  Clearly this doesn’t apply to companies like Google or Facebook that use and create derivative works from GPL code, but doesn’t redistribute the code.  The AGPL was designed to close this loophole.   The AGPL requires derivative works to be released into the community, even if the code is only being accessed over a network, and not being redistributed.

At the time, I had my reservations about AGPL licensing.  I wondered if, for instance, Google would have used as much open source as they currently do if much of the code was AGPL’d.  Would Google really want to release code modifications that aided Google’s differentiation vs. the competition?  Could Google really separate out the GPL/AGPL code from the proprietary Google code/applications?

Why would a company like Google want to contribute their derivative works back?  One reason could be self interest.  A great example of this is the news from Facebook that they have made some interesting modifications to memcached, which lets Facebook run 200,000 UDP request/second vs. 50,000 before the Facebook modifications to memcached.

Facebook has decided to release their modifications and is hoping that they’ll be picked up by the official memcached distribution.  Why do this?  Clearly there is no license-based reason to do so since memcached is BSD licensed. Well, aside from being all around good guys/gals, contributing this code back to memcached ensures that Facebook can use the official version they get from memcached in the future.  Facebook doesn’t have to keep its own branch of memcached internally and try to apply service and feature updates to its own version as newer versions of the official memcached distribution become available.

Do the modifications that Facebook made to memcached aid Facebook’s differentiation vs. competitors? If so, why release the code and allow competitors to access the same technology benefit?

To the first question, I’d say the modifications appear to be differentiators.  The modifications allow Facebook to serve more customers with lower latency at a lower TCO (due to fewer servers required).  To the second question, it seems Facebook values using off the shelf open source in its infrastructure.  Like many companies that use open source, Facebook would rather that someone else (i.e. the memcached community) take care of that code while Facebook developers work on code/applications that are much closer to the Facebook end user.

What do you think?