Working in Public book club questions

1. 1.

   Eghbal argues that the collaborative utopia of open source was always more myth than reality. Does that match your experience of open source projects you've used or contributed to?

2. 2.

   The stadium dynamic — one creator serving a massive passive audience — appears across open source, newsletters, podcasts, and social media. Why does this form keep emerging, and is it sustainable?

3. 3.

   If you maintain or contribute to open source software, how does your project fit Eghbal's taxonomy? If you're a user, which type of project do most of your dependencies fall into?

4. 4.

   The book argues that most users rationally choose to free-ride because contributing is costly. Is there a design or incentive change that could shift this, or is it a structural feature of the attention economy?

5. 5.

   Eghbal draws parallels between open source maintainers and internet creators (newsletter writers, YouTubers). Where does that analogy hold up, and where does it break down?

6. 6.

   Who is responsible for the sustainability of critical open source infrastructure — the companies that profit from it, the platforms that host it, the foundation ecosystem, or something else?

7. 7.

   The book describes how successful maintainers manage their attention by being selective about engagement. What's the equivalent of that in your own work — where do you need to deliberately not respond?

8. 8.

   Eghbal distinguishes 'producing' from 'maintaining.' How much of your own creative or technical work is new production versus maintenance of what already exists?

9. 9.

   Platform dynamics concentrate attention at the top of the creator hierarchy. Is that a flaw in how platforms are built, or an inevitable feature of attention markets?

10. 10.

    The book ends without a strong prescription for fixing the maintainer sustainability problem. Does that feel like intellectual honesty or an evasion?

11. 11.

    If a creator's attention is the scarce resource, what are the right and wrong ways to manage it? What would good boundaries look like for a solo open source maintainer with a large user base?

How to run the discussion

• Pick six to eight, not all of them. An hour of real discussion covers fewer questions than anyone expects, and racing the list is what makes a book club feel like homework.
• Open with what people noticed, not what they concluded. Asking for a verdict first hardens opinions before anyone has heard each other.
• Let the disagreement run. The questions below that split a room are the ones worth the time; the ones everyone answers the same way can be skipped.
• Ask the quiet person a specific question. A direct, narrow question is far easier to answer than an open invitation to contribute.