Cerca nel blog

2008/05/27

Microsoft supporterà ODF

MS Office avrà ODF: fine dei formati proprietari che aiutano i monopoli? Calma un attimo



Il 21 maggio scorso, Microsoft ha annunciato che il Service Pack 2 di Microsoft Office 2007, previsto per la prima metà del 2009, supporterà anche il formato ODF (OpenDocument), lo standard ISO 26300 utilizzato da vari programmi alternativi alla suite Microsoft, come OpenOffice.org. Gli utenti saranno in grado di "aprire, modificare e salvare documenti usando ODF" e potranno "impostare l'ODF come formato di file di default per Office 2007".

Le versioni precedenti di Microsoft Office, specificamente Office XP e Office 2003, gestiranno ODF tramite un componente convertitore. Nulla è dato sapere per i tanti che usano le numerose altre versioni di Microsoft Office.

Manca insomma ancora quasi un anno prima che diventi realtà una delle richieste più frequenti di chi non vuole essere sottoposto al cosiddetto "vendor lock-in", ossia la dipendenza da uno specifico prodotto: l'uso di un formato che sia utilizzabile appieno anche tramite altri programmi, in modo da non doversi trovare alla mercé dei ghiribizzi del venditore dell'unico software in grado di leggere correttamente i dati generati dagli utenti.

Come già detto in varie occasioni in questo blog, i formati sono una delle chiavi di un monopolio digitale. Se scrivo documenti che posso leggere o modificare soltanto con uno specifico programma (per esempio Microsoft Word, ma anche AutoCAD o Keynote, giusto per fare qualche esempio), perché è l'unico che gestisce correttamente quel formato, quei documenti saranno per sempre accessibili soltanto tramite quel programma. Se quel programma non viene più concesso in licenza, o se la sua licenza aumenta di prezzo, i miei documenti diventano inaccessibili, oppure devo pagare un dazio per leggerli.

Usando un formato aperto, invece, posso scegliere quale programma usare per leggerli. Potendo scegliwre quale programma usare, posso scegliere anche quale sistema operativo adoperare. I formati aperti si traducono insomma in maggiore libertà di scelta e possibilità di risparmio per i consumatori grandi e piccoli.

Il problema di tutta la faccenda sta nella parola "appieno". Come ben sa chi ha trasferito documenti da una versione all'altra dello stesso Microsoft Office, ci sono incompatibilità persino tra versioni differenti di software realizzato dalla medesima società. Anche il mondo open source, che appoggia i formati aperti, ha problemi di compatibilità: aprite un documento in formato ODF usando OpenOffice.org e usando Koffice o Google Docs o uno dei tanti programmi che supportano ODF, e noterete subito che la formattazione perde pezzi per strada.
Quanto sarà completo e trasparente il supporto a ODF in Microsoft Office?

Anche se soltanto l'idea di Microsoft che supporta il formato OpenDocument sembrava eresia e fantascienza fino a poco tempo fa e quindi quest'annuncio è molto significativo, conviene dunque aspettare prima di festeggiare la "resa" di Microsoft: bisogna vedere quanto sarà completo il suo supporto al formato ODF, e poi c'è da tenere presente che Microsoft non ha ancora deciso di abbandonare il formato rivale che aveva proposto, l'Open XML, anch'esso ratificato da poco dall'ISO/IEC fra mille polemiche sulla correttezza della procedura.

Nel frattempo, però, si tratta sicuramente di un buon passo nella direzione giusta. Se Microsoft vuole togliersi di dosso la nomea (peraltro giuridicamente accertata) di monopolista aggressivo, deve abbracciare gli standard aperti, anche perché i consumatori stanno cominciando a rendersi conto che esistono soluzioni alternative. Del resto, qualitativamente la sua suite è in grado di competere più che alla pari con i prodotti alternativi anche senza bisogno di ricorrere al trucchetto dei formati proprietari.

Trovate alcuni commenti sulla vicenda presso The Register, la ODF Alliance e la BBC.

10 commenti:

Edo ha detto...

La mia chiave di lettura di questa notizia è leggermente differente ...
M$ ha spinto per far standardizzare il suo formato ma adesso si ritrova con la sua suite per l'ufficio dal nome fantasioso che, se sottoposta a test per la compatibilità con lo standard iso, riporta centinaia di migliaia di errori (ennesima prova che M$ non riesce a rispettare uno standard nemmeno se è stato proposto da lei).

Alla luce di questo è al momento impensabile per M$ offrire un prodotto incompatibile con ben DUE standard iso e da qui la necessità di implementarne almeno uno.

Ovviamente la scelta è ricaduta su quello tecnicamente migliore per diminuire i tempi di implementazione.

Nulla le vieta comunque di rimuovere il supporto in scrittura a odf convertendo tali documenti in ooxml qualora riuscisse a implementare decentemente il suo standard ...

più o meno le stesse cose le ho già scritte sul mio blog http://justalittlebitofgeekness.blogspot.com/2008/05/grosso-smacco-per-m-e-per-il-suo.html

Dan ha detto...

A proposito di formati proprietari, vogliamo parlare anche di Wordpad di XP, che non è in grado di leggere un .doc con poche semplici formattazioni, fatto con Wordpad di win98? La situazione è ridicola, un programma che alla successiva edizione del S.O. non riesce a leggere i file da lui creati, mentre openoffice riesce nell'impresa... senza contare l'inspiegabile scomparsa del .doc da detto programma, che adesso può salvare solo in .rtf o tre varianti di "solo testo".

Quanto al OOXML è evidente che microsoft ha cercato in tutti i modi di legittimare una sua personale versione 'concorrente' di opendocument. Piuttosto mi chiedo: è sensato e legale approvare due standard ISO per due cose così simili? (e aggiungerei, fatto per ripicca: come al solito la microsoft se ne frega di quello che già esiste, lei si fa i suoi di standard...)

Negadrive ha detto...

Sarebbe una gran cosa se la battaglia della concorrenza, anziché ruotare attorno al vendor lock-in, venisse combattuta principalmente a suon di caratteristiche e prestazioni del software. Ovviamente la Microsoft fa quello che le conviene di più in quanto azienda; spero quindi, da utente, che nell'attuale situazione le convenga (per qualsiasi motivo) implementare un supporto completo per odf.

Andrea Valboni ha detto...

Caro Attivissimo, sono Andrea Valboni, Technology Officer di Microsoft Italia, forse ci siamo anche incontrati. Permettimi di dissentire su una cosa (ce ne sono diverse che trovo inesatte, ma questa è importante). Questa non è una "resa", non si tratta di continuare una guerra di formati, come molti, troppi hanno voluto che questa faccenda apparisse. Se querra c'è stata, è finita; e credo sia arrivato il momento per chi crede nella possibilità di interoperabilità e convergenza tra questi due formati (in realtà sono 4 gli standard da prendere in considerazione) di lavorare perchè pian piano succeda davvero.
Credo che questo nostro annuncio sia un primo passo importante in questa direzione, forse non tutti hanno pensato che il precedente di Febbraio sull'interoperabilità non fosse una svolta importante per noi, ma lo è stato davvero.
I formati binari, o proprietari che dir si voglia, spariranno progressivamente nei prossimi cinque anni: con la possibilità di usare OOXML, ODF e PDF 1.7 non resteranno molti documenti con formati diversi a giro. Cosa possa succedere dopo, è difficile da prevedere, magari verrà fuori un altro standard che cancellerà quelli esistenti. Nel mondo della standardizzazione funziona così: spendi anni di vita a fare la pila ISO/OSI, poi esce il TCP/IP, i protocolli internet e tutto cambia.
Molti oggi sono impegnati a implementare convertitori e strumenti vari che trattano sopratutto ODF e OOXML. Poni giustamente la domanda: ma quanto fedelmente? La conformità ad uno standar è da sempre un problema non risolto (vedi X.400), ma forse adesso si inizia davvero a sentire la necessità di qualcuno che definisca dei profili di conformità e degli strumenti che permettano a chiunque di capire se e quanto un formato è conforme ad uno standard. Ne parlava Roberto Galopppini ad un convegno a cui abbiamo partecipato assieme e sono daccordo con lui, è un mestiere che qualcuno deve fare.

Paolo Attivissimo ha detto...

Ciao Andrea,

sì, se non erro ci siamo incrociati con piacere a Milano per una conferenza stampa sul virus Kamasutra, nel 2006.

Le virgolette intorno a "resa" stanno a indicare appunto che il termine non è usato letteralmente. Non penso affatto che l'inclusione di ODF sia una resa, ma so che molti potrebbero interpretarla come tale.

La scelta di abbracciare anche ODF è comunque una svolta molto importante nella politica di Microsoft.

Almeno a livello d'immagine, infatti, Microsoft è passata dall'ignorare ODF e spingere il proprio OOXML ad includerlo fra i formati supportati da MS Office e addirittura anticiparne l'implementazione rispetto a OOXML. Notevole.

E' un cambiamento davvero drastico, che mi ricorda molto la "Internet Tidal Wave" di un famoso memo (1995), quando Gates decise che non si poteva continuare ad ignorare Internet in favore dei giardini cintati proprietari, ma era necessario abbracciare la Rete.

Ricordo anche lo scambio di idee con il vostro Martin Taylor la sera dell'incontro su Kamasutra. Due anni fa, l'idea di supportare ODF in MS Office gli parve eccentrica, quasi eretica (ma non la escluse). Ora le cose sono ben diverse, e questo mi fa molto piacere.

Posso solo dire "era ora, e continuate così". Sono convinto che MS Office abbia la qualità (e il supporto tecnico) che serve per competere anche senza la gruccia di un lock-in ottenuto tramite i formati.

Nessuno, a parte una banda di eccentrici rumorosi ma sparuti, vuole realmente la sparizione di Microsoft. Ma molti (compresa, come ben sai, l'UE) vogliono un terreno di gioco meno sbilanciato e sono preoccupati per il vendor lock-in che vincola i loro documenti.

Credo che il bonus d'immagine che Microsoft otterrebbe nel mollare Office Open XML (visto, a torto o a ragione, come un inutile doppione) per abbracciare ODF sarebbe impagabile. Farebbe vedere al mondo che Microsoft ha davvero voglia di competere alla pari e di dimostrare sul campo il proprio talento.

A proposito: se hai tempo, sarebbe interessante una spiegazione dei vantaggi di OOXML rispetto a ODF. Perché tenere in piedi due standard, se ne basta uno?

Sul "quanto fedelmente", infine, siamo perfettamente d'accordo: anche nel mondo open source e in quello Apple e nei servizi Web come Google Docs, come ho scritto, ci sono vari livelli di fedeltà nel supporto a ODF. Sarebbe davvero un colpo da maestri se MS Office diventasse la suite che meglio di ogni altra supporta ODF. Toglierebbe elegantemente il tappeto da sotto i piedi a tante argomentazioni a favore delle soluzioni alternative.

Tecnologicamente, ne siete capacissimi. Mi auguro che abbiate anche il coraggio imprenditoriale di farlo, come fece Gates allora con Internet. In termini d'immagine, sarebbe decisamente meglio che andare avanti a sanzioni UE e a Broadcast Flag accesi a sorpresa :-)

Francesco Sblendorio ha detto...

Ciao,
vorrei approfittare, vista l'occasione, per chiedere ad Andrea Valboni, se il supporto ODF a Word sarà paragonabile a quello dell'ODF Converter rilasciato come open source da Microsoft.

L'ho testato con questo documento di test, caricandolo e risalvandolo varie volte, con risultati poco soddisfacenti.

Al contrario, il Sun ODF Plugin per Word 2003 funziona piuttosto bene, almeno con i documenti che ho avuto modo di provare, compreso il semplice test precedente.

Mi chiedo perché per l'ODF Converter non si sia attinto codice sorgente direttamente da OpenOffice (ok, bisogna convertirlo passando da C/C++ a C#, ma non credo sia un problema insormontabile per voi), a codice aperto e liberamente "scopiazzabile", dato che i filtri di import/export di Open Office, almeno nei test che ho potuto effettuare, hanno funzionato meglio di ODF Converter in tutti i casi.

Grazie per l'attenzione,
Francesco

Francesco Sblendorio ha detto...

Piccolo addendum: apprendo proprio ora dalla stessa sua homepage che il Sun ODF Plugin funziona anche con Word 2007 Service Pack 1

Edo ha detto...

Caro Andrea, il tuo commento non era rivolto a me e probabilmente non hai letto o non hai giudicato degno di risposta il mio precedente commento.
Effettivamente ci sono vari elementi che giocano a mio sfavore: riporto i fatti e non mi limito a fare "accuse" (passami il termine) generiche ed è lapalissiano che non riesca a provare simpatia per MicroSoft.

Forse è un mio limite ma non capisco come si possa provare simpatia per una multinazionale che predica bene e razzola male:
- forse non tutti ricordano la condanna di M$ in francia per pirateria sw nel 2001 (Paolo ci scrisse un articolo per apogeonline)
- i vari procedimenti dell'anti-trust che hanno portato a sanzioni decisamente importanti
- la completa mancanza di rispetto verso qualsiasi standard preesistente (html, css, w3c dom e proprio per finire odf), certo, solo i maligni sostengono che forzando una variante allo standard i tuoi clienti rimangano legati a te
- la mancanza di interoperabilità tra le diverse versioni dei suoi stessi programmi
- dopo aver spinto tanto per avere un altro standard iso (perchè odf non andava bene ?) si scopre che un test effettuato da Alex Brow ha evidenziato circa 122.000 segnalazioni durante un tentativo di validazione e quindi ad oggi (e chissà per quanto tempo) nessun sw sarà compatibile con ooxml (mi risulta che M$ non abbia fornito date per il rilascio ma può smentirmi)

Dopo questa "piccola" ma doverosa premessa vengo a noi.

Non mi è piaciuto il fatto che abbia accennato alla presenza di diverse inesattezze e poi non le abbia nemmeno indicate, magari le mancava il tempo.

Parla di interoperabilità ma non spiega perchè invece di adeguarsi ad uno standard già esistente M$ abbia voluto spingere (e la prego di non insultare la nostra intelligenza negandolo) il più possibile per l'adozione di uno standard proposto da lei senza poi aver nemmeno un programma che lo supportasse e visto che è pianificato prima il supporto a odf che non a ooxml mi fa supporre che il primo sia più semplice da implementare. In nome dell'interoperabilità quindi, e con grande magnanimità, M$ decide di fare dono al mondo di un altro standard, uno così semplice che la sua realizzazione risulta essere compito non facile nemmeno per le sue risorse (figuriamoci quindi i tempi di sviluppo per quelle società che non hanno a disposizione tali risorse).

Fa confusione poi tra formato binario e proprietario, non sono ne sinonimi ne contrari (la rimando su http://www.openformats.org/it1 per un facile approfondimento).

Ho trovato ironico il tuo riferimento alla conformità ad uno standard visto che come ho già fatto notare nemmeno M$ riesca al momento ad essere conforme allo standard da lei proposto e proprio al fatto che invece che dover essere conformi ad un solo standard grazie a M$ adesso i sw dovranno essere conformi a due standard per poter garantire interoperabilità, indubbiamente una mossa tesa a semplificare le operazioni.

Secondo il mio modesto parere prima di parlare di interoperabilità e promulgare nuovi standard (che al momento ribadisco, per il gusto di farlo, esiste solo sulla carta), M$ si sarebbe dovuta impegnare a rispettare gli standard esistenti.
Non sono aggiornatissimo su tutto ma ad un mese fa la beta di IE 8 si era dimostrata la versione più incompatibile con gli standard valutati dal test acid 3 con un mero 18/100 mentre webkit e opera sono a 100, firefox era a 71 e khtml a 73.

Se dovesse ritenere interessante controbattere alcuni o tutti i punti da me evidenziati si senta pure libero di farlo.

Dan ha detto...

La "Internet Tidal Wave" ed episodi simili mi danno l'impressione di un atteggiamento, da parte della microsoft, che spero rimanga una mia impressione: e cioè quella di un'azienda che va per la sua strada e cerca di imporre in tutti i modi il _suo_ personale modo di fare e vedere le cose, e che si "arrende" e cede ai metodi altrui solo quando ci è costretta dalla pressione della loro popolarità, del mercato o altro. Questo del OOXML mi sembra solo un ennesimo episodio della solita storia.

"A proposito: se hai tempo, sarebbe interessante una spiegazione dei vantaggi di OOXML rispetto a ODF. Perché tenere in piedi due standard, se ne basta uno?"
"Vantaggi" è opinabile; piuttosto parlerei di "differenze". Piuttosto, ripeto la domanda di Paolo: perchè tenere due standard, o meglio, perchè cercare con tanta insistenza di introdurre un altro standard aperto per il testo quando ne esiste già uno da diverso tempo? Come dice Edo, questo rischia solo di creare confusione e complicazioni nel mercato del software? Non è microsoft sta cercando di sfruttare tale confusione a suo vantaggio..?

Andrea Valboni ha detto...

Salve a tutti e grazie per i commenti al post di ieri. Non era mia intenzione rispondere solo a Paolo e non agli altri, è stata solo una questione di tempo, ero in fine giornata e un pò stanco, avevo voglia di andare a casa, niente di più e niente di meno. Mi interessa confrontarmi su queste cose con tutti, perchè c'è sempre da imparare; le questioni che sollevate sono molte, spero di riuscire ad indirizzarle tutte, almeno ci provo.
Un punto mi pare in comune, ed è una domanda che molti si sono fatti: perchè due standard? Non potevamo adottare ODF fin dall'inizio?
Non sono sicuro di avere tutti gli elementi per rispondere, ma di una cosa sono abbastanza certo: quando fu presa la decisione di virare verso un formato XML e abbandonare i formati proprietari (che chiamo binari, lo so che i termini significano cose diverse, ma spesso riferendosi a Microsoft vengono usati in modo interscambiabile)si pose il problema centrale: evitare quello che successe a cavallo del 97/98 cioè cercare di evitare discontinuità e incompatibilità con i formati precedenti. La scelta di non adottare ODF sta nella impossibilità per ODF di recuperare il pregresso (che non è solo .doc) con un alto livello di fedeltà, o almeno quanto più possibile.
OOXML, derivato dal WordML e affini del 2003, ha fin dall'inizio dovuto dare una risposta a questo problema, e contemporaneamente essere idoneo per divenire uno standard.
Il voler procedere ad un processo di standardizzazione non era per dare noia ad ODF (non abbiamo fatto ostruzionismo in OASIS dove siamo presenti, nè in ANSI, quando fu proposto come standard nazionale), ma perchè altrimenti OOXML sarebbe stato un altro formato proprietario, XML sì, ma comunque proprietario; il passaggio a standard era necessario anche e richiedeva un impegno a non far valere i diritti di proprietà intellettuale per poter poi affidare la sua evoluzione ad un organismo internazionale. Anche grazie alle pressioni in ambito europeo e IDABC in testa, dovevamo necessariamente standardizzare il nuovo formato XML.
Credo che ODF e OOXML abbiano loro pregi e difetti, se li si guarda dal punto di vista tecnico e si analizzano come specifiche tecniche di standards: onestamente non saprei dire quale dei due sia tecnicamente superiore. OOXML ha un linguaggio di macro, ODF no, le caratteristiche di accessibilità sono diverse, e su entrambi i fronti si lavora per migliorarle, questi sono alcuni macropunti. Il Fraunhofer Institute ha fatto un documento di confronto, si vede chiaramente che le architetture documentali sono diverse, così come è diverso architetturalmente lo standard cinese UOF da ODF, vedete cosa dice http://www.wikipedia.org alla voce UOF:
“At the "WTO IPRs Issues in Standardization" conference in Beijing (April 2007), convened by the Chinese Ministry of Commerce, the China State Intellectual Property Office (SIPO) and Sun Microsystems, Scott McNealy, the Chairman of Sun Microsystems called for a merger of OASIS/ISO's ODF and China's UOF.[4] While both formats are open, there are significant technical challenges in achieving a merger, as the two formats have made different fundamental choices in how to describe documents.[5][6]”
Durante il BRM a Ginevra, come delegazione italiana portammo una richiesta di armonizzazione degli standard; però fare uno standard vuol dire portare delle proposte tecniche, e non solo buone intenzioni e noi di proposte tecniche non ne avevamo. Visto che il Brasile aveva avanzato simile richiesta, chiesi ad un rappresentante della delegazione Brasiliana se voleva presentare una proposta tecnica su almeno uno dei 16 punti di possibile convergenza assieme alla delegazione italiana (mi ero fissato sulle tabelle). Ma la risposta fu che non c’era tempo, i due formati erano troppo diversi per poter fare una proposta tecnica anche solo su un punto nell’arco del BRM.
Spero di aver dato un’idea su questo aspetto e del perché non era e non è al momento usabile ODF come formato di transizione, ma mi rendo conto che l’argomento è di quelli che richiederebbero paginate.
Il punto ora diventa: ma si può sperare in un’unificazione per il bene di tutti? Io credo di sì, anche se la strada non è breve, bisogna però iniziare a percorrerla. La creazione dell’Ad Hoc Group 2 nell’SC34 del JTC1 ha anche questo obiettivo, ma tutti i partecipanti sanno che ci sarà da rimboccarsi le maniche.
Per inciso, in ISO sono attualmente in corso altri processi di unificazione di standard diversi, ad esempio sui font; è stata fatta una proposta di unificare o almeno armonizzare le diverse proposte tecniche relative ai Resource Description Framework. Da questo punto di vista, ODF e OOXML non sono una storia diversa, ma sicuramente è molto più visibile ed ha implicazioni più estese.
Se non vi ho annoiato, provo a rispondere anche ad alcuni altri punti:
@Francesco: il livello di supporto ad ODF sarà paragonabile a quello dei convertitori su source forge? Non te lo so proprio dire, però considera che sono due progetti diversi. Quello dei “translators”, che continueremo a supportare, è fatto da una community, il supporto interno ad Office seguirà l’iter di prodotto. Il che non vuol dire che sia necessariamente più fedele, solo che avrà un ciclo di qualità diverso.
@edo: non sei l’unico che non prova simpatia per MS, penso sia lo stesso motivo per cui io e altri miei coetanei hanno provato sentimenti analoghi per altre aziende….è un ciclo che si ripete. Errori ne abbiamo fatti e ne faremo, ogni azienda che vuole avere un ruolo di leadership inevitabilmente fa errori: l’importante è saperli riconoscere e correggersi. E credo che questo Microsoft lo faccia, si possono dire molte cose di questa azienda ma non che non abbia il coraggio del cambiamento continuo, e ti posso garantire che lo viviamo giornalmente. D’altro canto, chi non ha saputo cambiare è scomparso.
Su IE8 non sono ferratissimo, ma se non lo conoscete consiglio la lettura di questo articolo, a me ha dato elementi di riflessione: http://www.joelonsoftware.com/items/2008/03/17.html, soprattutto in merito a cosa sono gli standard nel mondo di internet.
Il motivo per cui abbiamo voluto che OOXML divenisse uno standard penso di averlo chiarito, ma bisogna anche riflettere su una cosa. Microsoft ha prodotto un formato che si chiama Office OpenXML, poi lo ha portato in ECMA per iniziare il processo di standardizzazione; qui ha lavorato un comitato tecnico (tra cui c’erano anche Apple e Novell, oltre ad una altra dozzina di soggetti) che ha prodotto lo standard ECMA 376, di 2000 pagine più spesso dell’OOXML originale. Office 2007 è allineato a questo standard. L’ECMA 376 ha prodotto l’IS29500, che ha un migliaio di pagine in più rispetto all’ECMA 376. Ci sono stati dei cambiamenti importanti nel corso del processo di standardizzazione in ISO, e questo richiede un lavoro di allineamento non impossibile ma che pone un problema: quando allineare? La decisione di farlo con la prossima versione di Office pare essere quella che ha riscosso maggiore gradimento dai clienti e dagli sviluppatori. Si può fare di meglio? Forse sì, e se il mercato ce lo dirà lo faremo.
@Dan: ci sono strade diverse che portano alla creazione di uno standard, talvolta nei comitati di standardizzazione, altre volte dal mercato (vedi Java); chi cerca di fare innovazione mette sul mercato prodotti che, per essere innovativi, si portano dietro delle implementazioni che alla prima uscita sono necessariamente proprietarie. Non vuol dire che per questo uno voglia fare come gli pare infischiandosene di tutti, è il meccanismo che sta dietro al processo di innovazione che porta al fatto che le cose possano succedere così. Se però, in funzione anche di una posizione dominante di mercato, capisci che alcune delle tue componenti tecniche sono critiche ai fini dell’interoperabilità, allora si pone il problema etico di come comportarsi nei confronti della concorrenza. L’importanza dell’annuncio che abbiamo fatto a Febbraio sull’interoperabilità sta qui: nel rendersi conto (qualcuno potrebbe dire: finalmente!!) che dovevamo avere un atteggiamento più responsabile e quindi dare accesso a tutta una serie di specifiche tecniche di protocolli proprietari alla base dell’interoperabilità delle nostre piattaforme. Da Febbraio, sono state scaricate oltre 200.000 copie di specifiche tecniche di protocolli di prodotti vari: Exchange, SharePoint oltre ai protocolli client e server di varia natura. Tutto quello che abbiamo prodotto nell’ambito del WS-* (dove abbiamo dato credo un grosso contributo alla standardizzazione dei protocolli dei web service) è liberamente accessibile. Anche questo fa parte del cambiamento, ma credimi: a me convince di più il processo che stiamo portando avanti, un passo alla volta, ma in modo deciso, di chi si è schierato notte tempo dalla parte dell’opensource rimanendo di fatto ancorato ad un modello commerciale puro, e ne conosco un tot.