statsd-imho.txt

* etsy/statsd is the official statsd implementation, yet hasn't been maintained for more than 2 years.
  (see also https://github.com/etsy/statsd/issues/649) 
* dozens of forks and re-implementations exist in the community.
  usually they bring one or more of extra features (e.g. graphite tags, security, ...),
  easier deployment and better performance,
  with various degrees of backwards compatibility

Which implementation is "best" depends on many factors, but often enough, it's not the official reference implementation.
IMHO, most of a statsd server's responsibility is catering to an organisations need of how they organize/name/.. their metrics.
So any implementation is very opinionated, and for etsy/statsd trying to cater to many different styles leads to a ballooning complexity 
(e.g. different namespace and prefix configuration methods)
Some competition or different flavours is not intrinsically a bad thing,
but the landscape has gotten overwhelming and confusing because there is no starting point in the decision tree.
(meaning, someone new to the ecosystem doesn't know where to start). And often the official implementation is not the most suitable one.
(you can draw parrallels to graphite for which several re-implementations of some of the components exist,
but this is more complicated and out of scope for this discusion)
while statsd (the official and some of its alternatives) support various backends, it undeniably is designed for,
works best with, and is almost always used in conjunction with graphite
thus, I think it would be a good thing for the graphite project to either:
B) at the very least steer people towards a recommended implementation that is being well maintained and
   aligned with the graphite project (e.g. aligned on tags, etc.)
A) better: officially incorporate a statsd implementation into the graphite project
arguably, it would also make sense to incorporate this statsd implementation into a carbon-relay,
to simplify things. potentially even re-imagine the statsd protocol as a "pre-aggregation/event based carbon protocol".
note that statsd supports various commercial hosted services as backends
https://github.com/etsy/statsd/blob/master/docs/backend.md , many of these are non-existant in the new implementation,
but i'm sure these vendors would be happy to contribute their backend code into a new project.
this also partially aligns with Grafana Labs interests:
we would be happy to have an integrated statsd-carbon-relay server that is officially sanctioned and
has a plugin for our platform. We may even help building it.
OTOH it may come short in addressing all of our goals for an on-prem agent, but that's another story.