[ldapjs] Consider for maintenance

[jsumners]

https://github.com/joyent/node-ldapjs

Note: I am in no way affiliated with the package in question.

I'd like to suggest the ldapjs package for inclusion in the maintenance program. According to the public stats on npmjs.com:

• This package sees almost 50,000 downloads per day
• This package is directly depended upon by 229 other packages

Anecdotally, I think you'd have a very hard time finding another package that fills the role this one does within the Node community. Chances are, if you need to interact with an LDAP server via Node then you'll have this package somewhere within your dependency tree.

This package seems to be abandoned. It was originally authored by @mcavage, then maintained by @pfmooney, and most recently seems to be under control by @melloc. At this point the package has months old outstanding fundamental issues:

• https://github.com/joyent/node-ldapjs/issues/488 -- asking if the project is still maintained with a brief "I plan to get to it" from melloc in late August of 2018
• https://github.com/joyent/node-ldapjs/issues/483 -- fundamental API method doesn't work with Node 10 since early June of 2018. PRs to fix it are ignored (https://github.com/joyent/node-ldapjs/pull/497 and https://github.com/joyent/node-ldapjs/pull/485)

PRs with popular backing are ignored:

• https://github.com/joyent/node-ldapjs/pull/399
• https://github.com/joyent/node-ldapjs/pull/466

I'm not sure if this issue is the right format, but @mcollina suggested I bring it here (https://twitter.com/matteocollina/status/1139655792997650434). I looked through the issues around suggesting packages and didn't see anything about a formal process.

Again, I'm not affiliated with this module. I just recognize that it fills a big role for the segment of the community it serves, and that it is time for some TLC be given to it. From the evidence presented here, I think it is a waste of time to try and wake the project up with its current leadership.

[ghinks]

This does indeed look like a good candidate I would not be surprised if several large enterprises were unknowingly dependent on this unsupported package.

[Eomm]

We need to focus also on this type of issue: when a package needs a new "incubator" to start a new life. Would the actual maintainer join the pilot packages #142 program? This could improve our range of cases since it seems, there are different problems like:

• time to review
• time to release
• unknown test coverage

Relates to #144

[jsumners]

🤦‍♂️

I got contacted this afternoon by my old employer because an app that has been running flawlessly for the year since I left suddenly stopped working. The issue was they updated Node to v10 and the ldapjs library, the hinge of the app, was causing a TCP connection reset.

[mcollina]

I propose we ask if we could ask for a transfer of the package to this group. This should include both the github repo (for issues and PRs) and the ownership of the npm package, and start working on it. In the meanwhile, we should:

1. create a fork of the original repo, ideally in a less known organization (the nodejs/ org might be intimidating)
2. update it, solve known bugs etc.
3. release

Wdyt?

[jsumners]

I think that for whomever volunteers to take this project on that it would be a waste of their time working on a fork that might never take over npm.im/ldapjs. It seems to me the "clout" of the nodejs org is what solves the take over problem for abandoned "core" modules. In this specific case, I would think someone in the nodejs org has contacts at Joyent they could use to start the inquiry about taking over the repo and publishing rights.

I really wish I could be one of the volunteers on this specific project. But, as you know from Fastify and Pino, @mcollina, I just don't have the capacity. The best I can offer is an advisory role. I don't personally need the ldapjs module any longer. But I do still provide maintenance to https://www.npmjs.com/package/activedirectory2 which relies upon ldapjs (and gets a surprising amount of usage).

[mcollina]

There is a way to take ownership of a unmaintained module on npm, I've done this several times in the past, and it works reasonably well (npm support is amazing). Even if Joyent does not respond to transfer the module, it's possible to help the community anyway.

[jsumners]

Then your plan sounds fine to me.

[melloc]

Hey all,

I brought up transferring the node-ldapjs repo to the nodejs organization internally at Joyent earlier this week, and people are fine with doing that. @jgeurts forked the project a while back as ldapts, and has fixed several issues in the fork. If he's willing to take over ldapjs maintainership, I'd be happy to add him (or whoever else steps up) as an owner of the npm package.

[jsumners]

He didn’t really fork it though. He started from scratch in TS and has only implemented some portion of the client.

[mhdawson]

@mcollina I don't think this repo is necessarily the right place to transfer modules. I think this group should help to find volunteers who want to help in situations like this but not necessarily own the modules as I'm worried that will set an expectation that may not be able to be met. So the first step is to identify the volunteers who want to take ownership/move this forward. At that point we can then figure out what the best org/place for the module might be.

[jgeurts]

@melloc I can help with getting some PRs approved, pushing out some new npms, and getting the project to work with latest node versions. That said, I would appreciate someone else taking over the project at some point, as I have moved my projects to use ldapts.

I would also be willing to merge the projects, too. The main differences at this point are:

• The lack of server code in ldapts
• ldapts does not return an event emitter as the client or from search(). All socket events are handled internally. I think that works for 80% of the use cases, but is a challenge the end user wants finer control over socket errors or search responses. I haven't heard anyone complain about lack of events, but the use is far less than ldapjs.
• ldapts doesn't use callbacks, instead opting for async/await. I don't think that would be a huge deal breaker as all supported node versions support async/await.

[wesleytodd]

I don't think this repo is necessarily the right place to transfer modules. I think this group should help to find volunteers who want to help in situations like this but not necessarily own the modules as I'm worried that will set an expectation that may not be able to be met.

We have not finalized all of our WG details on this, but I agree fully with this statement. We should not directly be taking over projects yet (ever?). We should focus on being facilitators, as that is a method which we can scale up for the time being.

[jsumners]

@melloc I created https://github.com/ldapjs . Feel free to transfer the repo(s) there. I can't promise to be able to work on this much more than it is already being worked on, but I can get some movement going. If you need anyone to vouch for me I am certain @mcollina would be willing.

[jsumners]

I'm not sure what the state of this working group is, but I have another query about this topic. Does the WG think it would like to help with maintaining project domain names? At the moment, we have the ldapjs project under management by a very small community, but Joyent still retains the domain name ldapjs.org. Before I contact them to determine what their opinion is regarding the domain, I'd like to first understand if this WG is willing to manage DNS for such projects.

Relevant ldapjs issue: https://github.com/ldapjs/node-ldapjs/issues/679

[mhdawson]

My first thought is that I don't think this group will manage DNS entries for projects, but the team can discuss. If the project was a member of the OpenJS foundation, they would potentially help on that front.

[jsumners]

Okay. FWIW, if this group intends to ease the burden of keeping unmaintained "core" modules up-to-date, these sorts of things will come along with it. I believe this issue is showing a concrete example. The module, ldapjs, is widely used and had a specific domain promoted as the go-to source of docs, etc. If the group is going to help at all with these sorts of project, this should be considered.

As I mention in the issue I linked in my last post, I think the domain should just go away completely and the project fully shift to using the ldapjs.github.io domain. That will prevent this issue from cropping up again in the future should I decide enough is enough or literally cease to exist.

[ljharb]

In this case, the project isn’t owned by individuals, but by a corporation, so details around IP like domain names will be significantly more complex.

[jsumners]

No, it was transferred to the community and is maintained by myself and another individual.

[ljharb]

Ah, the OP says you’re in no way affiliated with it :-) In that case, hopefully joyent holding on to the domain is an oversight, and would transfer it to the two of you - at which point, one possibility is applying to join the Open JS Foundation, who would hold and pay for the domain as needed.

[jsumners]

I'm closing this due to lack of movement. I think there are unanswered questions remaining, in particular it's still not clear to me what this WG actually provides, or intends to provide, to modules that are in the state ldapjs was in before it was transferred to me, nor what it provides to modules that are in ldapjs's current state (a large project with ongoing maintenance burden being maintained by one person who has zero use for the module), but it's clear it isn't anything in this issue.

[wesleytodd]

I think there are unanswered questions remaining, in particular it's still not clear to me what this WG actually provides, or intends to provide,

I think there was a time where we had ambitions to help provide tooling to make it easier for maintainers of large and important projects. It became pretty clear that the group did not have the time/energy to really well support those things. Mostly I think the group has spun off a bunch of other smaller scoped projects and the WG is in place still mostly to steward those.

For requests like this, I think where things really fell apart was that we didn't have the resources to even achieve movement on the critical projects we picked, so picking up more things from other less critical ones was clearly not going to work. Sorry this was all unclear, maybe we should update the readme to try and reflect the current state a bit better?

[jsumners]

Yes, the readme should be synchronized with the current goal of the project. I did consult it, and linked resources, to try once again to understand this project's purpose before closing this issue.