Assistenza e Documentazione

In un articolo apparso oggi su Punto informatico ed intitolato “Un diluvio open source sulle aziende e la PA”, viene riportata la notizia che l’85% dei casi le aziende pubbliche e private, europee ed americane, usano già qualche forma di software open source. Subito, un lettore che si firma (sicuramente a sproposito) “Tecnico” commenta la notizia in questo modo:

“Se non ci fosse il governo a spingere per delle soluzioni open source, che non beneficiano di nessun supporto tecnico ne di valida doucmentazione, sparirebbero.”

Nella mia vita da informatico (1987 – oggi) ho fornito assistenza tecnica ai clienti delle aziende per cui ho lavorato per diversi anni. Ho usufruito a mia volta dei servizi di assistenza tecnica che erano messi a nostra disposizione dai nostri fornitori (tra cui Microsoft) per diversi anni (gli stessi anni e/o altri del caso precedente). Ho scritto documentazione software per altri anni ancora ed ho letto documentazione, sia di software open source che di software closed source, per oltre vent’anni.

Credo quindi di poter dare un giudizio “informato” sulla qualità dell’assistenza tecnica e della documentazione che accompagnano il software closed source e quello open source. Non vi sorprenderà il fatto che non sono per nulla d’accordo con il nostro amico “Tecnico”.

Assistenza Tecnica

L’assistenza tecnica a prodotti software può essere di tre tipi diversi:

  1. Assistenza all’uso del prodotto (quale che sia la tipologia dell’utente finale. Si può trattare di asssistenza all’uso di un programma di videoscrittura per l’utente finale “burocrate” o di assistenza all’uso di un ambiente di sviluppo e rivolta quindi a dei programmatori).

  2. Assistenza nella configurazione e nel cosiddetto “troubleshooting” del prodotto.

  3. Assistenza tecnica vera e propria, ciò risoluzione di “bug” e sviluppo di personalizzazioni.

Il primo tipo di assistenza (uso del prodotto) viene fornito nello stesso identico modo sia nel mondo open source che in quello closed source, con gli stessi identici risultati. In entrambi i casi, l’assistenza nell’uso del prodotto viene fornita soprattutto sotto forma di documentazione e di formazione. Per quello che riguarda la documentazione, vedete il capitolo successivo. Per quello che riguarda la formazione, si può solo dire che, sia nel caso di software closed source che nel caso di quello open source, i corsi sono quasi sempre organizzati e tenuti da aziende diverse da quelle che producono il software e sono quindi del tutto indipendenti dall’eventuale supporto fornito dalla casa madre.

I corsi su tutti i prodotti Microsoft, da Office a Visual Studio, sono tenuti in Italia da Mondadori Informatica. Mondadori fa uso di formatori che provengono dal libero mercato ed hanno una esperienza “come utenti” su questi prodotti. Come è possibile trovare buoni (e cattivi) formatori su Visual Studio, C# e .NET, è ugualmente possibile trovare buoni (e cattivi) formatori su Qt, KDevelop e C++. La qualità della formazione dipende esclusivamente dai formatori, non dalla presenza di una casa madre (che in questo contesto non interviene praticamente mai).

La libera disponibilità dei prodotti open source e dei loro sorgenti rende molto più facile maturare delle elevate competenze tecniche su di essi. Io stesso, ad esempio, sono in grado di raccontarvi quasi ogni singola virgola di Apache (ho sia i “binari” che i sorgenti installati su questa macchina). Non posso essere altrettanto preciso per quanto riguarda Microsoft Internet Information Server per la semplice ragione che questo prodotto va acquistato (ed io non ho nessuna intenzione di spendere i miei soldi in questo modo) e comunque i sorgenti di MS IIS non sono disponibili.

La disponibilità dei sorgenti diventa di importanza a dir poco drammatica quando si fa uso di librerie per sviluppare software. Le famigerate Win32, cioè le librerie di base di Windows, sono disponibili solo in formato binario. Di conseguenza, per utilizzarle bisogna basarsi sulla loro documentazione, sperando che sia corretta, e risolvere gli inevitabili dubbi a suon di esperimenti. Provate a stabilire la corretta “signature” di invocazione di una queste funzioni quando essa dipende per il suo funzionamento da un’ampia infrastruttura software e capirete perchè il solo fatto di dover procedere per tentativi ed errori rende odiose queste librerie.

Usare librerie a codice aperto, come le Qt di Trolltech, vuol dire che se avete un qualunque dubbio sul reale funzionamento di una funzione, non dovete far altro che aprire il file che contiene il suo sorgente e vedere cosa realmente fa e cosa realmente si aspetta da voi.

Per vedere una reale differenza tra software open source e closed source, bisogna esaminare il secondo tipo di assistenza (configurazione e troubleshooting). Le aziende commerciali (Microsoft, Oracle, Sun,etc.) si fanno un punto d’onore di fornire un raffinato servizio di supporto tecnico alla configurazione ed al troubleshooting dei loro prodotti. Di solito questo servizio viene fornito sia per posta elettronica (o su un apposito servizio web) sia per telefono (di solito un numero gratuito), spesso nella lingua dell’utente (italiano). In tutti i casi, dall’altra parte della linea c’è un tecnico competente, dotato di sangue freddo e di molta esperienza, che può davvero aiutarvi a cavarvi d’impaccio.

Peccato solo che questo servizio sia costoso e non venga quasi mai utilizzato. Si tratta di un servizio costoso (anche per chi si ritrova Windows pre-installato “gratuitamente” sul PC) perchè rappresenta una parte importante dei costi di commercializzazione del software. Tanto per fare un esempio, un’azienda di produzione software per cui lavoravo qualche anno fa, pagava qualcosa come 120.000 euro l’anno per avere accesso alla MSDN di Microsoft ed al suo servizio di assistenza destinato agli sviluppatori professionali. Si trattava di una azienda di medio/grandi dimensioni, con oltre 120 stazioni di lavoro, e di un servizio di classe “Premium” ma, anche tenendo conto di questo, stiamo pur sempre parlando di circa 1000 euro/anno per stazione.

Il servizio di assistenza (telefonica o per posta), peraltro, viene usato pochissimo. Gli utenti privati spesso non possono accedervi perchè non hanno una copia originale del programma (Windows, MS Office…). Nelle grandi aziende, che pure pagano il software e questo servizio a suon di dollari, gli utenti finali non hanno quasi mai il numero dell’assistenza della casa madre e si rivolgono invece al loro servizio di assistenza tecnica aziendale (quasi sempre in outsourcing). In questo caso, i costi di assistenza semplicemente (ed assurdamente) raddoppiano. Queste sono alcune delle ragioni per cui esistono i forum di “auto-aiuto” tra utenti di prodotti commerciali. Sono questi servizi di aiuto reciproco che risolvono (gratuitamente ed in tempi brevissimi) il 90% dei problemi della vita reale di questi utenti. Ovviamente, se si deve ricorrere agli “user group” per risolvere i propri propblemi, non fa nessuna differenza avere un programma closed source od uno open source.

All’altro estremo, sviluppatori software e amministratori di sistemi e di reti ricorrono molto di rado a questi servizi semplicemente perchè sono in grado di cavarsela da soli. Nel loro caso, è veramente raro che l’assistenza tecnica della casa madre possa fare la differenza. Addirittura, molti di loro ritengono fastidiose le patetiche scuse dell’assistenza tecnica della casa madre e si rivolgono direttamente ai forum degli utenti, dove trovano informazioni più sincere e più tempestive.

Il terzo tipo di assistenza tecnica (bug fixing e sviluppo di personalizzazioni) è quello in cui il software open source mostra tutta la sua superiorità. Nel caso di un prodotto closed source, se avete la sfortuna di incappare in un bug che è fastidioso per voi ma è un problema marginale (marginale in senso “commerciale”) per la casa madre, siete rovinati. La casa madre si limiterà a marcare il bug con una priorità bassa e voi dovrete imparare a convivere con esso per anni. Leggete questi due articoli per farvi un’idea della situazione:

Microsoft, sette anni per una patch

Microsoft spiega il ritardo di sette anni per la patch

Io stesso ho aspettato per anni la soluzione di problemi in vari prodotti closed source senza poter agire in nessun altro modo che inserendo i controlli del caso nel codice che scrivevo. Se poi dovete scrivere una applicazione che deve funzionare correttamente su più piattaforme, siete morti. Ognuna continuerà a conservare gelosamente i propri bug per rendere difficile l’interoperabilità e quindi la libera scelta della soluzione migliore. Questa, ad esempio, è da sempre la situazione di Javascript sui vari browser web.

Nel caso di prodotti open source la situazione è molto diversa. Non c’è motivo di aspettare i comodi di nessuno. Chi trova un bug, lo corregge e rende disponibile la correzione agli altri. Punto e basta.

A questo proposito, va detto che in circa 14 anni di utilizzo di Linux (e BSD) con Apache, PHP e mille altri programmi open source, ci è capitato spesso di incontrare dei bug ma non siamo mai stati costretti a sviluppare le patch in prima persona. Quasi sempre le patch sono arrivate ancora prima che avessimo il tempo di preoccuparci.

Inutile dire che anche lo sviluppo di applicazioni personalizzate dipende in modo strettissimo dalla conoscenza della specifica piattaforma e che questa conoscenza è enormemente più elevata nel caso delle applicazioni open source. Ad esempio, un mio collega in questo momento sta sviluppando un modulo PAM. Di PAM sappiamo tutto. Non solo c’è tutta la documentazione necessaria ma, soprattutto, ci sono i sorgenti. Sviluppare questo modulo custom è persino divertente (a patto di eseguire Linux su un emulatore…).

Fare la stessa cosa su Windows o su MacOS X richiederebbe quasi certamente il coinvolgimento della casa madre. Ovviamente, non è nemmeno immaginabile che Microsoft o Apple si mettano a taroccare il loro sistema di login per far piacere ad una “software house” che impiega quattro o cinque sviluppatori e fattura qualche decina di migliaia di euro l’anno.

Non è un caso che lo sviluppo di applicazioni custom venga quasi sempre delegato ad aziende partner della casa madre. Queste aziende però devono fare i conti con i nostri stessi limiti (mancanza dei sorgenti) e non possono quindi fare nulla di più di quello che possiamo fare noi. A questo punto, anche per l’utente finale è più facile e più economico trovare una azienda (come la nostra) in grado di creare un componente custom per un prodotto open source che trovarne una in grado di intervenire su uno closed source.

In un mondo fatto di piccole aziende che seguono il mercato in maniera agile e veloce, la disponibiltà di soluzioni ritagliate su misura, in tempi brevi e con costi ridotti, è spesso l’arma vincente. Per questo si vedono sempre più spesso soluzioni “verticali” (addirittura “a perdere” in alcuni casi) e per questo queste applicazioni sono quasi sempre basate su piattaforme open source.

Documentazione

Per quello che riguarda la documentazione, va detto che raramente le aziende commerciali hanno l’interesse e la competenza necessarie per sviluppare della documentazione utile, affidabile e comprensibile.

Per scrivere della documentazione di questo tipo è necessario conoscere benissimo il prodotto in esame e sapersi spiegare in modo eccellente. Inutile dire che è estremamente difficile trovare sul mercato del personale che conosce un prodotto closed source in modo così dettagliato (proprio perchè è closed source). All’interno dell’azienda è ancora più difficile trovare un veterano che conosca bene il prodotto e sia disponibile a scriverne la documentazione. Tra l’altro, sono rarissimi i tecnici in grado di spiegarsi al mondo in una lingua diversa dal C o dai file di /etc.

Di fatto, la documentazione migliore la scrivono, magari solo tre righe per ogni volontario, le comunità degli sviluppatori e degli utenti. Ma per scrivere documentazione di questo livello bisogna conoscere bene il prodotto e, ancora una volta, il livello di conoscenza che si può avere di un prodotto open source è immensamente superiore di quello che si può avere di un prodotto closed source, proprio perchè è possibile accedere ai sorgenti.

Per farvene un’idea, date un’occhiata alla documentazione di Python, di Ruby o di Apache, per esempio. Non hanno nulla da invidiare a quella di C# e .NET su MSDN.

Conclusioni

Se si vogliono trovare delle ragioni per continuare ad usare software closed source, è necessario trovare delle motivazioni ben più solide di questi luoghi comuni sull’assistenza tecnica e sulla documentazione. Se ne stanno rendendo conto anche le aziende clienti ed è sempre più difficile dargliela a bere.

Ormai è tempo di confessare: sul software commerciale (closed source) si incassa una percentuale come rivenditore. Su quello open source non si incassa nulla. Questa è la UNICA ragione per cui rivenditori e consulenti continuano a proporre software closed source.

Dalla loro parte, i clienti preferirebbero spesso prendere delle bastonate che doversi studiare un nuovo programma, soprattutto perchè la loro stessa pigrizia impedisce loro di accorgersi che i due programmi sono IDENTICI. Confrontate OpenOffice Writer con Word per rendervene conto.

Intendiamoci: il software closed source HA SENSO. In molte nicchie di mercato la modalità di sviluppo closed source è l’unica possibile e risolve un grossissimo problema. Date un’occhiata ai prodotti di statistica applicativa di Camo (http://www.camo.com/), per esempio. Tuttavia, non ha più senso tentare di appioppare MS Office a gente che scrive solo delle banali lettere e non ha più senso insistere con MS IIS e ASPX per i server web. Per queste applicazioni “mainstream” ci sono da tempo delle ottime soluzioni open source.

Alessandro Bottoni

Annunci
Comments
2 Responses to “Assistenza e Documentazione”
  1. Gianni ha detto:

    Eccellente disamina della realtà quotidiana dell’assistenza tecnica. Segnalo un errorino nei tag: “assietnza” invece di assistenza.

  2. MG ha detto:

    Ci sono persone che si scagliano contro gli altri solo per far notare che ci sono, tu scrivi anche su Punto Informatico, io non lo leggo più da tempo, mi danno fastidio i commenti.

    M.

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: