This one-hour discussion session covered some of the same material as my Linux.Conf.Au 2021 lecture, on "How To Get A Project Unstuck -- And Fixing The Skill Gaps That Got Us Here" (outline and links; video).

Below are some session notes, including some of the live collaborative document we used to take notes during the discussion. I've removed individuals' and projects' names.

Case studies

Autoconf (Case study: rejuvenating Autoconf; also see how my upcoming book is helping Autoconf's developers decide what to do next)

Pipenv (Pipenv case study)

Asking participants about their projects

• How old is the project?
• When was its last release?
• What kind of danger is it in? If no one intervenes, then 5 years from now, what will happen?

Principles of getting a project unstuck

Some premises I use in my work:

• There is no one tech industry and there is no one open source community.
• Open source contributors, as a population, disproportionately want to code.
• Skills are fungible; domain knowledge can be learned; credibility can be earned.
• Every open source project has a life cycle. (Including an end.)

Five major areas where legacy projects get stuck. I need help with the names for these categories! (And of course sometimes combinations of problems crop up.)

1. strategy, e.g., what work do we need to prioritize, and how urgent is it? what is our goal, and should this project exist (or should we decommission it)? has the team agreed on these things?
2. team, e.g., do we have enough maintainers to do the essential work, and do we have up-and-coming contributors who can replace us as maintainers in the future? does everyone know who has what powers, or are some people confused about who has the power to do certain things? do we run into team workflow problems when different groups want to participate at different speeds? is there a malicious, offputting, or flaky person who needs handling? do we have the social processes we need to support the project and each other, like meetings, mentorship programs, and Requests for Comment?
3. connection, e.g., who are our users and what do they need? are we listening to them? are we responding quickly enough to their concerns? do they have a way of listening to us? who are our partners and upstreams? do we talk to each other? do new contributors fall through the cracks?
4. workflow and digital infrastructure, e.g., do we run automated tests on every patch? do new issues, patches, and discussions get interlinked so developers and users can easily follow up? are there bottlenecks or duplications in the platforms we use to respond to issues, review code, and discuss the project in general?
5. money, e.g., do we have enough money to do what we want to do? have we developed plans or proposals to turn money into progress? can we persuade funders to give us money?

Thank you to a participant who suggested "interfacing" rather than "connection". I do like that better.

The sequence of steps for gaining credibility within a project and helping turn it around:

1. Settling in (doing routine tasks that do not require much trust, assessing and earning credibility)
2. Taking charge (doing things that require trust but that the group has already agreed needs to happen)
3. Making change (modifying and adding social, digital, financial, and legal infrastructure)
4. Passing leadership over to successors and leaving

This is the outline of my forthcoming book. My sampler ebook of Getting Unstuck: Advice For Open Source Projects, available for free download once you subscribe to my 1-10 times per year newsletter, includes that full outline.

Questions & discussion

What kinds of "stuckness" have you seen in FLOSS projects? I feel like I've seen 5 major areas where legacy projects get stuck (strategy, team, connection/interfacing, workflow, and money). Does that reflect your experience?

• not having motivation to promote it
• "I think sometimes (especially in an operating system) we have too many requests and this makes the development of the core slower"

What circumstances make it easier or harder for projects to get unstuck?

• harder when it requires more dev skill to contribute
  
• how easy dev toolchain is, to bootstrap project
  
• whether project will accept small submissions or needs to be 100% complete ... a lack of small problems for people to fix
  
• "how much it is connected to other communities, sometimes if more than one community is using the project there will be more people willing to maintain it and help in general"
• findability & presence of important information, e.g., code location
• conflict over whether to release a breaking change, because of refactors/rewrites
• sometimes there is no one interested in taking the money to help improve the project, or the amount of financial support available is insufficient to hire someone in North America or Western Europe

(I was struck by how much easier it was for participants to come up with programmer-specific problems -- especially problems with onboarding new contributors -- than to remember and bring up people, money, and other problems. After all, most mature software projects have a backlog of patches awaiting review, and so making it easier for more new contributors to get onboarded is a less crucial bottleneck than widening the code review bottleneck, which is probably a team, workflow, and money problem.)

Do you know a stuck project? What support would you need to start getting it unstuck?

• I have all the support I need, except I need a push... I don't use the program myself anymore, I do this to help users, so lack of motivation.... thinking about motivation and how we help ourselves in moments when we need more
• need help improving core skills (managerial and similar professional/interpersonal skills)

Plans for followup

I suggested that people form optional accountability pairs, to talk with each other regularly and help both stay motivated to get their project unstuck. Two people did pair up.