Sull’espansione del software nel tempo…

Un celebre aforisma, spesso veritiero negli effetti, così recita:

Zawinski’s Law of Software Envelopment

“Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.”

Una mia personale revisitazione generica di quella legge:

JP’s Law on Software Expansion

“Every software attempts to expand until it can even make coffee. Just before reaching that goal, someone else complains about that huge mess and will start a new tiny replacement project.”

Un buon software è spesso il frutto di un buon compromesso circa il numero di funzionalità incluse e “maneggiabili” da un utente medio.

Quello che molti sviluppatori non digeriscono proprio o fanno finta di ignorare è che l’utente medio si stanca in fretta di trovare sempre nuove funzionalità da imparare nelle sempre nuove versioni di programmi che utilizza: presto o tardi quel tipo di utente si ancorerà a vita ad una specifica release di un dato programma, rifiutando qualunque upgrade, oppure inizierà a cercare qualcosa di alternativo, che soddisfi tutte le sue necessità, ma senza farlo ammattire.

Capisco anche che il marketing spinga costantemente per poter disporre e vendere nuovi prodotti con nuove fantasmagoriche funzionalità, tuttavia questo non coincide necessariamente (o non coincide affatto) con il “Bene” del cliente.

Quante funzionalità può avere uno spreadsheet come Excel, quante ne conoscete e quante ne usate davvero? (Perfino voi cultori di questo genere di programma!)

Mi rendo conto che dare la colpa solamente al marketing sia un’ottima scusante, ma il problema è che noi stessi, gli sviluppatori, siamo i primi responsabili dell’espansione del software: se intravediamo la possibilità di aggiungere qualcosa ad un nostro progetto perchè ci piace o perchè sentiamo che ci serve, è molto probabile che l’aggiungeremo comunque, anche se non è fondamentale.

Arriviamo ad un punto essenziale: il bravo sviluppatore sa dire e sa dirsi no. Sa resistere cioè alle richieste che provengono dall’esterno per aggiungere questo e quest’altro (spesso non necessari se non “per fare numero” sulle brochure) ma sa soprattutto controllare il suo impeto creativo.

Non si tratta semplicemente di negare qualcosa ad un power user (ed uno sviluppatore lo è per definizione!) o un utente alle prime armi, si tratta di bilanciare un prodotto perchè sia usabile da entrambi e senza che nessuno dei due prenda il sopravvento come pubblico-target (a meno di software specifico, ovviamente).

Anzi, diciamocelo, se il software che viene progettato non è pensato per un uso iperspecialistico, dovendo scegliere, è meglio dire no al power user. Tanto quel tipo di utente ha sempre qualcosa di cui lamentarsi, ha sempre qualcosa di cui avverte la mancanza e che vi rinfaccerà alla prima occasione. Se poi è così bravo, magari modificherà o ricrereerà comunque da zero il vostro progetto, a suo uso e consumo. Per cui, perchè inseguire questo tipo di cliente difficile?

I power user – per quanto possa dar loro fastidio ribadirlo – sono numericamente poca cosa rispetto alla restante massa di utenti. Costituiscono certamente una minoranza forte e combattiva, è vero, ma non per questo devono averla sempre vinta.

Nel mondo FOSS è anche peggio…

Il mondo FOSS è una fucina di talento, un porto in cui le persone vanno e vengono, un ambito in cui il software non sta mai fermo. I progetti più importanti lo sono anche e soprattutto in virtù delle comunità che ruotano loro intorno; in ciascuna di esse si annida ogni genere di sviluppatore, da quello che spinge per fare il caffè istantaneo a quello che invece tende a frenare sistematicamente ogni novità.

Prima o poi, passo immancabile, tutti i progetti di successo si trovano alle strette fra “progressisti” e “conservatori” e l’esito di un tale scontro varia a seconda di molti fattori. Il vero problema, tuttavia, sono le frammentazioni del software a seguito di diverbi più o meno espliciti sull’evoluzione dei progetti FOSS.

Prendiamo un “caso storico”, il browser Epiphany:

Epiphany è la naturale evoluzione di Galeon (un progetto amministrato da Marco Pesenti Gritti) che aveva come obiettivo lo sviluppo di un programma che fungesse solo da browser. Il passaggio alla versione 2 delle librerie GTK+ ha portato molte novità (e incompatibilità), così si è optato per la riscrittura da zero del programma: Galeon è stato gradualmente inglobato in Epiphany.

Wikipedia inglese è più esplicita:

“Epiphany is an open source web browser for the GNOME desktop environment. The browser is a descendant of Galeon and was created after developer disagreements about Galeon’s growing complexity.”

Questo è solo un esempio di un vastissimo elenco. L’ultimo in ordine di tempo è il progetto Razor-Qt, l’ennesimo desktop environment, nato leggero, che sembra una reimplementazione di KDE 2/3.

Sul fronte GNOME, il fork di GNOME2, MATE, è invece un buon esempio di progetto nato come prosecuzione di qualcosa di dichiarato deprecato (GNOME2, appunto). Dal sito della distribuzione Mint, a sua volta una derivata di Ubuntu:

“MATE is a fork of Gnome 2 which is compatible with Gnome 3″

Non proseguirò oltre negli esempi. Mi soffermerò però sul punto che reputo essenziale: un software rimane vivo se viene seguito e migliorato costantemente.

“Migliorare” però non è solo “espandere”. Continuare ad aggiungere feature non è fare del bene nè al software (“più roba c’è, più roba si può rompere”) nè agli utenti (“più roba c’è, più gli utenti si romperanno di usarlo”).

Migliorare è prima di ogni altra cosa semplificare, agevolare l’utente medio, magari nascondendo ma non rimuovendo le funzionalità avanzate per i power user. In questo non mi piace nè l’approccio di KDE, zeppo di opzioni e parametri di configurazione anche per le quisquilie più superflue, nè quello di GNOME, troppo zelante nel levare tutto quello che – a sua detta – potrebbe confondere l’utente.

La virtù, al solito sta nel mezzo: un sistema semplice ma estendibile (es: tramite plugin) può far felici tutti i tipi di utenti. Si dà il minimo che l’utente medio può usare, ma anche ai rompisc… ehm… power user la possibilità di personalizzarsi e perfino riprogettarsi il software a loro uso e consumo, senza infastidire il resto del mondo.

Questo è un modo semplice per estendere il software senza renderlo eccessivamente carico fin dall’inizio e, possibilmente, senza spingere qualcuno a reinventarlo da capo.

La fluidità e l’impeto del variegato mondo FOSS sono indubbiamente la riprova che come modello funziona e funziona invero molto bene. Sono però convinto che la frammentazione di questo mondo – e relativa dispersione delle energie – sia una cosa estremamente negativa. Diciamolo, è un effetto collaterale estremamente spiacevole, spesso motivato da egoismo, rancore, pigrizia, … o da qualcos’altro, come la sindrome NIH. Come può sorgere qualcosa di positivo da un tale tipo di atteggiamento?

Che ne pensate! ^^