I'm not sure what it would mean for them to move the tech industry into their political machine. Could you clarify?

I assume he means having the more appealing political platform to hypothetical Tech Industry employees ie. young, urban and college educated.

For them I think it would mean that they could generate SOPA level pressure on lawmakers.

I agree pretty strongly. I read, for example, that the Obama campaign expanded the Democratic Party's voter database by something like a factor of 10.

But the database (and accompanying tech platform) then gets cycled back into the hands of state and local parties, where it can be incredibly useful.

I'm not entirely sure that's the case. The DNC voterfile is compiled primarily from public record requests, and is as complete this cycle as it was in any other.

Narwhal and other OFA DBs may have supplemental information -- as do the "blue" vendors -- but that's separate from the voterfile, and I'm not sure its life-cycle is certain at this point.

The problem with BitNami Cloud is that they are AWS only and the pricing model is highly opaque. You pay once for Bitnami and then AGAIN for AWS. According to AppFog's pricing you pay only one source, namely us and never Amazon or Rackspace or HP or anyone else, and pricing is solely RAM-based, which means that it's next to impossible to incur costs that you don't actively choose.

I don't get why you claim the pricing is opaque. If anything, it is completely transparent because we do not add any markup whatsoever to the AWS charges, so in most cases it will result in a much lower monthly bill. Regarding it being AWS-specific, Bitnami Cloud Hosting is, but the rest of the BitNami offering and images is available for other clouds such as Azure and HP. We also integrate well with the rest of the AWS infrastructure: CloudWatch, CloudFormation, Beanstalk, etc.

I totally get that, and no markup above and beyond AWS pricing seems like the way to go.

But the problem is that AWS pricing itself is not completely transparent. It's based on usage, which means that the bill at the end of the month can end up being an unpleasant surprise, as it has been for lots and lots of AWS users over the years. Who can know in advance what their usage figures will be?

RAM-based pricing means that the bill at the end of the month literally cannot be a surprise. We have four available plans, and monthly bills map directly and seamlessly onto those plans.

We run on AWS (among others) but WE pay AWS, not our customers, because we think that part of the mission of PaaS is to shield customers from the many disparate pricing models on different IaaS providers. Want to run on Rackspace via AppFog? Same price. Want to run on HP? Same price. Azure? Same price.

PaaS needs to abstract hardware away completely, even monetarily. Paying IaaS providers directly is not the way to do that.

It seems we have different customer feedback. Our offerings are different, so we may be targeting different segments as well. What we get is that many of our customers (specially the bigger ones that run dozens / hundreds of machines) want to deal directly with the underlying vendor and do not want to be shielded from that. Having a predictable bill and dealing with a single vendor is convenient (specially when starting out) but the economics do not scale up as well for the customer as dealing with the IaaS vendor directly is always going to be cheaper, specially as they grow. It also moves the customer lock-in from the IaaS provider to your platform, which many customers are wary of. With BitNami, they can cancel the subscription and still keep managing their infrastructure through the regular AWS console or Rightscale. In any case, not arguing that a single, predictable bill is not appealing, just that it is not as appealing as what you would give up in exchange for that (at least for our current customer base, I am guessing yours is different in that respect)

You're right. I think people need to give AppFog a chance.

Once they do something like, for example, cloning an app in Singapore and re-deploying it in Ireland in less than a minute, they'll see the value in what we've built.

AppFog does not currently support persistent file systems, but we're working hard on adding this feature. In the meantime, we strongly recommend Amazon S3 as a persistent file store.

AppFog is absolutely NOT being discontinued! We are incredibly proud of what we accomplished with PHP Fog, but we think that the AppFog is the true future of PaaS: polyglot and poly-infrastructure. We simply don't think that single-language PaaS on a single infrastructure is the future, and we're working on rolling all of the functionality from PHP Fog into AppFog, where you'll be able to deploy Node, Java, Python, Ruby, and other runtimes and deploy to a variety of infras.

AppFog is absolutely thriving right now and will be around for quite some time, we assure you.

Sure it is. And I'll bet if you look through your archives you'll find that you made the same assurances about PHPFOG...

Please note: this is the first in a series of tutorials. This tutorial in particular is devoted solely to migrating application code. Tomorrow, we will post the first of two data migration tutorials that will walk users through the data migration process.

I know, I know. It's all that was available at the time this was announced, a little over a month before free accounts are scheduled to be shut down. Some people are probably already migrating.

Is it true that appfog's filesystem is volatile? Does this mean that it could be wiped without a system fault or a user shutting down the system? If so, there doesn't seem to be a clear migration path to appfog for PHP users that are using the writable directory support. If not, it should probably be documented that writes will only go to the one instance and that if you're using multiple app server instances you need to set something up.