Someone asked me for pointers on doing product management (and, to a lesser extent, project management) in Free/Libre Open Source Projects for the first time, after many years of experience in proprietary software. I basically made some points off the top of my head and here they are.

First: on the major differences between these environments, check out the "What doesn't get covered" section of "Gaps in Existing Guidance on Open Source Software Management".

But my advice also differs depending on what kind of open source project you're joining. As a product and/or project manager, you'll need to maintain a balance between listening to external stakeholders and keeping momentum towards goals you've already decided to pursue. And different projects have different attitudes towards this balance.

The Mozilla/Open Tech Strategies project archetypes have helped me understand those differences and get faster at figuring out what approach is going to work well with a particular project -- for example, see my 2019 post "Design, and Friction Preventing Design Improvement, In Open Tech." Some project types (such as Trusted Vendor, Bathwater, and Rocket Ship to Mars) simply are not interested in welcoming contributions from users, or at least are very averse to making room for those ideas and patches in their engineering schedules, so that's important for a project or product manager to understand going in. (Version 2 of the archetypes (2019) is more up-to-date, in case you've been relying on version 1 (2018).)

There's less nuance in Nadia Eghbal's 4 quadrants divided by high-to-low contributor growth and user growth (e.g. "stadium" and "toy") but they can also be helpful when you're gathering initial information. And heads-up that it's not enough to look at GitHub if you want to understand how many people contribute to a project (see my "What You Miss By Only Checking GitHub"); instead, rummage around CHAOSS and Project OCEAN (datasets).

And finally: peer examples will help you. Let's say you're interested in a paid job with one of the open stuff nonprofits that hires project or product managers, such as Wikimedia Foundation or one of the bigger chapters/affiliates, Signal, Tor Project, Python Software Foundation, Mozilla, Electronic Frontier Foundation, Internet Archive, Open Knowledge Foundation, Ruby Central, etc. In general, in these organizations, the paid staff are trying to be open and transparent in what they make and how they make it. They aim to ensure the users have a participatory voice in the product roadmaps, and to ensure that it's possible for particularly sovereignty-minded users to fork and to run their own instances of stuff. And they have to deal with the public-facing dynamics I described in "User Support, Equanimity, And Potential Cross-Project Tools and Practices in Open Source". Some users never show up for the big public consultations, some don't notice till late in the process and ask "why wasn't I consulted?", and there are some really vocal users who are not very collaborative. So the designers, managers, and other staff have developed cautious ways to do user consultations while shielding themselves against jerks.

Wikimedia, Mozilla, and Python Software Foundation have often blogged or otherwise tried to be transparent about how they do and improve strategy, deployment, user experience research and design, etc. For Wikimedia stuff I would look at meta.wikimedia.org and mediawiki.org -- search for keywords like "design" and "infrastructure" and poke around. With Mozilla I'm less certain, especially since they've broken a lot of links to old blog posts at blog.mozilla.org, but you could do worse than checking out Recent Changes on wiki.mozilla.org. Some Python Software Foundation examples: The user experience team wrote up their research, and it looks like some key material is still awaiting merge into the main pip docs, but here's the UX guidance they wrote for Python packaging maintainers, and here's the research synthesis with several useful reports. [Edited 2024 April 15 to note: now that the material is properly merged, you can read all the pip UX research and design and guidance material within pip's docs.] And the PSF blog has some excellent archives.

I'm less familiar with similar documents from the other organizations I mentioned, and welcome links in the comments.

The book I'm writing is going to go into all this sort of stuff in way more depth, but for now, hope this helps.