I can understand that a small group can split the job and everyone works on her own task. But how should this work with a larger group, spread over several places?
Bene, se ci pensate, funziona allo stesso modo in cui funzionano tutti i progetti di sviluppo distribuiti tutti . Gli sviluppatori usano strumenti (ad esempio controllo della versione distribuita) e procedure che sono provate e testate per questo tipo di situazione.
E la prova è che questo approccio funziona davvero ... se fatto correttamente.
Una cosa che funziona a favore dell'approccio "the code is the spec" per un file system, è che un file system Linux richiede solo un'implementazione master singola. Dal punto di vista degli sviluppatori, non c'è bisogno di implementazioni multiple di (diciamo) BTRFS, e certamente non c'è bisogno di re-implementazioni indipendenti (ad esempio clean room). Se lo guardi dal loro punto di vista , non c'è alcun valore per loro nello scrivere una specifica, creare un comitato per gestire le modifiche alle specifiche e limitarsi a conformarsi alle specifiche.
Commenti di jmoreno:
For something like a file system, I would expect a reference implementation and/or a test suite, which would be the documentation.
Si potrebbe dire che l'implementazione principale è l'implementazione di riferimento e la suite di test principale è la suite di test di riferimento. L'unico problema è che la suite di test sarà stata progettata come una suite di test delle funzionalità per l'implementazione master (di riferimento) anziché come una suite di test di conformità per tutte le possibili implementazioni di una (ipotetica) specifica.