Prometheus developer here.<p>&gt; More development resources?<p>Not directly. I expect the gains to be around the legal and organisational stuff you need as a project grows (e.g. trademark registration, formal governance), as well as publicity.<p>&gt; I suppose it at least to some extent allays whatever fears there might have been that it will go &quot;open core&quot; in some ways, as e.g. InfluxDB recently..<p>That was never really a risk, as Prometheus has never been a commercial effort controlled by any one company.<p>&gt; That being said, what is the killer feature here?<p>Prometheus is perfect for monitoring any sort of operational timeseries, and is designed to do so in a way that scales both technically and organisationally.<p>For example collectd is an on-host daemon that you have one of per machine. That may work when you&#x27;re small, but with many services that will become a bottleneck as each need to be added and stragglers may become an issue (Twitter seem to have hit this, see &quot;Lessons Learned&quot; <a href="https:&#x2F;&#x2F;blog.twitter.com&#x2F;2016&#x2F;observability-at-twitter-technical-overview-part-ii" rel="nofollow">https:&#x2F;&#x2F;blog.twitter.com&#x2F;2016&#x2F;observability-at-twitter-techn...</a>). The Prometheus approach of one exporter per target scales far better.<p>For another example if two different teams (say infra and database) have two different views of the world, with a collectd approach then the infra team likely wins. With Prometheus monitoring can be decentralised so infra can view a machine as mach1{rack=&quot;ch&quot;,datacenter=&quot;ma&quot;} and database as mach1{owner=&quot;app2&quot;,env=&quot;canary&quot;} each in their own Prometheus server. This gives teams more control by decentralising monitoring.