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?
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 ;)
Love what you're doing, but I couldn't figure out how to export my fatfreecrm data in case I ever have to move away from cloudfuji. Is there a way to do this?
There isn't a standard way right now, though we'd be happy to add that in! In the most manual case, we can give you any kind of database export you'd like.
Our goal is to make the data for a user owned by the user - so when you move from Fat Free CRM to Salesforce, your data follows you without any special config at all.
If anyone contacts us for a data export right now, we'll take care of it ourselves and send it over :)
Yup, custom domains are possible on Cloudfuji, because we're running the vast majority on Cloud Foundry OSS, which does support custom domains.
CloudFoundry.com doesn't support custom domains yet while it's in beta, but I'm sure it's on its way and should be available as they make their way out of beta.
