Which Problems Node.js OSS maintainers/authors face today?

[mcollina]

In the early days, the Node.js community was composed by a small set of individual that learned to trust each other. Those individuals now maintains a high number of packages that are part of everyone dependency tree. Now, more complex software is being built and released on NPM on top of those tiny utilities, and the authors struggle to keep up with updates on their dependencies. Which challenges are the maintainers on both set face?

1. Building a community around an Open Source is a different job compared to writing a tiny module. Moreover, creating a community around a single utility is extremely hard. What strategies can we recommend to grow this community? Should we recommend that these utility be moved into a bigger organization (all streams module should move to github.com/node-streams for example) to simplify maintenance?
2. Managing changes in Node.js and dependencies is hard. Whenever there is a breakage that is fixed in a semver-major release, it’s highly possible that a stream of semver-major updates on all the dependency on a given tree. In some cases, CITGM is not broad enough to catch those breakages when a new version of Node.js happens.
3. There are two main trends in supporting different Node.js versions in the ecosystem: support ALL of them (express) or support only the LTS version. Is there a common strategy that we could recommend? The LTS cadence is dictated by Node.js.
4. Framework authors have often the challenge of testing the ecosystem for breakage of their dependents. Currently there is no such tool that helps in that regard.
5. Providing support for the user is a tough job and some project have an unchecked issue tracker because of this. How it is possible to migate this problem? What strategy should we recommend?

[ghinks]

A practical approach is to only support the LTS version. But we actually need to be really clear about what are our aims and what consequences those aims will have.

If the aim is to make sure that the enterprise can adopt and choose to subsequently support node then the LTS path makes the most sense. Enterprise upgrade less often and stick to the LTS versions.

We have to also be practical in that the weight of maintenance would eventually not be sustainable for anything other than the current LTS.

[ljharb]

For what it's worth, I strongly disagree with only supporting LTS versions and think that trend is hugely harmful to the ecosystem (I'd be delighted to debate/discuss that somewhere else, but let's please not get into it on this thread :-D ).

In other words, even that recommendation wouldn't be uncontroversial.

[ghinks]

as suggested I opened a new issue. I agree that what I said may be cause discussion.

[wesleytodd]

Should we recommend that these utility be moved into a bigger organization

This is what express has done, but it still has not developed a "community" around them. We have jshttp and pillarjs as a way to organize different types of modules used or maintained by the express team. It turns out that it is basically just the same group who worked on express.

There are two main trends in supporting different Node.js versions in the ecosystem

I fully agree with @ljharb's comment above. That being said, Express does not support "all" versions. We support the core versions at the time of the major release and above. So the wide range of support right now is just because we have not cut 5.0, but when we do it will drop support below the current versions. This is keeping with semver, and IMO would be what we should recommend if we recommend anything in this area.

Framework authors have often the challenge of testing the ecosystem for breakage of their dependents.

This is where a CITGM engine would be great! #84

Providing support for the user is a tough job

This is a problem we can help with IMO. This is one of the largest time investments the express team does, and it often has nothing to do with express directly. Many times it is "new to node" type issues, others it is node core http, and some are just asking for advice.

If we could channel all of this helpful energy into helping triage and debug with users it would go a long way to helping reduce burden for maintainers. I think the "good first issue" tag model might be something we could piggy back off and make a "needs triage" tag. Just pulling a list of these issues and presenting them to people who want to help might be a good start.

[wentout]

Many times it is "new to node" type issues, others it is node core http, and some are just asking for advice.

Variety of places, stackoverflow: there are a lot of answers with no real understanding.
Is it still "help" or not, if they look like answer but impact as a problem for thouse, who asking?

And if some package mainteiners answers directly, it always seems like a best solution. Therefore I think it might be more helpfull for users to make some solution of QA for packages, and additionally some sort of answers rate for managing "helpfull energy", if package is moved to bigger organization.

Or, though it might be hard, there is a way to link package with stackoverflow directly.

[wesleytodd]

We usually direct them to stackoverflow and our gitter channel, but that kind of help still takes time reading and assessing. What I was proposing is people who were around and wanted to be helpful could triage and direct people like we do. And if it was something more complicated, could be tagged for the primary maintainers to look at.

[wentout]

And if it was something more complicated, could be tagged for the primary maintainers to look at.

Oh, I see, thank you. Looks like 1st tier of support. So there can be common solutions, kind of enterprise ITSM software, but 4 everywone. Still wonder how person from this 1st tier will separate "something more complicated". Though, users are always turning back to the ticket, if answer was not helpfull. I think that is why users more often prefer systems with tracking ID to general chats with no linking.

Then the second point is to seek a solution for this. For example, this can be real help from "bigger organization" to unfold that solution if package is moved in. It might be real preference for package maintainers if there will be sort of guarantie of help to users. Google Groups are good as Help Desk, might be if the will be a way to auto-create pre-set of a group with all that necessary stuff, it will be the answer. Though it is very complicated topic. And also it can help with releases\changes notification channels as well: some bots stuff able to notify via twitter\slack\telegramm\whatever.

[mcollina]

In MQTT.js, we have 113 open issues, most of those from people that are new to Node.js. There has been a huge amount of questions of how EventEmitter works for example.

We usually direct them to stackoverflow and our gitter channel, but that kind of help still takes time reading and assessing. What I was proposing is people who were around and wanted to be helpful could triage and direct people like we do. And if it was something more complicated, could be tagged for the primary maintainers to look at.

As you said, this requires time as well, and it's the lack of time that we are talking about here. Should we perhaps recommend to go to https://github.com/nodejs/help?

[mhdawson]

I don't think using https://github.com/nodejs/help would be the right answer but we might create something like https://github.com/nodejs/package-help.

That would let existing contributors to ../help continue to focus on Node.js if that is there interest and provide a more centralized place for people who want to contribute to helping people with more general issues.

[dominykas]

Can we find a way to make people who do tech support in their day jobs spend their evenings to do OSS support for free? (Sorry, dark humour)

I think doing support is one of the most draining tasks that maintainers face. It's personal, it brings little value to the remaining community, it brings little value to the maintainer (unless a recurring request identifies a broader usability problem, which is rather rare, I suppose) and it is hard and quite often even when support is provided or a request for more information is made, the person who asked for support never responds again.

I don't have an answer, but I have observed and thought (more like sighed...) several times about it. I think that package-help deserves a separate issue to discuss options and ideas.

My current thinking is that OSS maintainers should not do unpaid support and that's probably a best practice. Support is expensive (there's a reason that businesses have separate departments doing that, rather than send their devs to do T1 responses) and brings value only to the supported, so maybe some default template responses with some links to where paid/free support can be acquired is a good thing to prep.

Yes, there's people who are willing to do that, but I'm not sure that relying on that is sustainable. Yes, people supporting each other is what communities are made of, but more often than not an issue for support is the single contribution a given Github account has ever made.

[ghinks]

Indeed @dominykas this is the dichotomy we face, we on one hand depend on these packages for our daily work and spend all day long solving business problems that make money. This leaves little time for us to show our appreciation by way of offering support for the tools we have been essentially gifted to make that money. I think we are searching for sustainability. Currently this entire endeavor is asking how we can sustain without paying for it, at least in cash. We will have to find a middle ground.

[ljharb]

I don’t agree; i find tons of bugs by supporting the community. I think supporting the community is a best practice - if someone will pay, great, but regardless.

[wesleytodd]

I don't think using https://github.com/nodejs/help would be the right answer but we might create something like https://github.com/nodejs/package-help.

I am not sure either of these would be the right solution. This would just be another place to check, because most of these users would not go there in the first place. I think stack overflow and some real time chat community (slack or gitter or whatever new chat app the kids use these days) is fine.

My current thinking is that OSS maintainers should not do unpaid support

While I agree in principal, this is one of the reasons the node community has been so great for new developers. That there are a lot of people out there willing to help. I think saying "we dont do unpaid support" is too hard of a line.

I'm not sure that relying on that is sustainable

I think we are searching for sustainability

Currently this entire endeavor is asking how we can sustain without paying for it, at least in cash. We will have to find a middle ground.

I think these are the right questions to be asking. Sustainability is the goal, and I think a mix of paid and unpaid work is the goal.

[sebs]

I might step in .. I have the habit of publishing to npm quite often (sorry for that) and doing so over a long time, I guess shipping something that is available for a big number of node versions has become harder (i guess) and here we could look at some new good practices.

[mhdawson]

I think it would be useful to identify a few key package maintainers and then have somebody reach out to them to either discuss/capture their major pain points or ask them to get involved in this thread. I'm not sure how to generate that list but finding maintainers with larger number of packages or those that are heavily depending on might be a good start.

[mhdawson]

In respect to

I am not sure either of these would be the right solution. This would just be another place to check, because most of these users would not go there in the first place. I think stack overflow and some real time chat community (slack or gitter or whatever new chat app the kids use these days) is fine.

On the flip side, if there are people who want to help out with having issues go into one place versus all of the different packages would be easier for them. The module owner would have to document that the first place to open an issue is package-help as opposed to opening an issue in the repo for the module (you could even require an issue be opened there for a week before you can open an issue in the repo for the module). The big assumption is that there are people who will be willing to provide general help for multiple different modules and I think a common package-help would have to auto close issues that are opened if nobody jumps in to help after 1 or 2 weeks.

The question in my mind is does this over value over people just using stack overflow instead. Maybe just documenting how module owners and refer people to stack overflow for initial help?

For example in @mcollina's case, would requiring people open an issue in stack overflow first and have it be active for a week before you can open an issue in the MQTT repo help. If so them maybe working through and documenting the mechanics for that might help. If it does help then would having something like package-help improve the situation by making it easier for people willing to help find the issues? If so then it might make sense, otherwise not.

[bluesockets]

Interesting subjects being discussed here.

I've been thinking about supporting all versions vs just LTS and I think I'm in the camp where just supporting LTS seems like the more practical approach longer term. Supporting everything is quite a challenge in that package maintainers would need some kind of way to reliably test breakage across all the versions and then figure out how to provide the same functionality regardless of whatever JS language features are available or not. Imagine writing a brand new and clean npm utility package that uses async/await and then having to port that code to versions of node before 8... It could potentially introduce quite a lot of complexity to manage.

https://github.com/nodejs/citgm is amazing for at least digging into compatibility! Maybe there's a way to leverage CITGM for testing before publishing to npm? Seems like some minor tweaks could add a lot of value if it were suggested as a baseline check for documenting compatibility with authority.

2¢

[ljharb]

@bluesockets you can already test breakage across all versions going back to 0.6 using travis-ci and nvm, see here for an example; you can use babel to transpile prepublish with the env preset so you never have to think about syntax support. These are all solved problems that end up requiring minimal complexity to set up and virtually zero to maintain.

[bluesockets]

@ljharb That's gold right there! I sure as heck didn't know about these tools until this conversation. I'm completely for surfacing this info somehow as a best practice for maintainers. If it's low effort/complexity to do then should we recommend it as a best practice so modules can maximize compatibility?

[ljharb]

I certainly do already :-) it’d be great to come up with a best practices guide for things like this.

[gabrielschulhof]

We should include in our best practices that Node.js as shipped by Debian and Electron need to be tested as well, because they may be ABI-incompatible with the official distribution of Node.js as provided by nvm even though the NODE_MODULE_VERSION happens to line up.

nodejs/TSC#651

[ljharb]

Personally i only support (and recommend supporting) node as installled from the only official distribution mechanism, nodejs.org, but i also don’t write native modules :-)

[vweevers]

We should include in our best practices that Node.js as shipped by Debian and Electron need to be tested as well

It's difficult to draw a line there. E.g. if we recommend to test native modules against Debian's distribution, then what about Alpine (for which prebuilt binaries must be built with musl), ARM, Android and so forth.

I think rather than saying "you need to test on X" as a best practice, we should say "if you want to target X, here's what you can do" as a guide.

[vweevers]

On a related note, users also have trouble with native modules on platforms like AWS Lambda, which a maintainer cannot solve (other than graciously providing support). So perhaps we need both a guide for maintainers (how to support as many platforms as possible) and a guide for users (what to do when your platform isn't officially supported).

[mhdawson]

Maybe the next step is to talk to the maintainers of the pilot packages we have identified and try and get their topic issues?

@mcollina is that something you can setup.

[mcollina]

I won't have time to do this for the next two weeks.

[bnb]

Nobody in today's meeting to discuss this specific issue/tool. Will hold off on discussion next meeting that someone is present to discuss.

[Eomm]

Maybe the next step is to talk to the maintainers of the pilot packages we have identified and try and get their topic issues?

I would add to this issue how the MQTT.js reply to questions #175
We are also waiting for the express.js reply.

[mhdawson]

@mcollina have you had any time to make progress on this?

[mcollina]

Not at all. I would not have time anytime soon unfortunately :/. Sorry.

[ahmadnassri]

Is there anything npm can provide in the context of anonymized data, patterns & behaviours that would help further surface information and insights here?