"open source"
(Yes, I understand this might be "open source" for some definition of "open" but it is now what we talk about when we mean open source, and I think that holds true both for MIT/BSD/ASL loves such as myself as well as for the (A|L)GPL crowd.
It seems some of this is actually opensource.
If you look at flogo-cli or one of the other linked projects, the license appears to grant more rights. It looks like it's in the BSD-style but I can't be bothered to scroll the long lines to read the whole thing.
Parent is pointing out that the license lacks some provisions commonly required to be considered "open source" -- a better term for what is presented might be "disclosed source" or "visible source."
Defining open source can be a point of contention, but the license in question is pretty far away from most accepted definitions. There's not even a right to modify the code. Note that this license appears to be only on the base project that seems to contain nothing beyond documentation and samples.
I'm the PM on Project Flogo and welcome your questions + feedback. As some have noted on the interweb, it's a pretty big step for an enterprise sw vendor like us, to open up a core piece of our technology, so your constructive feedback gets a lot of attention around here and shapes it!
Couple of quick clarifications:
- All the repos (CLI, Library, Contrib and Services) except the top-level repo are BSD-licensed. The top-level repo is docs+samples, so we have put it under a free-beer license. However, we are in principle open to putting it out under BSD or a CC license as well.
- At its core, Flogo is a process engine that executes flow definitions consisting of activities. These flows are triggered by events happening in the real world. Triggers could be HTTP, MQTT, CoAP, etc. & activities could be AWS IoT, Log, HTTP, Send MQTT, etc. There is a fairly simple SDK to build your own activity or trigger and bring those along.
- We are actively working on a Web UI to model the flows instead of handcrafting the json DSLs or writing code.
- The runtime footprint comparison is for apps with equivalent functionality (Think a flow like MQTT Trigger -> Log Message -> HTTP Request -> Send MQTT). We just chose 2 common frameworks to showcase the difference in runtime footprint. We love Node & Java - it's just that for Edge integration microservices we chose Golang - and the runtime footprint was a key decision factor among others.
"Build IoT applications that run on edge devices..."
The moment I see "runs on Raspberry Pi", I know they haven't done any thinking about low cost or low power consumption edge nodes. Get back to me when it can run on a CortexM0 with 128KiB of flash.
(Disclaimer: TIBCO PM working on Project Flogo)
Isn't it like some basic http api for "triggers"? Is this what people think IoT is about?
More importantly, can these basic set ups make money for some?
I'm of the opinion that these frameworks for Gateway devices are reinventing Unix pipe and cron, that integrations for devices and databases should be written in any language (as CLI), and running logic on the gateway is 90% of the time not what you want to do, you just want to pull data from a device and push it to a database somewhere. Shameless plug, in my free time I work on Open Pipe Kit, a project that is building CLI for devices and databases. We're currently working on a series of DIY LORA Nodes for Agriculture. If anyone is interested in lending a hand, please reach out. http://openpipekit.github.io
If you are looking to monetize connectivity services, you certainly will need a bi-directional architecture to push values back to end nodes, and compute resources available at the gateway for data filtering, preprocessing, and security.
But these are tasks that AWS IoT, Azure IoT, and GCP IoT are currently tackling with a lot of resources. So it would be hard to compete at that level.
The one thing I would like to add is that flogo-lib is a full-fledged process engine which means you can craft (or soon enough visually model!) rather expressive flow definitions unlike a request-reply pipeline or HTTP middleware.
(Disclaimer: I'm a PM working on Project Flogo at TIBCO)
IoT devices identifying themselves (authentication) is only a tiny sliver of the security picture. You also need to worry about authorization, encryption, and (security) monitoring.
One really annoying security problem with IoT devices right now is SSL/TLS's complete fundamental incompatibility with the concept of "roaming". Want to connect to your device via SSL/TLS? Better get used to ignoring warnings about the certificate name not matching the device's IP/hostname.
Flogo's problem domain is broadly speaking, IoT integration. Using Flogo you can build integration apps/services/microservices that are lightweight enough to run dozens of these edge apps on IoT edge gateways & devices. Specifically, these edge integration services can be built as flows & triggers (yes, a visual flow modeler is coming soon!). Hope that clarifies - but we'll take your feedback to improve the docs.
(Disclaimer: I'm a TIBCO PM working on Project Flogo)
And on each of the other projects linked from the TIBCOSoftware/flogo README
Now, we will likely end up doing a whole lot less functionality on an M0 profile, compared to a typical Flogo flow app on an IoT gateway, but the idea is to offload the right level & kind of edge compute onto lower power nodes.
One point worth mentioning is that pretty much any framework can run on a Pi, but running dozens of these Edge apps - "12-factor" style[1], that is where Flogo's advantage shines through.
It's kind of like HTTPS. nobody can snoop on you, but it's more about stopping malicious actors from lifting your identity. And making sure you are connected to the true requested server.