Is developer led, the best strategy for the adoption of security tools?

We run a periodic newsletter with additional commentary and news about upcoming events and open-source projects. Subscribe here.

With my newfound passion to root out security myths and look for facts based on data, lots of things are catching my eye. This tweet, shared this morning by David Rook, Director of Security at Riot Games was one such thing.

It shows that Microsoft now has a staggering 180 million daily active users compared to Slacks 20 million. There are clearly different demographics in their respective user bases. Slack tends to be used in tech companies, and is often adopted online by communities. Said another way, Slack grew from bottoms up online customer acquisition, before it later ramped up a top down sales force to maximize revenue in the enterprise. That approach is tried, tested and loved by investors because of the low cost of customer acquisition, no expensive sales people, and fast time to revenue, bypassing procurement teams. 

Conversely Microsoft Teams, despite my understanding of its consumer roots from Skype, is mainly a big corporation tool. I have never seen a developer community use Teams or had a person that does not work for a big corporation set up a meeting with it. With 180 million users I am sure loads of them exist, it does have a free tier. I think it's fair to assume that its growth and adoption is almost certainly as a result of tight integration with the Microsoft ecosystem and attaching it to ELA’s or Enterprise License Agreements. Platform and top down sales. 

Taking a step back, if the goal of a DevSecOps leader in a large corporation is to get security tools used by as many developers as possible, it makes you wonder if the current trend of developer led adoption is the most effective. Based on the radically different active users of Slack and Teams, and the hockey stick growth curve, maybe pushing them down from the top is actually better than waiting to find developer champions and natural growth. Sure, developers have much more autonomy in selecting their own tooling versus IT controlled infrastructure tools but with centralized shared developer services in big companies, that's not always true. People using corporate communications tools probably put up and shut up, whereas developers have stronger opinions and are more likely to voice them, but if the differential between DevSecOps tools is anywhere near proportional, then this is a significant data point to consider if you are a DevSecOps leader in a big corporation. 

It may well be that bucking the trend and going old school is more effective. More friction but a better long term result. Microsoft pushing CodeQL down, via Github, via Microsoft ELASs, may well result in a security equivalent graph like the one above. It will be interesting to see.