> It's also important to note that while FIX frontend is open source, it utilizes commercial Material UI components. As such, to use it, you'd need your own Material UI license.
That is an odd choice for an open-source project. I'm curious to know what Material UI provided that any other open-source UI library did not.
The reasoning is explained in the very section of our Github org README you quoted this sentence from. Our main open source project is Fix Inventory (https://github.com/someengineering/fixinventory) and that is very well documented (https://inventory.fix.security) and uses no commercial 3rd party libraries.
The Fix SaaS frontend that you're referring to and that you find at https://fix.security builds upon Fix Inventory. We could have just made it closed-source like every other SaaS (think Grafana Cloud). But because I'm a big proponent of OSS we decided to open source our entire SaaS stack, frontend, backend as well as all internal tooling. The main intend here is transparency, not so you spin up your own SaaS environment.
Essentially we develop the SaaS for ourselves first and foremost, but saw no reason to make it closed source. So that is why it might be using any number of commercial 3rd party add-ons.
> I'm curious to know what Material UI provided that any other open-source UI library did not.
I believe it was some MUI X table features like multi row sorting that we didn't feel like re-implementing. I'm sure there's other open source libs that would do that, but we've settled on MUI and are not going to start mixing different UI libraries for different visual elements if we don't absolutely have to.
I also removed the old lambda based callback template from the repo. We're now using an SNS topic as part of a CustomFunction, to know when a user has deployed the stack (https://github.com/someengineering/fix-cf/blob/main/fix-role...). More work on our side, but less sketchy than executing code just to receive a callback that tells us the role name and account id.
We're currently working on Azure, but it's not stable enough to be listed here.
> > AWS, Google Cloud, DigitalOcean, VMWare Vsphere, OneLogin, and Slack
> kind of a weird mix of control planes
:D agreed. Two of these things are not like the others. There are also Github, Posthog and Scarf plugins.
To explain, Fix Inventory doesn't care about Cloud resources per se. It can create an inventory of whatever kind of resources. fixcore maintains a large graph of resources and makes them searchable. fixworker runs collector plugins and ships their results to the core. In theory you could build a plugin that monitors the sensors of your farm's greenhouses and run automations and reporting on them.
Slack for instance is there because when you want to notify a user on Slack it makes it convenient to lookup their internal Slack ID based on e.g. their Email address.
So you might do lookups like: AWS resource tag -> OneLogin User -> Email -> Slack UID.
That is an odd choice for an open-source project. I'm curious to know what Material UI provided that any other open-source UI library did not.
The Fix SaaS frontend that you're referring to and that you find at https://fix.security builds upon Fix Inventory. We could have just made it closed-source like every other SaaS (think Grafana Cloud). But because I'm a big proponent of OSS we decided to open source our entire SaaS stack, frontend, backend as well as all internal tooling. The main intend here is transparency, not so you spin up your own SaaS environment.
Essentially we develop the SaaS for ourselves first and foremost, but saw no reason to make it closed source. So that is why it might be using any number of commercial 3rd party add-ons.
> I'm curious to know what Material UI provided that any other open-source UI library did not.
I believe it was some MUI X table features like multi row sorting that we didn't feel like re-implementing. I'm sure there's other open source libs that would do that, but we've settled on MUI and are not going to start mixing different UI libraries for different visual elements if we don't absolutely have to.
I also removed the old lambda based callback template from the repo. We're now using an SNS topic as part of a CustomFunction, to know when a user has deployed the stack (https://github.com/someengineering/fix-cf/blob/main/fix-role...). More work on our side, but less sketchy than executing code just to receive a callback that tells us the role name and account id.
;-)
but, in seriousness
> Currently, Fix Inventory can collect AWS, Google Cloud, DigitalOcean, VMWare Vsphere, OneLogin, and Slack resources
That's kind of a weird mix of control planes, and it seems that Azure is actually present, just just not listed in the readme: https://github.com/someengineering/fixinventory/tree/4.0.1/p...
(AGPLv3 for those interested in such things)
> > AWS, Google Cloud, DigitalOcean, VMWare Vsphere, OneLogin, and Slack > kind of a weird mix of control planes
:D agreed. Two of these things are not like the others. There are also Github, Posthog and Scarf plugins.
To explain, Fix Inventory doesn't care about Cloud resources per se. It can create an inventory of whatever kind of resources. fixcore maintains a large graph of resources and makes them searchable. fixworker runs collector plugins and ships their results to the core. In theory you could build a plugin that monitors the sensors of your farm's greenhouses and run automations and reporting on them.
Slack for instance is there because when you want to notify a user on Slack it makes it convenient to lookup their internal Slack ID based on e.g. their Email address. So you might do lookups like: AWS resource tag -> OneLogin User -> Email -> Slack UID.