Needs new maintainer

[raggi]

Needs new maintainer

[raggi]

Please understand that the bug here explains that we're looking for a new maintainer. It does not mean we're ignoring maintenance work. The common tone in comments on this bug seem to be responses to there not being a maintainer - but there is, I'd just rather not.

I can't responsibly hand over full authorship rights to someone else blindly, so I'm waiting patiently to see if anyone makes contributions that would be a good fit. Honestly the traffic is low - and that's totally fine. The most traffic on this repository in the last year has been on this bug. The code still works - it's still in active use by people. We still respond to other issues and accept PRs.

If the datadog folks want to discuss flattening their fork with this one, we can absolutely do that. It looks like they have a bit of outstanding maintenance on their side with issues dating back to 2015. I'm not going to audit their changes right now though - there doesn't appear to be any harm with things as they are.

Overall statsd is a waning project at this point (not the gem, but the collection system), and rightly so. There are now more advanced technical solutions that are at least as easy to deploy and maintain, if not easier. Those solutions offer better statistical models given the same inputs, and in many cases also offer optional professional support. Again this doesn't mean we're going to just stop responding here, it just means that it's unlikely anyone is going to come along with major changes or any particular interest to take stewardship of this library.

[johnnyshields]

@reinh @jnunemaker @vmg @raggi would it be possible for the Github fork to take over this project so we can have a single, well-maintained gem out in the wilderness?

[jnunemaker]

@johnnyshields we are currently moving away from statsd, so I'm not sure that we can commit to maintaining our fork in the future. Just my two cents. I'll let @vmg speak for himself.

[raggi]

To be fair to "well-maintained gem out in the wilderness", we have one open issue, this one. Despite having no interest, I've tried to come and clean things up as people request and time allows. It would be great to find a maintainer with skin in the game, though.

[raggi]

I just had a look at the graph, and at this point, the github version and this one appear to have diverged quite a way, the github one being 48 commits ahead, and 118 commits behind. It's also moved into a github namespace, which seems very sensible given the split. It's not immediately clear what the differences are, but I do see some features like signed payload support and sharding, which iirc we don't have. In neither case is the code base large, so merging them wouldn't take long.

[johnnyshields]

"well-maintained gem" > what I meant is that there are several forks and as an implementer it's not clear to me which fork I should use. (I've ended up choosing https://github.com/Shopify/statsd-instrument)

[raggi]

That one is very drastically different, it has aop style meta stuff in it and appears to be significantly larger across the board. It's really a competing offering with quite different initial goals, which is fine.

If anyone has a concrete proposal or is interested in taking on the project, please continue to discuss.

[reinh]

@johnnyshields wrote:

@reinh @jnunemaker @vmg @raggi would it be possible for the Github fork to take over this project so we can have a single, well-maintained gem out in the wilderness?

If GitHub or some other organization wants to merge in our work and take over maintenance, that's something we could talk about. I mean, we are literally asking for someone or some group to take over maintenance, so we certainly aren't opposed in principle.

"well-maintained gem" > what I meant is that there are several forks and as an implementer it's not clear to me which fork I should use.

Competition among open source projects is healthy and having options is useful (to an extent). Some of these other projects are also significantly different from ours (and entirely separate codebases) and you should be given the opportunity to choose them if they are a better fit for you. Obviously, we can't demand that they delete their projects so ours is the only choice, and merging unrelated codebases with different goals is probably both untenable and undesirable. That said, with options comes the need to make a decision, and ultimately we can't make that decision for you because it is unique to your particular requirements. However, we could do a better job of explaining the tradeoffs that exist in our project to help you make a more informed decision.

Also, I'd like to say something about this unfortunate implication that our project isn't "well-maintained":

While I haven't been actively involved in maintaining this project in years (in part because I haven't used statsd in years), I don't think this is fair to the current contributors and maintainer, who have all done an excellent job. Our project has had a total of 18 issues filed against it, most of which have been feature requests, and all of which (aside from this one) have been resolved. This also speaks to the high quality of the work done by these contributors (again, mostly not myself). Please understand that I honestly appreciate your interest and don't really think you meant anything by it, I'm just an over-protective papa-bear 🐻 who wants all the people who have donated their free time to help me with this project to be appreciated.

[johnnyshields]

@reinh Did not mean to imply the current repo is not well-maintained and did not mean to disparage anyone's hard work. Poor choice of words on my part.

[reinh]

@johnnyshields Thanks. 👍

[damm]

I think moving this into it's own org; would allow other maintainers to be added or removed regardless of @reinh 's github plan. It would be a first step; there's no active issues so there's nothing to race to fix

So it would be a soft step; and github would redirect them from reinh/statsd over to the new org/repo.

The rest is just getting more people interested

Just added this gem to one of my projects and starting to use it.

[raggi]

@damm people can be added here too, there's no plan requirements for adding contributors to public repos afaik. I don't mind a move, I can't speak for reinh.

What we're in need though is a new primary maintainer. Until then, moving things around is just more work for me & reinh.

[damm]

I think that would help; but it's not a requirement for someone new to takeover.

At least things are responsive; makes me less nervous. Thank you.

[damien]

@raggi @damm I haven't contributed to this library before, but my current employer is making heavy use of DataDog, which maintains it's own fork based on an older version of this library.

I'd be interested in contributing if there's work to be done. DataDog may also have a vested interest in stewardship of this library if you wanted a corporate backer for this project.

[damm]

Datadog has it's own protocol; this is more the standard statsd that works with Graphite. You can drop it in front of influxdb and it works just fine (I use it using the graphite protocol tbh)

The tag support is really what I'm talking about.

Lastly been using this gem for years; and it's worked. Sure it would be amazing to have someone back it; but truth is open source is more of a community effort. I wish we'd stop putting all this effort on the creator to keep it up.