Assistenza agli Sviluppatori

In un suo commento al mio articolo “La sicurezza dell’Open Source”, il coraggioso autore che si firma “nome e cognome”, solleva un problema molto interessante. Riporto qui di seguito tutto il suo intervento perché credo che sia il caso di parlarne a fondo.

“Non serve il numero di telefono? Il tecnico si limita a dirti che il problema è noto?
Ok un altro che non ha mai visto come funzionano le cose dove girano i soldi veri.

I clienti per cui ho lavorato io hanno speso milioni in licenze SAP, Oracle e Microsoft e quando si trovano dei bug si compila un bel form (quelli vecchi di oracle erano divertentissimi) in cui c’è sempre una domanda del tipo “quanto potrebbe costare il problema sul cliente?” … beh quando mettevi il fatturato dell’azienda e il numero di licenze comprate venivi richiamato dopo 10 minuti da un manager e mediamente dopo 5 giorni arrivava la patch, fatta apposta per te.

Visto capitare per Oracle e Microsoft … con SAP,fino ad ora, non ho mai trovato niente di così grave da non poter essere risolto con un workaround (ovviamente suggerito e supportato dalla casa madre).

Con il software opensource tipo Apache, Tomcat e cazzi vari posso anche segnalare il bug ma se nessuno di buon cuore si prende la briga di risolverlo allora mi tocca assumere un programmatore esperto e pagarlo a caro prezzo per sistemarlo. Non sono certo i milioni della licenza (almeno si spera) ma il tempo perso a cercare il programmatore può costare molto più caro.
Oltretutto dopo aver pagato qualcuno per risolvere il problema devo fare in modo che la correzione diventi parte del ramo principale di sviluppo altrimenti mi scordo gli aggiornamenti. E anche qui mi rimetto al buon cuore del mantainer del programma che potrebbe benissimo decidere di non includere il fix. A quel punto tocca mantenere un fork… e allora ciao.”

Innanzitutto, grazie per la lezione. Avendo lavorato solo per diversi anni per aziende che disponevano appunto di questo tipo di supporto da parte delle case madri, e dovendo io stesso fornire da anni questo tipo di supporto ai miei clienti, non potevo certamente sapere che le cose stessero in questo modo dietro le quinte… Chiedo umilmente venia per la mia profonda ignoranza. ;-)

Managed Software e Non Managed Software

Adesso lasciamo da parte il facile sarcasmo e parliamo di cose serie. Dovete sapere che esistono due tipi di software o, per essere più precisi, due diversi modi di usare il software. Li possiamo chiamare “managed software” (“software gestito in prima persona” ) e “non managed software” (software che non dipende da noi per la sua gestione).

I database, come Oracle (citato da “nome e cognome”) e MS SQL Server appartengono al primo tipo. Chi li acquista, li installa su un suo server e li gestisce in prima persona. Se qualcosa va male, può chiedere una patch al fornitore. Il fornitore gliela manda, il cliente la installa sul suo server ed automaticamente tutti gli utenti del sistema si trovano ad usare la nuova versione del software (ad esempio accedendo al database attraverso una interfaccia web).

I sistemi operativi (di cui abbiamo diffusamente parlato nel mio articolo) ed il software applicativo in grado di ospitare degli script (come MS Office o AutoCAD), appartengono alla seconda categoria. Una software house può sviluppare software “su” una certa piattaforma (MS Windows o MS Office, per esempio). Se però viene rilevato un problema alla piattaforma, in un elemento da cui dipende il vostro programma, le cose vanno in maniera molto diversa da quella del caso precedente. La software house cliente può benissimo chiedere una patch al produttore della piattaforma. Il produttore può mettere a punto la patch e la può fornire alla software house cliente ma… non è detto che la software house cliente la possa installare sui PC degli utenti. Fin troppo spesso succede che installando una nuova versione di una libreria, i programmi scritti da altre aziende per la stessa piattaforma smettano di funzionare (spesso perché dipendono proprio da un bug per funzionare…). Di conseguenza, raramente chi produce il sistema operativo o l’applicativo “host” permette ad una software house cliente di distribuire una sua patch. Per poter fare affidamento su quella patch, bisogna quindi aspettare che l’azienda che gestisce la piattaforma ospite rilasci un aggiornamento ufficiale (cioè un “service pack”) e che gli utenti finali lo installino.

Questo è esattamente quello che è successo anche a me in diverse occasioni, sia con Windows che con MacOS (e con diversi programmi applicativi). I programmi che abbiamo scritto dipendevano da elementi della piattaforma che contenevano un bug. Alcuni di questi bug sono stati corretti, più o meno prontamente, e le patch sono state distribuite agli utenti dalla casa madre. Altri bug sono ancora lì, anni dopo la loro scoperta. Questo vale per Windows (tutte le versioni), MacOS (tutte le versioni), Linux e BSD. Su Linux e BSD però, in molti casi, abbiamo potuto intervenire noi stessi, creando una patch da distribuire sotto la nostra responsabilità sui PC dei nostri utenti (e solo su quelli), in attesa che il tronco principale di sviluppo la includesse. Provate a fare altrettanto con un sistema proprietario come Windows o MacOS, se ci riuscite.

[Per la cronaca, questa storia della incompatibilità tra diverse release delle stesse librerie è anche la ragione per cui Windows Vista mantiene diverse versioni della stessa libreria sul disco fisso, l’una accanto all’altra, in modo da permettere ai vari programmi di usare quella di loro gradimento. Questa è una caratteristica prevista dalla piattaforma .NET e viene condivisa anche da Mono su Linux. A sua volta, questa è anche la ragione per cui l’installazione di Windows Vista cresce di dimensioni con il passare dei giorni.]

Correggere o non correggere?

Come programmatore, capisco molto bene la posizione di Microsoft e di tutti coloro che producono software che può ospitare altro software (cioè “piattaforme”).

Innanzitutto, ci sono bug che non si sa proprio come risolvere. Chi sviluppa CAD e modellatori solidi, per esempio, sa bene che ci sono situazioni geometriche, matematiche e logiche che sono tutt’altro che chiare e per le quali non è facile immaginare una soluzione.

Poi ci sono bug che sono talmente “annidati” nel codice che andarli a toccare vorrebbe dire sconvolgere tutta la baracca. Questo è il motivo, per esempio, per cui ogni tanto si riscrivono di sana pianta intere GUI, come è successo recentemente anche a Gnome ed a KDE.

Poi ci sono bug da cui dipende il funzionamento di qualcos’altro, scritto da voi o, molto peggio, dai vostri clienti. Io stesso ho nell’armadio degli scheletri una mezza dozzina di bachi “pesi” e ben noti che non posso riparare perché alcuni miei collaboratori ed alcuni miei clienti, ignari della situazione, li hanno usati come base per frammenti di codice che ora sono cruciali per la missione (“mission critical”). Mea culpa…

Poi ci sono i bug che costano di più a correggerli che a pagare le penali al cliente (o perderlo).

Poi ci sono i bug che sono di importanza limitata per il 99% dei vostri utenti ma che sono mission critical per uno soltanto, magari di poca importanza economica per voi.

Alla fine (come potete vedere in qualunque sistema di bug tracking dei programmi Open Source ed in quelli dei prodotti commerciali che sono pubblici), si stende una lista di “priorità” e si corregge solo una parte dei bug tra una release e l’altra (di solito meno del 70% di quelli “seri”, cioè meno del 20% di quelli complessivi).

A questo punto, potete capire perché chi ha le competenze per farlo (ed i programmatori professionisti hanno per definizione almeno una larga parte di queste competenze) alla fine preferiscano avere i sorgenti del software in modo da poterselo riparare da soli.

Una volta creata la patch, la si può gestire in proprio (come fa Apple con la “sua” versione di WebKit, usato dentro Safari) e/o chiedere che venga inserita nel tronco principale della linea di sviluppo. Francamente, devo ancora incontrare un maintainer così idiota da rifiutare un bug fix che proviene da una software house che vive sul suo prodotto, anche a costo di piazzare if nel codice e/o tag di compilazione nel makefile come se piovesse.

Primo: creare il caos

Microsoft è “più colpevole” di altri per una ragione ben precisa.

Once upon a time, verso la metà degli anni ’80, c’era un mondo relativamente omogeneo di sistemi operativi. C’erano diversi Unix (SVR4, AIX, Ultrix, SunOS e altri) che differivano parecchio l’uno dall’altro ma erano pur sempre Unix. Una delle aziende per cui ho lavorato ha gestito parallelamente lo sviluppo del suo programma su 13 diversi flavour di Unix per circa 15 anni. C’è riuscita usando codice portabile (Fortran prima, poi ANSI C) e, soprattutto, usando degli script di interpretazione dei comandi Unix scritti in linguaggio di shell (Bourne o C shell) od in Perl. In questo modo, con relativamente poca fatica, è stato possibile creare, e mantenere attivo per anni, uno strato di omogeneizzazione dei comandi di sistema attorno ai vari Unix, cioè una specie di Virtual Machine ante litteram.

Si sarebbe dovuta seguire quella strada, ad esempio diffondendo versioni di Unix specifiche per i PC, come ha tentato di fare Mark Williams Company con il suo Coherent Unix che girava sia su 80386 (32bit) che su 80286 (16bit).

Invece è arrivata Microsoft, con MS/DOS e poi con Windows. Nel giro di pochi anni, ci siamo trovati sommersi di versioni di Windows incompatibili l’una con l’altra più di quanto MS/DOS fosse incompatibile con Unix: Windows 3.0-3.11 a 16 bit, poi Windows 95, 98 ed ME a 32 bit, a fianco di questi Windows NT, 2000 ed XP basati su una base software completamente nuova, ed infine Windows Vista.

Addio ad ogni sogno di avere una piattaforma comune a tutti su cui sviluppare codice applicativo in santa pace. (Se questa situazione vi ricorda quello che è successo alla Sinistra Italiana con l’arrivo in politica di Silvio Berlusconi, state cominciando a capire perché io sono sia Comunista che Linuxaro ;-) ).

Ci siamo trovati tutti quanti costretti a creare e mantenere software per due, tre o quattro diverse versioni di Windows. Cosa ancora più grave, ora tutti quanti ci troviamo a gestire un parco macchine molto variegato e composto per il 30 o 40% da sistemi operativi privi dei più elementari sistemi di sicurezza (come la gestione delle utenze) e per i quali nessuno sviluppa più software (nemmeno gli antiviurs) o aggiornamenti. Un bel regalo ai virus writer…

[A futura memoria: Microsoft ha anche tentato di sviluppare un suo Unix, lo Xenix. In questo modo ha implicitamente riconosciuto che quella era una strada da seguire, forse la strada più logica.]

Secondo: vendere (a caro prezzo) le soluzioni

Nel bel mezzo di questo casino, è arrivata MSDN, cioè il “circuito” riservato degli sviluppatori Microsoft. Una volta comprato Visual Studio (l’ambiente di sviluppo ed il compilatore di Microsoft) ti trovavi costretto a decidere: o accontentarsi dei CD semestrali/annuali (ora non ricordo) con gli aggiornamenti della mutua, o sottoscrivere MSDN per avere accesso alle informazione ed alle patch in tempo reale. Altri soldi da tirar fuori…

Indovinate un po’ cosa si era (e si è tuttora) costretti a fare per stare sul mercato…

Terzo: chi più paga, più ottiene (ed i cocci sono dei “peones”)

E qui arriviamo al problema sollevato da “nome e cognome”. Si, è vero: le software house ed i grossi clienti quasi sempre dispongono di questo tipo di servizio a pagamento da parte di Microsoft, di Oracle e di altre software house.

Il costo di queste soluzioni è abitualmente abbastanza elevato. Ad esempio, nel 1996, quando ho deciso di comprare la mia personale copia di Visual Studio, l’ambiente di sviluppo “base” costava circa 700 euro di adesso, l’abbonamento a MSDN per i singoli sviluppatori costava altri 1.200 euro l’anno e l’abbonamento “corporate” di cui parla “nome e cognome” costava intorno ai 25.000 euro l’anno.

Cosa succede a questo punto?

Succede che chi ha soldi per pagare, come le grandi software house ed i grossi clienti, riceve un servizio di prima classe, che include anche lo sviluppo ad hoc delle patch (solo per il software di tipo managed. Non ho mai visto nessuno così idiota da dare ad un cliente una patch per una piattaforma condivisa da milioni di utenti).

Gli altri, a partire dai singoli sviluppatori ed i piccoli gruppi, si arrangiano. A volte si trovano addirittura a dover litigare con delle patch che l’azienda produttrice ha sviluppato solo per accontentare uno dei suoi grandi clienti.

Conclusioni: è questo il mondo che volete?

Questo è un mondo che rispetta le regole del libero mercato. Non c’è nulla di sbagliato in questo.

Ma è davvero questo il mondo che volete?

Io, personalmente, preferisco avere i sorgenti del software che utilizzo, in modo da poterlo studiare, verificare ed eventualmente correggere. A volte dipendiamo da altri per le correzioni ed altre volte riusciamo a fare da soli. Dipende dai casi. In ogni caso, non mi (ci) spaventa la dipendenza dalla comunità. In fondo, i maintainer sono quasi sempre dei poveri Cristi come noi. Non mi spaventa nemmeno la possibilità che un mio bug fix non venga inserito nel ramo principale di sviluppo. Si può sempre trattare con un altro essere umano. Trattare con una specie di Ministero della Difesa, sclerotico e burocratico, come sono molte grandi software house, è decisamente più difficile.

La questione commerciale

Ne approfitto per chiarire un punto. Quando dico che i miei colleghi ed io abbiamo deciso di abbandonare la piattaforma Microsoft e di dedicarci a Linux, quasi tutti si dimostrano sorpresi. “Ma come?! Windows rappresenta il 93% del mercato! Come fate a sopravvivere?!”

Il trucco è semplice: la nostra attività verte soprattutto sullo sviluppo (su commissione) di applicazioni “company specific”, cioè applicazioni che possono essere usate solo dall’azienda committente (magari su un suo server web, esposto al pubblico, o su dei dispositivi che l’azienda produce o vende). Né a noi né al nostro cliente interessa nulla di cosa usa la gente là fuori. Siamo comunque noi a fornire tutto il necessario (via web, sul terminale dedicato od in altri modi).

Può sembrare una situazione molto particolare, molto fortunata e non ripetibile in altri contesti ma non è così. In realtà, è la situazione in cui vivono ormai quasi tutti i “consulenti” italiani. Ad esempio, sono quasi sicuro che “nome e cognome” lavora su dei database (Oracle e SQL Server) che vengono resi accessibili via web. Di conseguenza, le aziende per cui lui lavora potrebbero benissimo decidere già oggi di abbandonare Oracle per PostgreSQL. Gli utenti non avrebbero nemmeno modo di accorgersene e, di conseguenza, non cambierebbe nulla per quello che riguarda la loro capacità di penetrazione sul mercato. Se restano attaccati ad Oracle è, immagino, per ragioni tecniche, non commerciali.

Forse adesso riuscite a capire perché io non riesco più a capire per quale motivo molti miei colleghi restino aggrappati tanto disperatamente allo “scoglio” rappresentato dal software proprietario. Non ci trovo niente di rassicurante. Uno scoglio è uno scoglio, non un’isola su cui trovare salvezza. Il mare aperto, là fuori, è molto più interessante.

Alessandro Bottoni

alessandro.bottoni@infinito.it

Advertisements
Comments
One Response to “Assistenza agli Sviluppatori”
  1. musashiII ha detto:

    mi piace come ragioni! :D

Rispondi

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

%d blogger hanno fatto clic su Mi Piace per questo: