The document outlines the open-source product management approach utilized by npm, focusing on balancing competing demands and fostering collaboration within the team. Key duties include fixing bugs, meeting business objectives, and enhancing the tool's functionality while acknowledging limitations. It also details the npm release process and guidelines for using the npm issue tracker effectively.

1. open source
product management
with npm
@othiym23 / Forrest L Norvell
npm, Inc.

2. npm

3. npm is many things
• project
• company
• team
• philosophy & ethos
• product family

4. npm is many
softwares
• registry
• website
• CLI

5. the CLI team

6. me

7. npm CLI team duties
• meet npm, Inc.’s business
objectives
• fix bugs
• support current npm users
• keep npm moving forward

8. make npm the most useful
tool it can be for the most
people

9. “useful”

10. pragmatism >
rigor

11. simplicity >
completeness

12. problems >
solutions

13. ($ > !$)

15. • 356 support tickets
• 222 bugs
• 236 feature requests

16. traditional product
management
• own the roadmap
• sell the strategic vision
• mediate between business
owners, developers, & other
stakeholders

17. say no a lot, but
be stubborn about
what you say yes to

18. open-source product
management
• balance competing demands
• consensus-seeking
• but sometimes you have to say
no

19. example: making
npm more
extensible

20. 1. lifecycle

21. 2. ADD M0AR
HO0KZ

22. 3. yay!

23. nope

24. (2. add more
commands, like
git)

25. npm is not an
infinitely extensible
miracle pegacorn

26. turn the problem
inside out

27. npm as a set of
APIs plugged into
a CLI

28. LET A THOUSAND
PACKAGE MANAGERS
BLOOM

29. CAVEATS

30. • looked at a lot of different
requests
• came up with a global solution
for many local problems
• try to keep each goal
supporting the others

31. npm’s roadmap
• scoped packages
• multi-stage install / dependency
tree realization
• npm as API
• better Windows support
• client-side development support

32. you

33. the npm release
process
• new release every Thursday
• new releases published to
npm@next for about a week of
burn-in
• `npm@latest` for safe production
release, `npm@next` if you want
to help test the next release

34. supporting npm
• the CLI team doesn’t have much
time for support
• `npm report` will make
crowdsourcing that easier, but
it’s a ways out
• answering questions with the
`support` label is ❤️ by me

36. using the npm issue
tracker: labels
1. bug, support, feature request
2. next-patch, next-minor, next-major
3. documentation, patch-welcome,
and novice

37. using the npm issue
tracker: best practices
• don’t add your bug to a closed issue
• …but please do add specific details
that helped you
• no such thing as too much
information, but gists are useful
• use cases are useful, +1s are
terrible

38. PATCHES WELCOME
• pull requests with tests are
landed as quickly as
practicable
• no patch is too small
• …but some patches are too big

39. developing npm
• `npm test` while developing
• `npm run test-all` before
submitting PR
• update the docs, plz
• people who add tests are my
favorite people

40. thanks for listening /
thanks for helping /
thanks for being you

41. nice people
matter