5 ms·
Project Flogo – Open Source Framework for IoT Integration
- mdani 10y agoGoogle Brillo and Weave are essentially providing the same functions for Google's evosystem for IoT which connects to Google Cloud Platform. How does Flogo compare with Brillo + Weave?
- zok3102 10y agoWe havent seen a whole lot of real world demand yet, but something that could likely end as a trigger or activity in Flogo.
- craigcabrey 10y ago>Internal Use Only License Grant. TIBCO hereby grants you a limited, non‐transferable, non‐exclusive license to use the software solely for your internal business purposes. "open source"
- jlgaddis 10y agoopen source != free software
- craigcabrey 10y agoYou're absolutely right, of course. But I never implied it was. I highly doubt this would be an OSI approved license. https://opensource.org/faq#unlisted-licenses https://opensource.org/faq#unlisted-licenses
- no_protocol 10y agoPedants would probably agree that this is a true statement, but it is also not relevant. The project itself claims it is open source and the parent claims it isn't. No one mentioned the free software movement. 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.
- no_protocol 10y agoI want to point out that this license applies only to the base project, which only contains some documentation and samples. 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.
- reitanqild 10y agoWhere is that license?
- no_protocol 10y agohttps://github.com/TIBCOSoftware/flogo-cli/blob/master/TIBCO%20LICENSE.txt https://github.com/TIBCOSoftware/flogo-cli/blob/master/TIBCO... And on each of the other projects linked from the TIBCOSoftware/flogo README
- deleted 10y ago[deleted]
- reitanqild 10y agoSeconded. Don't let them advertise it as open source when it is just shareware with readable 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.
- reitanqild 10y agoSee also no_protocol s link: https://news.ycombinator.com/item?id=12643676 https://news.ycombinator.com/item?id=12643676 It seems some of this is actually opensource.
- mrtree 10y agoI have been doing "IoT" for 10 years and after checking the website and the github repo I still have no clue about what flogo does. 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?
- cobookman 10y agoAgreed. It also doesn't solve the biggest it challenge which is giving each thing a unique identity and a means to prove its identity. I find that real-time event processing had been solved already through dataflow and Apache Beam. Along with generic pub sub systems.
- riskable 10y agoNo, the biggest challenge in IoT right now is security and in that same vein, updates. 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.
- cobookman 10y agoIdentity and encryption are tied hand in hand. It's about knowing where all the iot data is coming from, and knowing it wasn't spoofed. 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.
- salex89 10y agoHear, hear! I can only see it being compared with dropwizard which is "only" a REST framework for Java. What's the problem this is solving?
- PinguTS 10y agoIt should be an IoT integration framework, which has 3,3 MB. That sound huge to me. If I have an embedded processor that has 1 MB of Flash, than that is already huge. Still this has to fit my application besides that framework.
- betimsl 10y agoInitially I thought the same, but looks like it's only a web application, not the software you'd ship with the node.
- joezydeco 10y agoI'm not so sure. "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.
- zok3102 10y agoGood point - yes, we have M0-3 class target platforms on our roadmap. IoT Gateway devices was where the need was most pressing for our customers and we just went there first. 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. [1] https://12factor.net/processes https://12factor.net/processes
- Dowwie 10y agoA Tibco project?! What the.
- zok3102 10y agolol. This goes up on my review deck with execs. But yes, a (new) TIBCO & a new TIBCO project :) (Disclaimer: TIBCO PM working on Project Flogo)
- zok3102 10y ago12 hours off HN & your project gets posted! Phew :) 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.