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

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.

Java vs. PHP atto II

Dopo aver finito la mia prima applicazione in PHP ed averla messa on-line voglio tornare sull’argomento del confronto fra le due piattaforme.

Lo scopo del post è rispondere alla famosa domanda: per scrivere la mia applicazione web devo usare java o php?

Caso n.1: se l’applicazione andrà installata sotto forma di hosting la scelta è praticamente obbligata php

Caso n.2: se chi scrive l’applicazione non ha fatto studi informatici o non ha anni di esperienza nella programmazione la scelta  consigliata è php

Caso n.3 se si sta cercando di fare del content managament (ovvero pubblicazione di contenuti tipo pagine web) la scelta consigliata è quella di guardare se esiste un programma php (e ce ne sono veramente TANTI) che fa al caso vostro.

Caso n.4 se dovete scrivere una applicazione che è al 50% HTML e 50% web service la scelta consigliata è Java

Caso n.5 se dovete fare progetti di cooperazione applicativa (secondo lo standard CNIPA) la scelta obbligata è java

Caso n.6 se dovete produrre applicazioni “corpose” Oracle based la scelta caldamente consigliata è Java

Solo i casi n.1 e 5 sono “obbligatori”, gli altri sono suggerimenti. Al termine della mia esperienza posso confermare che se si vuole scrivere una applicazione senza usare prodotti già fatti, ma solo librerie(es Spring framework piuttosto che Zend framework) Java è la scelta a mio avviso più produttiva (a patto di ipotizzare che le persone che ci lavorano abbiano la stessa produttività in entrambi gli ambienti) e matura, in quanto a livello di librerie web (e NON di prodotti tipo portali,CMS, etc) Java offre delle soluzioni più complete e più sofisticate (per esempio la gestione delle transazioni via AOP in Spring o i custom tag Spring MVC o Struts).

VB6 vs. Java

L’idea di fare un paragone fra VB6 e Java mi è venuta da una serie di esperienze recenti dove ho dovuto modificare o analizzare codice VB6 e java scritto da altre persone. Erano almeno 6 anni che non usavo VB6 e un ritorno al passato mi ha fatto capire le ragioni del suo successo. La prima cosa che ho notato del codice VB6 è stata la sua densità, ovvero quasi tutte le righe di codice erano dedicate a svolgere il compito specifico per cui era pensato il software; il codice Java che ho dovuto analizzare invece era l’opposto, per trovare le classi che svolgevano la funzionalità applicativa ho devuto aprire almeno 10 classi scritte per mettere le funzionalità applicative dentro il framework.

Questo mi ha fatto riflettere perchè in parte corrispondeva alle mie esperienze lavorative precedenti, da cui sembra emergere che i programmatori Java tendano a farsi tutto in casa; ovvero il logging, il mapping fra oggetti e RDBMS e così via. In VB no, codice e codice che fa le query e gestisce gli eventi utente, librerie custom zero o quasi (se non wrapper per usare meglio le funzionalità esistenti).

Credo che la ragione del VB6 sia stata proprio la produttività ovvero la tendenza con cui il linguaggio e l’ambiente di sviluppo portavano il programmatore a concentrarsi sulle funzionalità applicative. Credo che la situazione di Java nel 2008 sia QUASI come quella di VB6 nel 2000 nel senso che ormai ci sono tutte le librerie per concentrarsi solo sull’implemetazione degli aspetti funzionali.

Nonostante tutto non rimpiango i giorni in cui lavoravo in VB6 (anzi lo considero una sorta di peccato orginale). La ragione è molto semplice: in VB non si ha il controllo di niente, ovvero basta cominciare a complicare un po’ la logica applicativa per trovarsi intricati in una serie di eventi che rendono difficile stabilire un comportamento completamente deterministico. In Java il programmatore ha il controllo di quello che accade e può influire in maniera molto più efficace sul flusso di esecuzione. Questo credo che sia stata una delle ragioni del successo di Java (nei confronti di VB), il senso di sicurezza che viene dato al programmatore. Un’altra ragione è sicuramente stata il mix di eleganza/potenza della soluzione servlet+jsp che ha permesso a Java di diventare il riferimento in ambito server side. La risposta Microsoft, ovvero .net ha superato tutti i problemi tecnici precedenti e sotto alcuni punti di vista è superiore a Java (da quel poco che ho visto di C#, mi sembra una versione di Java rivista e migliorata), ma con il vincolo non indifferente di rimanere ancorata alla piattaforma Windows. Senza considerare che il codice VB6 va riscritto per essere convertito a .net per cui se si decide di cambiare il salto verso Java non è così doloroso rispetto a quello .net.

Java Vs. PHP

Negli ultimi mesi ho speso parecchie ore ad imparare ed usare il php, per cui ora che sono arrivato ad una sua discreta conoscenza vorrei provare a buttare giù qualche riflessione. Dal punto di vista del linguaggio la differenza più grande è che Java è tipizzato mentre PHP no. La seconda differenza è che in Java le variabili vanno dichiarate, in PHP no. A mio modo di vedere sono due grossi svantaggi a favore del PHP, perchè rendono più facile la scrittura di codice bacato. Una (almeno per me) stranezza del PHP è che i nomi delle variabili sono case sensitive, mentre quelli delle funzioni no. Anche questo fattore crea problemi almeno per chi è alle prime armi. La cosa invece che apprezzo del PHP è che è interpretato e quindi non devo riavviare Apache quando cambio il codice. Un’altra cosa positiva sempre legata alla dinamicità del php è che si sente molto meno l’esigenza di file di configurazione, in quanto il codice può essere la configurazione del sistema (si cambiano i valori delle variabili e via); in java ormai se non ci sono quintali di file XML si riesce a fare ben poco. E’ vero che questo potrebbe essere un problema legato più alle librerie che al linguaggio, ma se Java potesse essere dinamico come PHP credo che la configurazione di molte applicazioni sarebbe diversa. Per quanto riguarda il discorso legato alla produttività (che è stato il primo aspetto che mi ha spinto ad usare PHP) devo dire che il maggior peso lo hanno le librerie e che dipende da cosa si deve fare. Se si devono scrivere applicazioni web da zero e si dispone già di un server con Java (e di una struttura sistemistica dietro) secondo me Java aiuta di più. Se invece il target è un sito dinamico in hosting/housing presso un provider internet allora PHP è una scelta obbligata in quanto il supporto Java è pressochè nullo (a meno che non vogliate gestire un server dedicato o virtuale). PHP ha il grosso vantaggio di offrire una serie di prodotti gratuiti per quasi tutti i tipi di applicazioni. Basta cercare PHP CMS su google per rendersi conto del grosso vantaggio rispetto a Java. La (presunta) maggiore produttività vantata dagli ambienti PHP è dovuta essenzialmente alla presenza di applicazioni già fatte che consentono di non partire da zero. Le controparti in Java esistono, ma sono molto rare e molto più complesse (e solitamente si portano dietro mega e mega di Jar). Se dovessi scrivere una applicazione da zero e fare uso solo di librerie e non di prodotti esistenti allora Java, almeno per chi lo conosce e usa le librerie esistenti senza riscrivere ogni volta le cose da zero è la scelta migliore. In questo caso sono le librerie a fare la differenza: io posso dire a ragion veduta che SpringMVC offre un insieme di funzionalità nettamente maggiori rispetto allo Zend framework (sempre MVC). E’ vero che Zend è un framework più giovane, ma se devo sviluppare adesso (e consegnare per ieri)…….

Alla prossima dove parlerò di VB6.