3 ms·
Thanks for the great question. I'm the CEO & co-founder of Flynn. tldr: we're open to making Flynn a foundation/community project if we could find the right ki
by danielsiders 10y ago
Thanks for the great question. I'm the CEO & co-founder of Flynn.
tldr: we're open to making Flynn a foundation/community project if we could find the right kinds of partners and once the core innovation is complete.
This is something we've thought a lot about over the past few years. Everyone on our team is a hardcore open source believer and contributor and the long term success and sustainability of open source projects and Flynn in particular are something we care deeply about.
When we started working on Flynn (with just a crowdfunding page posted to HN) we had no intentions of commercializing it. Before asking HN to fund the project we reached out the founders of many growing startups (many of which are now unicorns) who we saw as the core users. Our goal was to agree on an architecture and set of APIs, then have each company "own" one component of Flynn, with one engineer at each working on their component full time.
Everyone we talked to said they loved the idea of an open source Heroku that could run anything (not just 12 factor apps) and run anywhere from AWS to their own colos and datacenters, but none had the staff to spare on infrastructure engineering (which is why everyone wanted a PaaS in the first place). Several, like Shopify, contributed to Flynn financially so we could hire a dedicated team to build Flynn for everyone.
So a community/industry collaboration was absolutely our goal from the start, but several things made us question that route. Not only were our first choices for collaborators and partners unable to participate directly, but we spent a lot of time talking to companies in the then-thriving OpenStack community as well as other foundation/industry run infrastructure projects. They shared a number of horror stories of how the most promising new features and capabilities were killed by cross-vendor compatibility concerns and how specs were limited by legacy vendors on committees.
Committees and bureaucracies are great at keeping something alive and maintaining the status quo, but not at innovation.
We also met executives from very large companies in regulated sectors like banking and telecommunications. They were extremely excited about Flynn but had a completely different set of requirements than the younger companies like startups whose needs we knew best, and had experienced ourselves. It was clear that we would have to build a very different project to serve the largest of enterprise customers. Crucially, foundations/industry collaborations on infrastructure attract the largest of vendors who have these mega-companies in their sights as the real customers.
If you want to see what a PaaS built to their (imagined) needs are, look at CloudFoundry built by Pivotal, which is currently owned in part by Dell/EMC, VMWare, GE, Microsoft, Ford or at OpenShift, which was built as a startup but acquired and retooled by RedHat.
While we think Flynn has a lot to offer today and in the future to these large institutional users, they have not been our focus.
Flynn today has the minimum feature set we consider necessary to be useful. Looking towards the future we want it to encompass a lot more. We'll be publishing a comprehensive roadmap/master plan soon, but most of that innovation would be harder or impossible to accomplish if we were locked into a foundation today. Development would be slower, changes would have to work their way through approval to consensus, and many partners would object to new features competing with their own established products.
We've been very careful both to limit external dependencies and to provide end-to-end integration between all our components. As a result we're able to move very quickly when changing APIs, implementation details, even major pieces of architecture, all without impacting customers. This gives us the freedom to stay nimble in a changing landscape, but partners might be more attached to technologies in which they already had a large institutional investment.
Infrastructure companies today are already a world apart from where things were in 2008 when Heroku upended PaaS. The default is now open source, making lock-in (historically the bigger concern) far rarer. There are few companies among our peers battling to become the next Oracle.
Additionally there's a tremendous amount of portability both among unified PaaS's and build-your-own infrastructure because of technologies like buildpacks and containers. As a result most apps that run well on one platform can be moved to another. There are of course features, like Flynn's database appliances, that are not available on most others.
We've made other choices like a small codebase with few external dependencies that make managing Flynn's development and maintenance easier, whether it's our team or yours doing that maintenance.
That being said, we're entirely committed to Flynn's future personally. While we'd love to see it become a huge company, that's not necessary for us personally. We're a team of five, and speaking for at least my cofounder any myself, we're not going anywhere, regardless of the VC market.
We work on Flynn (for several years and many long hours now) because we believe it needs to exist in the world, not because we think it'll make us rich. We're committed to keeping Flynn alive as long as that stays true (basically until it becomes unnecessary or there's something else that does everything we want but better). Since our 1.0 launch we've had huge growth and adoption and are currently fundraising. We're single digit new customers away from default alive with the current team. Whether we become a small, sustainable company to selling to/partnering with a large enterprise vendor, to creating a foundation, everyone on the team is 100% committed to a permanent, sustainable future for the product, with or without venture capital, unicorns, or IPOs.
- duncanawoods 10y agoThank you for the detailed response - much appreciated. You have tempted me to look into Flynn further. The headline feature that attracts me is HA postgresql - that has instant relevance. My greatest concern is stability - I'm not seeing many success stories but lots of problems. I want to hear that Flynn is "the one bit of my stack I don't have to worry about". I hope you can publish some case-studies (both successes and post-mortems) including discussion of the attempted architectures. A fundamental philosophical worry I have is that it is a "wrapper tech". I increasingly stay away from these - the promise is that they make the underlying tech easier/quicker to use but they make assumptions that don't hold for you in the long-term, they serve too many unrelated use cases so become bloated and poorly fitted to your own needs and they reduce the features, flexibility and stability of the tech they wrap. The cost in fixing & working-around the wrapper can quickly exceed the cost/value of building your own glue based on the underlying tech because it also gives you a greater depth of knowledge in the fundamentals and more power.