Dire che Scrum non può funzionare a causa di questi argomenti è come dire che Scrum non può funzionare in un'azienda, perché attualmente stanno usando waterfall. Mentre Scrum e cascata non giocano bene l'uno con l'altro (o piuttosto si contraddicono a vicenda) ciò non significa che non puoi stabilire lo Scrum lì, se tutti vanno d'accordo. Allo stesso modo non direi che Scrum non può funzionare in un progetto open source di per sé, ma ha i suoi limiti.
People tend not to work on Open Source projects full time
Anche se questo è vero, Scrum abbraccia anche questo tipo di incertezze. Dato che abbiamo un ciclo molto breve di una settimana, tutti quelli che vogliono contribuire dovranno impegnarsi per almeno una settimana e pianificare quanto tempo saranno in grado di spendere per il progetto. Sulla base di quanto tempo ogni contributore può permettersi, è possibile pianificare le storie su cui lavorare. In ogni caso, fare Scrum non sarà realmente possibile, se i contributori tendono a stare lontano dagli incontri obbligatori.
Naturalmente questo non è limitato ai cicli di sprint settimanali.
While some projects have a group of core contributors many pull requests are ad-hoc with people submitting pull requests which most likely won't contribute to any agreed sprint goal
L'open source non significa necessariamente che tutti possono contribuire come vogliono. Ci sono progetti open source con regole molto rigide su come contribuire (Linux per esempio). Le persone che intendono contribuire al progetto saranno obbligate a partecipare alla pianificazione dello sprint, ecc. Puoi rendere questo un requisito per contribuire al progetto. Ovviamente le persone che non amano questo possono creare un fork e lavorare su questo come vogliono, ma questo sarà un altro progetto, quindi.
Communities are often run via messaging systems, blogs, and forums rather than formal meetings like plannings sessions, retrospectives, and sprint reviews
Puoi avere gli incontri formali tramite telefono o meglio videoconferenze. Anche se questo non rende Scrum più facile, è ben possibile. Solo perché non è fatto nei progetti, ciò non significa che non possa essere fatto.
The direction of projects is often more of a democracy (or whoever contributes the most) rather than being focused by a Product Owner
Sì, dovrai avere qualcuno che agisca come proprietario del prodotto. Di nuovo, la solita pratica non ti impedisce di farlo diversamente. Inoltre, ci sono esempi di persone singole che guidano un progetto e lo guidano in una direzione (di nuovo, pensa Linux).
Per farla breve, anche se probabilmente hai ragione che non è una regola, non penso sia impossibile. Se hai un proprietario competente che sceglie e dà la priorità alle storie degli utenti e ai contributori che sono disposti a contribuire in questo modo, nulla ti impedirà di fare Scrum.
Modifica
In ogni caso - come è stato sottolineato dai commentatori - è probabile che sia un disastro e probabilmente non è una buona idea. Solo per menzionare alcuni punti per cui potrebbe fallire:
- Sarà difficile ottenere un nucleo di contributori - senza di esso, Scrum non giocherà i suoi punti di forza
- Senza una squadra molto stabile potresti tirare un dado per stimare i punti della storia - potrebbe funzionare ugualmente bene
- con il sovraccarico di Scrum sarà ancora più difficile reclutare abbastanza contributori
- I livelli di impegno molto probabilmente non saranno abbastanza alti
( Nota a margine: Un approccio tipo Kanban potrebbe funzionare meglio se vuoi dare una certa struttura al tuo progetto OSS, non dipende dai ruoli, il buy-in è molto più basso ed è molto più flessibile nel tempo, ma offre comunque una buona panoramica del WiP.)