We're also considering different options e.g. Gittip vs traditional kickstarter-esque funding options with stickers and t-shirts. Currently there are 13 days on the clock, we'll post again when we're nearing deadline.
We'd be excited to hear any suggestions you have on how to balance individual and organization contributions and participation before then.
Thanks again for your support
Why can't you start the project first and then ask for donations later? Are you saying that unless you guys get paid you're not going to work on the project?
"hey I can get this for free, and I can get this TODAY. hm those developers are cool. maybe I'll donate some day"
Then they download and use the thing. 97% forget about donating and never return. Of the remaining people, they donate maybe $100 or something.
Up until recently Passenger was completely free, with donation options. Now they have an Enterprise offering - which we are happily paying for. I suspect the Enterprise licenses are orders of magnitude more than the donations ever were.
We're experimenting with a model that allows us to work full-time on a project for long enough to make it a viable production system.
Using LXC allows us to support applications that run on multiple processes, and since Juju is also written in Go, It seems like it might be possible for us to work together in some interesting ways.
We already have charms for Rack, node.js, Django, etc. already working and we can replicate the example in the video, just on raw LXC, EC2, and OpenStack. And we’ve put a lot of time and energy into managing the relationships between services, which is the big complicated part of a PaaS So, there seems to be pretty good overlap.
Have you looked at Juju? Perhaps there are places where you can leverage the heavy lifting that the juju team has already done in creating a “bring your own” kind of PaaS.
I could be completely wrong, mind you.
Using the database doesn't impose any restrictions on your software.
Even hacking on juju to add API'S you for your client software doesn't impose restrictions on the client -- it just means you are subject to the AGPL licence source distribution rules on the patched version of Juju.
I do not believe that _running_ your software on top of AGPL-licensed Juju makes one iota of difference.
The App Store is different: the restrictions the App store adds are at odds with GPL's defined freedoms. Not the same issue here.
I'd also be happy to talk more about this any time.
OpDemand will be releasing a very similar open-source project called Deis in the next few weeks. It's an open-source PaaS powered by Docker & Chef, with a Heroku-inspired workflow.
We're busy ironing out a few final issues, putting together documentation, quick-start guides, tutorials, etc.. but we are very close to launching our public 0.1.0, which will allow you to deploy your own private PaaS providing you complete control over hosting, backends, proxies and more.
Re: Puppet -- A good chunk of the "orchestration" is done by updating data bags on a Chef Server, and force-converging Chef nodes over SSH. However I know Puppet has similar constructs, so it's definitely possible to fork the Deis controller and Puppetize it. We'd encourage that sort of contribution.
Seems like this would be an issue for the host-only (private) network?
Docker 1.0 will include an API which will make it much easier to customize how you want networking to happen. That includes static IPs and private networks.
Note that the 1.0 API will also include hooks for service discovery - specifically to facilitate the development of projects like Flynn.
Another option could be to use Go DNS  to integrate a DNS server directly into the cluster. This would allow the DNS records to immediately reflect the state of the cluster, using SRV records to map directly to the dynamically allocated hosts + ports. DNS resolver caching would have to be carefully managed though.
I have no idea whether there any plans to implement a naming service on top of Flynn.
Adding this to Docker would be a nice way to allow new machines to be created but to keep the same IP with automatic switchover.
The dirty little secret of PaaS is that there is not, and will never be a single PaaS that fits everyone's needs. With docker we offer a foundation for many PaaSes to engage in a healthy competition while preserving interoperability.
So Shopify will always be free to mix and match Flynn's lego bricks with the bricks of other offerings - because they are all Docker-compatible. The authors of Flynn get that, which is why I believe their product will be good and I will be personally sponsoring it :)
Much respect for DotCloud's success thusfar btw.
People who value a little extra effort at startup as being a cost that is more than $200/month over the life of their use of dotCloud.
There's a lot of cases where that could be true, especially if the extra effort and moving to a different platform is deferred, rather than permanent. There are many times where doing something now (that isn't necessary for immediate goals, but is useful for long-term savings) has greater opportunity costs than doing it later. (Lots of times when the reverse is true, as well.)
You see where I'm trying to go with that?
If I compared to DigitalOcean instead, then DotCloud would look even worse -- about 10x more expensive.
I'm not complaining that an alternative to Cloud Foundry is going to exist, but I'm still a bit surprised.
GitHub did not create Git, nor is their code open source.
This supposed competitive advantage that they would have would mean nothing if they still had to work on top of other IaaS-providers. They would be undercut by the IaaS themselves. By changing the game, they get another angle to work from.
One question though, what is going to be 'the cluster' (The site says it distributes work across 'the cluster')? Basically, will it be capable of interfacing with cloud API's or will it just be you manually setting up a group of instances to host the machines to run Docker on top of?
Never got in to Cloud Foundry because it's overly complex and very limiting. Always went with Heroku, but wished I could have a Heroku-style infrastructure on the above mentioned VPS providers for the benefits of running better hardware, being more affordable, being multi-region, etc, etc.
Digital Ocean: http://kencochrane.net/blog/2013/06/running-docker-on-digita...
Linode: http://stinemat.es (site seems to be down at the moment)
Don't see Linode listed there, but between that or Jclouds (http://jclouds.incubator.apache.org/documentation/reference/...) you have like a billion cloud API's available to you. I imagine teaming one/both would make Flynn a very interesting alternative to Cloud Foundry/etc.
I wonder if there is anyone here who works on CloudFoundry or OpenShift and could comment on this, or comment on the proposed capabilities of Flynn (https://github.com/flynn/flynn-spec) compared to the capabilities of their systems.
They actually don't use LXC though and implement resource control with Cgroups. That said, Cloud Foundry is extremely difficult to get setup and running in my experience (even with the v2.0 recently released). It sounds like one big differentiating factor is that Flynn would have fewer moving pieces (Cloud Foundry is at least: BOSH, Warden, VCAP?, CF itself, etc.).
CF is actually very plugable as well - there is a well defined internal API, which you could just add components that listens/publishes to - however, I don't think its encouraged, neither have I seen a single example of it.
They may even share code in the end, but Dokku will remain focused on simple, single host deployments. Flynn is about a real, distributed system that could be used in production.
Since Flynn is really just a packaged collection of components (similar to Dokku), Dokku may just end up being a single host version of Flynn someday.
Ultimately, it seems, heroku will need to find an additional axis (besides ease of use) to differentiate on. Maybe I'm wrong, though. Apple sure has been able to turn ease of use into a sustainable competitive advantage. In heroku's case, though, there are fewer UI decisions and its audience is super-technical, so I'd be surprised if ease of use alone is sustainable in this domain.
We'll see. I want to see them win, to be honest, because I feel like they've done so much good in a providing such an accessible and (at first at least) cheap way for a developer to get his or her stuff out there.
The idea is that you can turn on and off web servers really quickly to do tests and also that it should scale as the amount of work that your web application needs scales.
I'd be happy to contribute at a lower level (at least $100, possibly up to $500) as I do see the value in this.
Dokku is more than sufficient for my needs at the moment, but see Flynn as a natural extension to that.
We'll start accepting personal contributions next week as well.
I wonder if using Heroku buildpacks is a good idea, though. Something that can more fully take advantage of Docker layers, and in some cases APT packages for language runtimes, would be better IMO.
That way, you get a nice out-of-box experience (push your code, something magic happens), and when you need more control over your build and dependencies, you can add a Dockerfile.
I'm hoping this is what Flynn will do :)
Lots of uncomitted changs locally. With this announcement, not sure if its worth continuing down this path.
It almost feels as tho Flynn (or maybe something build on top of Flynn) could/should be a whole minimal linux distribution (SmartOS-ish) that could just boot up into RAM, be told to read a cluster config from somewhere and then start working for the cluster accepting Docker services.
I'd love to use docker or something similar for .NET applications.
I can't help but think that this won't really work for many Microsoft shops because the Microsoft CLI is very different from the Mono CLI.
The reason I ask is that there's a number of providers of private PaaS solutions that are willing to install their stuff in your organization for Microsoft stack(HP Matrix, I'm looking at you), but they are full of holes and aren't nearly as robust as what Docker/Dokku/Flynn can offer in terms of plugability and modularity.
Also, free is a pretty good price.
Regarding the product funding remark, that's not the intention, though with the license anybody could build a product with this project. I'm not convinced that's a bad thing.
Just in case someone is too lazy to look it up himself: He's not alone and teamed up with Jeff Lindsay.