Monkeynoodle.Org

I’m pretty fascinated by the effect of social code matching in product design. In order to market and sell products you have to fit them to the buyer: language, use cases, pricing, packaging, sales motion, and more. In large and small ways, a company’s go to market or an open source project’s landing page tells you who it is intended for. The underlying technology may be exactly the same between two products that are aimed at completely different buyers, which is how organizations end up with their hosts, images, and laptops larded down with duplicated technology stacks.

Let’s take the concept of botnet-for-good systems management as an example. The basic tech needs are visibility, control, and file movement. There’s a small handful of reasonable answers for each of those needs.

• Visibility:
  • The endpoints push a stack of data points to a central store
  • The endpoints are polled for a stack of data points by the central store
  • The central store is a horizontally scaling cloud
  • The central store is a vertically scaling hierarchical stack
• Control:
  • The administrator can extend with script (either native to the platform, or an open language)
  • The administrator is constrained to what the tool developer offers (possibly a library of functions and a Domain Specific Language (DSL), or just a set of prebaked commands)
  • The administrator distributes individual control actions, perhaps in logic-grouped bundles
  • The administrator distributes policies and the endpoints independently resolve what to do
• File movement:
  • File shards are delivered from central (read cloud or perhaps Content Delivery Network (CDN)) storage
  • File shards are delivered from peer endpoints (read proprietary protocols similar to BitTorrent, but with more controls)

And there’s dozens of companies and open source projects delivering the same conceptual tech stack with different clothing. This list is by no means complete: Microsoft Config Manager (FKA ECM, FKA SCCM, FKA SMS), IBM/RedHat Ansible, Cybereason, Ivanti (FKA LANDesk and Shavlik, two products with botnet capabilities), Puppet, SentinelOne, HCL BigFix (FKA TEM), Progress Chef, Tanium, Crowdstrike, Tenable, Trellix (FKA McAfee and FKA FireEye), ninjaOne.

Here’s a possibly surprising one: Splunk Deployment Server. It fulfills all three of the needs, but it isn’t positioned as a product to buy. Its sole purpose is to ensure that the on-premise Splunk Enterprise administrator does not have to speak to the people who manage systems more than is absolutely necessary. Once the initial agentry is deployed, Splunk DS means the Splunk admin has their own botnet for good infrastructure and does not have to ask for help when changing configuration or upgrading components. Similarly, many of the companies I listed above use their powers for themselves and do not advertise that they could be used for deploying patches or third party software. This is a marketing decision made by the vendor. Once they’re operating a root shell with a file transfer agent, that agent can install whatever it’s told to. Their use of the technology is solving a problem for their customer, but that problem isn’t the reason that the customer bought the software, so the technology is a hidden feature.

But if you’re investing cash and time into Chef or Ansible, their Job To Be Done is control first, visibility second. Buying an endpoint manager? They sell visibility and control. Buying a vulnerability and compliance scanner? They sell visibility, and hide their ability to control. (It is continually hilarious to me that Qualys labels their ticket-opening feature “remediation”.)

Here’s another exception that proves the rule: Take some combination of Osquery, Rapid7 Velociraptor, Influx Telegraf, and/or OTel for visibility, maybe add Fluent-bit or TD-Agent-bit to move the data… you’ve got a visibility-only stack that’s mainly aimed at cloud customers doing centralized container image development, servers-as-cattle. Control and file movement are probably handled by Infrastructure-as-Code (IaC) products driving an Infrastructure-as-a-Service (IaaS) vendor stack or your own Kubernetes. And yet, you can easily add FleetDM, Calyptia, Saltstack, or any of the products from my first list. You could use many of those for file transfer, or just curl to grab files from the cloud. Now you’ve got a full management stack for servers-as-pets or edge devices (albeit a janky Frankenstein of a stack).

Want a single vendor solution that’s aimed at Macs? Cool, there’s jamf Pro (FKA JAMF Casper) and Kandji. Maybe you’re all-in on mobile device operating systems? The MDM category is right there (and notably, many of the vendors I mentioned have plugins for this tech stack).

So, vendors build out the same stack of technical abilities… emphasize or hide parts of it from customer view, and then aim their product pitch to buyers from ops, compliance, and security on platforms of cloud, data center, or edge. Any one of these vendors could theoretically compete with any or all of the others.

Taking on a competitor from a different vertical focused on a different platform is harder than it sounds though. They would need to learn how to talk to the buyers, what language will resonate, what features are important. Those features might conflict with others as well. For instance, I’m sure that Qualys’s “remediation” feature is doing exactly what the compliance buyer wants, because Enterprise Roshambo dictates that compliance cannot drive uncoordinated patching. If they were to launch a patching product, they would need to sell it to the operations team instead of their current buyers. If they launched an EDR, they would need to sell it to the security team instead of their current buyers. Sometimes that kind of pivot is necessary, such as adding cloud to your data center pitch; but without hard necessity, vendors are unlikely to successfully pivot for opportunity alone.