[AcLab] "ehi capo, passiamo al software libero?"

[Shark]

On Mon, Oct 29, 2012 at 01:35:25AM +0100, Federico Razzoli wrote:
> Ciao Shark, ti sei accorto che hai risposto a me personalmente?

Ovviamente no :-), ho rimesso in copia la lista.

> > Non capisco appieno. Useresti un software open pieno di bug piuttosto di
> > un software closed che funziona magari a pagamento solo per una
> > questione di etica?
> 
> No, ti ho già fatto l'esempio di Kompozer. Ma uso i software e le librerie
> che per me sono accettabili, senza chiedermi se ci sono alternative
> proprietarie migliori. Se trovo un bug lo segnalo, se è una libreria e
> implemento qualcosa mando una patch, se mi sembra che la documentazione
> contiene un errore lascio un commento. Nel caso di progetti piccoli,
> spesso provo a contattare personalmente l'autore. E ho sempre avuto
> risposta, anche nel caso di progetti morti. Il tempo che perdo non è
> paragonabile a quello che perderei se non ci fossero affatto il bug
> tracker, la documentazione coi commenti degli utenti, etc.
> Sono sicuro che il mio contributo personale serva a poco al progetto, ma
> in generale è questo atteggiamento che rende il software libero migliore
> di quello proprietario... ovviamente, sempre a condizione che chi gestisce
> questi strumenti li usi davvero e che ci sia realmente una comunità
> interessata a usare/migliorare quel software. Così come il software
> proprietario funziona solo se c'è mercato da una parte, e una società
> capace dall'altra.
> 
> > Non sono pienamente d'accordo con te. E` vero che ci sono tutte quelle
> > cose, ma nessuno ti garantisce che funzionino bene. Ad esempio, puoi
> > segnalare un bug nel tracker pubblico, ma nessuno ti garantisce che
> > qualcuno ascoltera` la tua richiesta (personalmente mi e` successo
> > un'infinita` di volte, sia con software grandi che piccoli). Stessa cosa
> > per la documentazione, c'e` molta documentazione, ma spesso obsoleta o
> > con parti mancanti.
> 
> Infatti io sto parlando di due metodi a confronto, non di singoli casi in
> cui le cose possono andare bene o male.

Pero` e` da considerare questa cosa, perche` entrambi i metodi hanno
delle pecche, e personalmente ho avuto esperienze "peggiori" (nel senso
di non essere stato cagato) piu` con dei software open che con
un'assistenza a pagamento.

> Poi sta a chi usa un software farsi un po' furbo:
> * prima di segnalare un bug guardo le statistiche e mi faccio un'idea di
> quanta attività c'è intorno ai bug segnalati e con quali risultati. Se i
> bug non vengono risolti, lo capisci in 2 minuti.
> * Prima di iscrivermi a una lista, guardo gli archivi. Chiaramente, se
> metà delle domande non trovano risposta, lascio perdere.
> * Prima di usare davvero un software me lo studio. In questa fase lo vedi,
> se la documentazione lascia a desiderare.

E se uno di questi punti e` negativo? Lasci stare e ti tieni un software
con un bug?

> > Insomma, con un software open e` vero che hai quegli strumenti pubblici
> > ma nessuno ti garantisce che siano affidabili, mentre se paghi un
> > supporto tecnico (e se l'azienda e` seria, cosa da non trascurare) sei
> > sicuro di avere il supporto quando ne hai bisogno.
> 
> Ora non sono d'accordo io: programmando in Visual Basic (sì ho fatto anche
> questo, quasi 10 anni fa) ho chiamato due volte il supporto Microsoft e mi
> è servito a ben poco, tanto che la terza volta non ho chiamato per evitare
> di perdere tempo. Sarò sfortunato io? Mah, la barzelletta che ho scritto
> nella mail precedente però non l'ho inventata io.

Scusa, ma quando compri Microsoft Visual Studio (se non sbaglio si usa
quello per programmare in Visual Basic, ma non ne sono sicuro) a quanto
ne so tu compri una licenza, non compri nessuna assistenza riguardo al
software, quindi il supporto Microsoft non aveva nessun obligo neanche a
risponderti. O sbaglio? (non e` una provocazione, non lo so sul serio)

> E poi anche qui mi sembra che rimanga valido quello che avevo scritto
> sulla concorrenza. Faccio l'esempio pratico di MariaDB: per il supporto
> tecnico puoi scegliere se rivolgerti a Monty Program, Percona, OpenQuery,
> SkySQL e forse altri. Essendo tanti (e ti assicuro che non sono cialtroni:
> ognuna di queste società è stata fondata da ingegneri che hanno creato
> MySQL e che Oracle non ha saputo/voluto tenersi) devono farsi concorrenza,
> quindi offrire un supporto di alto livello a prezzi non esorbitanti. Con
> il software proprietario non puoi sperare di cavartela a buon mercato,
> perché come insegna qualsiasi economista, se un mercato è monopolista
> (quindi se per il supporto di Oracle puoi rivolgerti solo a Oracle
> Corporation) il prezzo viene deciso da quella azienda.

Pienamente d'accordo con te, ma questo purtroppo non si puo` dire per
tutti i software open.

> C'è anche un altro fattore. Se segui un progetto grande (MariaDB, ma anche
> PHP, Apache...) i nomi degli ingegneri e dei community manager li vedi
> scritti mille volte, poi inizi a ricordarteli, leggi i loro blog, e se
> frequenti gli eventi del software libero li vedi di persona. Anche se non
> te ne frega niente, finisci per sapere dove vivono e se hanno figli!!
> Quindi hanno una credibilità da difendere, sia come correttezza sia come
> professionalità. Ma le multinazionali non aperte no, possono fare
> qualsiasi cosa, tanto non c'è una persona che perde la faccia, i
> dipendenti sono tutti delle entità misteriose. E allora ti promettono
> software che non arrivano, rilasciano robaccia instabile, ti fanno vedere
> dei benchmark fantastici e poi scopri che nel mondo reale il loro prodotto
> è lentissimo... dai, potrei farti mille esempi, ma lo sai anche tu.

Si`, e concordo. Da qua pero` puoi capire se un'azienda e` seria o no.
Ad esempio tu ritieni Oracle un'azienda poco seria e quindi ora lo sai e
non la usi. Altra gente magari ha avuto invece un'esperienza ottima. Io
non sono ne` da una ne` dall'altra parte dato che non sono esperto di
database :-).

> Poi ci sono le vie di mezzo, tipo Google che è chiusa però ospita i
> progetti open source. E' chiaro che hanno una credibilità diversa rispetto
> a Microsoft, perché non possono raccontare qualsiasi fesseria che gli
> passa per la testa, altrimenti la comunità li abbandona. Però anche
> loro... mi ricordo quando hanno lanciato google code che ammetteva varie
> licenze, ma poi hanno cambiato idea e con un preavviso minimo hanno
> buttato fuori tutti i progetti che usavano la AGPL.

Se non sbaglio avevano anche dichiarato i motivi (e non me li ricordo),
comunque si`, quelle aziende "a meta`" hanno pero` una grossa
reputazione da difendere.

> > In aziende medio-piccole questo magari non e` cruciale quindi si possono
> > optare per alcune soluzioni open anche se non hai supporto 24/7, ma per
> > altre aziende il supporto e la produttivita` e` fondamentale!
> 
> Sharkm, grazie della lezione, ma sei sicuro di sapere cosa vuol dire "la
> produttività è fondamentale"?
> Lavoro come programmatore dal 2000, e purtroppo sempre in società piccole.
> A causa delle consegne imminenti e i tempi troppo stretti ho lavorato
> spesso durante i fine settimana e la notte. Diverse volte, in diverse
> aziende, anche in campi diversi - dai siti web al data wharehouse. Non so
> se a un dipendente di una multinazionale è mai capitato di lavorare di
> notte...
> La produttività inizi a capire quanto è importante quando sei in una
> società con 4 sviluppatori che dovrebbero essere almeno 8 (ma non ci sono
> i soldi, o almeno così ti dicono), il tuo capo non mangia con voi per
> farti pesare che siete in ritardo e tu sai che se per caso domani mattina
> alle 10 il codice che stai scrivendo crasha davanti al cliente, l'intera
> società è fottuta e tu sei morto.

Allora, ti riporto solo un esempio su tanti che mi sono capitati
quest'estate. Si`, nelle grandi aziende si lavora giorno, notte e
weekend (e si vive anche il cercapersone sempre attaccato).
Una notte io e altri 4 colleghi stavamo cercando di risolvere un
problema di un grosso cliente e mentre cercavamo di capire la fonte del
problema abbiamo trovato un bug in gcc (si`, anche i compilatori hanno
dei bug). Una volta appurato che il problema stava proprio in gcc e non
nel nostro codice un mio collega non ha aspettato alto tempo e ha
chiamato Red Hat la quale ha risolto il problema in 1 ora e mezzo (da
contratto dovevano risolverlo entro 2 ore) e ci ha mandato il pacchetto
rpm con il problema risolto.

Prova a pensare se dovevamo metterci noi a cercare e risolvere il
problema in gcc, magari ce l'avremmo fatta, ma perdendoci un sacco di
tempo quando il problema non stava in qualcosa di nostro. Questa io la
considero "produttivita`": potersi concentrare sul problema da risolvere
e se sorgono altri problemi lasciarli ad altri (piu` esperi e che
giustamente paghi).
Ovviamente potevamo anche segnalare la cosa agli sviluppatori di gcc, ma
avrebbero anche potuto metterci piu` tempo, cosa che noi non avevamo.

Salot