One thing they mention several times is the idea of open-source project runners being upfront about their direction and limitations: what they are and aren't wi

One thing they mention several times is the idea of open-source project runners being upfront about their direction and limitations: what they are and aren't willing to do for the broader community. To this end, I love it when a project (of any size) has a written list of "goals" and "non-goals". Having the latter is important not just because they help set expectations, but because they set boundaries for the project. This past decade, open source has enjoyed a glut of resources, and many projects saw massive growth (both organizationally and in lines-of-code) and they became these huge things that required hundreds of people to maintain. This raises questions about sustainability, and any fans of the "unix philosophy" haven't been happy campers this past decade either. In the podcast they also mention the importance of extension interfaces and modules, so things that aren't part of a project's core concern can be externalized and swapped out by users as needed. Software should do one thing. Beware any large system where you can't tear along the dotted line and replace arbitrary parts of it with something else. Proprietary software and companies have a cancerous (and ultimately self-destructive) tendency to want everything to become an all-consuming monolith that there is no escape from, but this dark impulse lurks in open source too.