Interesting thoughts and I agree Forking can be beneficial in different circumstances especially when technology is not evolving at the pace it should.
Originally posted on Gigaom:
The rumblings have been around for weeks but now they’re breaking the surface: Cloud Foundry, the open source platform-as-a-service framework faces a bit of an insurrection. Several vendors, such as AppFog, ActiveState, Tier 3, Uhuru, etc. — have built PaaSes atop the framework and some have quietly been mulling forking the Cloud Foundry code, citing lack of clarity about the project’s future.
The attraction of the multi-vendor Cloud Foundry effort is that, in theory, it would provide customers an array of compatible PaaSes from different vendors. If they don’t like their experience with one, they can move their code elsewhere. But now the prospect of a “fork” looms with some other vendors thinking of splitting off and doing their own iterations. Worst case scenario: that could negate any promise of compatibility. And that raises the old bugaboo of vendor lock-in which even PaaS providers say has restricted business demand for PaaSes.
Some background: late last year, VMware(s vmw) turned over the Cloud Foundry effort and related projects to the Pivotal Initiative spinoff. Since then some of the third-party Cloud Foundry crowd have complained that they have not gotten information they need from Pivotal. And, they worry that Pivotal or VMware will push its own commercial, competitive version of Cloud Foundry. And so they privately discussed forking the Cloud Foundry code. Any fork or forks raises the specter of a fractured standard.