A little bit more in this video: https://vimeo.com/cbase/noflo
(also, see http://bergie.iki.fi/blog/noflo-two-years/)
A little bit more in this video: https://vimeo.com/cbase/noflo
(also, see http://bergie.iki.fi/blog/noflo-two-years/)
I might have a use case for a flow UI - not FBP, but a niche of an application that might be best suited to be administered with precisely this kind of flow UI. Pretty soon, I will have to make a decision on what to use there. NoFlo looks like a very strong contender, but I've had a couple of them, even with mature codebases, that turned out to be nice in theory, but not usable in practice.
But I have to admit, I wished we had the UI every step of this project!
What I'm getting at is this: A good, reusable component-graph interface is a very strong pull for all those people who care about that part without being particularly interested in the server behind it. It could make your kickstarter that much more effective to make it clear that it's about making it simple to write your own engine implementation.
Screw your stretch goals* - the 250k level should be you providing a good-as-apple-pie API/documentation/support that others can write implementations for/with. Instead making it about particular implementations - Android, iOS, Python - smells a little like marketing speak. If you really believe in FBD, all you have to do is make it very simple for people to pick up the threads. You'd have tons of implementations in no time.
*Also: I don't get the stretch goals in general. I get what you try to achieve with them, but you need to look at them form a programmers perspective: What if I'm a Python programmer who wants NoFlow? Do I have to call all the people I know who care about Android or iOS so I can get to my $1M level? That's not going to happen. Likewise, Android devs won't really care about pushing it further once their level is achieved, likewise for iOS. It's a bit confusing.