Anything's possible. I know, I know, you just rolled your eyes, but hear me out.
The key here is to not think of the vendors' ability or non-ability to work directly with GeoEvent. Unless the vendor, or an otherwise interested party, creates the GeoEvent connectors, it's impossible for the Esri GeoEvent team to make and maintain a connector for every possible vendor - it's just not a realistic development and maintenance feasibility.
So then what's the key? The key is to find out lower level details about these vendors' APIs and data formats. How does a developer or integrator communicate with the vendors' products/APIs - HTTP? TCP? Web socket? UDP? What is the format of the actual data? Comma-separated fields? Tab-separated fields? XML? JSON?
GeoEvent ships with native support for a bunch of industry standard transport mechanisms (HTTP, TCP, UDP, Web socket, etc) as well as native support for a a bunch of data formats (CSV, JSON, etc). If a vendor's connector doesn't exist natively (which is most likely the case), but you find out their API is REST-based and returns tab-separated data, then you could "marry-up" the HTTP transport with the Text adapter and make a new GeoEvent connector with no development required.
There are possibilities to integrate vendors' products APIs with GeoEvent, but I won't go into it here. Anybody interested in hearing more can contact me if desired.
I hope this helps clarify some things.
Mark Bramer
