Programmatori dentro

L’open source e le sue possibili implicazioni il caso Spring

ottobre 8, 2008 · Lascia un commento

Adesso che le acque si sono calmate e che la vicenda è finita bene vorrei provare a fare qualche riflessione sull’argomento. Parto dai fatti. In ambiente Java lo Spring-framework si è affermato come uno standard importante per lo sviluppo. Spring è rilasciato con licenza Apache che è, insieme a quelle BSD, una delle più permissive, ovvero con il codice ed il jar relativo ci puoi fare quello che vuoi. Spring è sviluppato da una azienda Spring Source che dalle attività di supporto, consulenza e sviluppo closed trova il suo sostentamento.

Fino a un mese fa venivano rilasciati i jar delle versioni con un ciclo di vita classico, rilascio delle major release (es 2.5) a cui seguivano le versioni con bug fix (2.5.1, 2.5.2, etc). Ed ecco che arriva l’annuncio, Spring Source cambia politica e dice che i sorgenti saranno rilasciati sempre cona la stessa licenza e sempre con su subversion, ma ci saranno solo i jar delle major release e delle minor release che verranno rilasciate entro tre mesi dalla data di rilscio delle mino release. Dopo i tre mesi ognuno fa da se’ se vuole i jar in quanto sul subversion pubblico non ci sono ne tag ne branch quindi nessuna informazione per creare delle minor release comuni. Se si vogliono i jar delle minor release successive si deve sottoscrivere un contratto di supporto.

Credo che si tratti di un caso da manuale. Il sorgente rimane disponibile a tutti, puoi compilarlo, ma in realtà la libertà è solo apparente. Se dopo i tre mesi trovo un bug cosa faccio? Consulto la lista dei bug e se questo è stato corretto scarico i sorgenti e li compilo. Benissimo a questo punto che versione sto usando? boh. Come faccio a chiede supporto sui forum della comunità se in pochi ho nessuno usa la mia versione? E’ facile intuire che se si vogliono creare delle applicazioni da metter ein produzione su cui garantire un supporto non si può procedere “liberi e belli” a meno di avere delle persone dedicate ai problemi Spring. Per cui ritengo che tale policy costringa di fatto a comprare il supporto da Spring Source. E’ il classico caso in cui del sorgente te ne fai veramente poco, quello che conta è che hai un prodotto di qualità, gratis e con un supporto da parte della comunità. E’ questo che dal punto di vista dell’utilizzatore conta, la libreria ed il supporto (per il management conta molto anche il fatto che è gratis); il sorgente spesso è uno specchietto per le allodole; un’altra cosa che conta è che la licenza consenta di vendere l’applicazione a sorgente chiuso (cosa che per esempio la licenza GPL non ammette).

Per fortuna le proteste della comunità hanno indotto Spring Source ad un cambio di rotta che ha portato al rilascio dei jar delle minor release fino alla versione RC della successiva major relase. Il problema si è notevolmente ridimensionato, a patto di essere sempre sulla cresta dell’onda ovvero di adottare l’ultima versione. Chi non se lo può permettere paga e tutto sommato è giusto così.

Vorrei concludere con una riflessione sui prodotti open source; l’analisi di una serie di casi mostra come storicamente tutti i prodotti che hanno dietro di sè una azienda che ne controlla lo sviluppo seguono un ciclo in cui la versione free (nel senso di free beer) subisce delle limitazioni del tempo; basti guardare Spring, MySQL, extJS e se ricordo bene anche le librerie QT. Il motivo è quasi sempre il profitto. Nel caso di prodotti open che sono sviluppati dalla comunità (Tomcat o Postgresql per esempio) questo non può succedere in quanto c’è una comunità di individui che spesso ricava profitto da altre fonti o in maniera indiretta. Lo svantaggio è che non ci sono persone dedicate allo sviluppo quindi le release possono essere diluite (anche se OpenBSD dimostra esattamente il contrario).

La scelta di un prodotto open source deve essere quindi effettuata facendo anche valutazioni di questo tipo in quanto i cambiamenti in corsa sono spesso sgradevoli e costringono ad un esborso economico improvviso oltre che ad una perdita di fiducia nel prodotto che si sta usando.

Categorie: java · sviluppo software · vita in azienda
Messo il tag: , , ,

0 risposte finora ↓

  • Non ci sono ancora commenti... Inizia tu riempiendo il modulo sottostante.

Lascia un commento