Hacker News Reader

Comment by shykes | Hacker News Reader

Cloudfoundry is really intriguing to me. On the one hand cf-based vendors point out the awesome acceleration effect of many companies contributing to a common codebase. Yet they all emphasize their unique value-add compared to vanilla cf and everyone else - which they do by maintaining a private fork and not contributing back upstream. Aren't these 2 things mutually exclusive and slightly hypocritical?

View on HN

Solomon, wait, just 2 days ago you said CF was throw away code and not on your radar? Care to explain your pivot to 'intriguing'?

https://twitter.com/solomonstre/status/209895170194423808

Hi James, in this tweet I'm referring to phpfog, which has been publicly deprecated (the polite term for "throwing away the code") in favor of a cloudfoundry deployment. Not necessarily a bad move in their situation... but yes, as a result it is not a very fearsome contender in the paas market.

I just looked you up and found out you're a cloud foundry evangelist. Would love to hear your thoughts on my original question. In your experience do cloudfoundry resellers contribute all of their customizations? Do they sometimes emphasize non-contributed extensions as key differentiators? And if so do you see this as a possible concern for the cohesion of the project? Do you (vmware) do anything to discourage (or perhaps encourage) this behavior?

I'm not an evangelist, but I am a member of the Cloud Foundry team, and responsible for partner development and ecosystem.

I think you are creating a straw man question as the overwhelming majority of partners have open sourced most/all of the applicable code. Take a look at http://www.ironfoundry.org for instance from Tier3 who has taken a very liberal approach to open source with their Cloud Foundry based service.

Appfog has also contributed back their code for PHP to Cloud Foundry. They are doing a very nice job of expanding the potential deployment targets as one of their competitive advantages (HP, Joyent, most EC2 regions).

Thus to answer your question I've seen robust contributions back with a very liberal amount of open source code, and a focus on value-add through service delivery options.

I'm curious about your view of the hybrid deployment model many of our users prefer with an on-prem instance that can be deployed to multiple service providers.

"I'm curious about your view of the hybrid deployment model many of our users prefer with an on-prem instance that can be deployed to multiple service providers."

I see these as 2 separate things:

- By "on-prem instance" I'm guessing you're referring to a local VM which mimics the remote deployment target? I think that is a cool and useful feature in the "nice-to-have" category.

- By "can be deployed to multiple service providers", I guess you mean that the portability between cf-enabled providers frees developers from lock-in? In my opinion this solves a non-existing problem. Developers can already deploy to multiple service providers with almost zero effort, because all service providers rely on open standards for deploying web applications. As a result portability is incredibly good between dotCloud, Heroku, Cloudfoundry and almost everybody else. Of course it's up to the developer to not lock themselves into proprietary APIs which are only available on certain service providers (eg. App Engine).

We're not a Cloud Foundry company, we really don't care about PaaS that much. We just needed something that fit our unique use case and that, in case the PaaS vendor didn't feel the same sense of urgency that we did for something we need, we could add in ourselves - I'm sure you're very familiar with that, Solomon. We're happily sending changes upstream whenever they're sufficiently high quality for everyone else.

So, 1.) We didn't want to (poorly) re-invent it ourselves, and 2.) We didn't find any existing provider that was able to match our schedule and needs. Cloud Foundry let us side-step both of those problems and launch. We'd be dead by now if we had waited.

Hi shrove, thanks for the precision. You have a point - you're tackling a particular edge case in deployment which most paas providers are neglecting, leaving you vulnerable to shifting priorities in their roadmap. It makes sense for you to take your destiny into your own hands, so to speak.

My question was triggered by your article but not particularly targeted at you - I was hoping to start a philosophical conversation on the pros and cons of running a business on top of IP which you don't own. So far I don't see any takers ;)

Sgrove. Sean Grove.

And when you have a chance, I'd certainly be happy to take you out for drinks and chat for a bit. Sometime next week, perhaps?

I'm going to blame my iphone keyboard on this one :)

I'll accept an apology in the form of an email inviting me to tasty drinks and interesting conversation :)

Reply on news.ycombinator.com