pfSense

I suspect this will be heavily debated but please read my idea before dismissing it.

One of the reasons products like Unifi are so popular is the SPoG. For network admins, SPoG can be a huge value add. I realize it sounds complex, but it actually wouldn't take a huge lift to add capabilities to pfSense to allow it to control 3rd party network devices like access points. The things that need to happen already happen, it's just a matter of exposing the capability.

The enhancements needed to pfSense:

1. pfSense would document a schema for describing network configuration change. When you add a VLAN, or configure a wireless network, that is a network change that can be described using some schema. Example below. pfSense already has some mechanism for making changes -- the idea is to expose the change using a schema that describes the change in a standard way that a network device can consume.
2. pfSense would add a configuration page where user's would specify the IP of their network device such as an AP
3. pfSense would expose some APIs that network devices would call to interact with pfSense such as reporting back status, metrics, data, etc...
4. optionally pfSense would add some polling mechanism that could/would make API calls to the network device to pull back status, metrics, data, etc... For this to work, pfSense would document some standard APIs that they can consume.

Example schema for describing a network configuration change:

{
  "action": "new VLAN",
  "name": "VL10",
  "id": 10,
  "...": "..." 
}

Once this is done, manufacturers would make enhancements on their side. They want pfSense's HUGE user-base to buy/use their network product (AP, switch, etc...) so they have a vested interest in making updates to their device to leverage these pfSense features.

1. When a user makes a change in pfSense, the network device they registered using #2 above would consume the network configuration change and act accordingly. If, for example, a user made the example change in/from pfSense, then pfSense would submit a GET/POST request to the network device with that JSON payload and the network device would consume it and act accordingly.
2. #3 or #4 would allow pfSense to show status of the network device right from pfSense.

A lot of the smaller network devices would readily support this because it would put their products front-and-center to pfSense users who want SPoG.

I don't support breaking the law but if a user was to reverse engineer the communication for products like Unifi then they could easily create a translation layer (a plugin) that would take the network configuration payload from pfSense, translate to what Unifi understands, and send to the unifi device. I mean, Unifi already does this today.