Carlo Daffara has been a part of the “libre” IT world for more than 20 years, working as a researcher in 8 European Commission projects (among them COSPA, one of the largest migration experiments to an open desktop for public administrations in Europe), moving freely from technology adoption processes, experiments in extending open source to the material world, being an entrepeneur (twice), cofounder of one of the first open source consortia, working for companies like Pfizer, Ansaldo or Insiel, health care institutions like the Beaumont hospital or the Besta neurological institute, administrations like the Friuli, Veneto and Piedmont regions, and even support for development countries along with the United Nations International Open Source Network. Member of the FSFE European Legal Network, of OSI Policy and Economic Development group, chairs the Editorial board of the cloud standardization initiative SIENA and several other working groups, especially in the European context. Carlo Daffara has transformed the largest survey of open source business models in the FLOSSMETRICS project into a methodology for helping companies explore and develop their own adoption process for turning open source into a market and development opportunity.

For these and other reasons I felt he was the right person to understand what is behind and beyond the paradigm of open source, today and tomorrow. 

(Italian translation of the post follows here – La traduzione in italiano è disponibile)

[Simone Cicero]: For years, we have talked about the differences between Free Software and Open Source software, about confusing terms and concepts, about principle (sometimes) or substantial differences: this discussion was crucial. Today that these solutions are “mainstream” does it still make sense to discuss matters of principle? Is there still a substantial difference between Free Software and Open Source Software? how much room do we still have discussing rights and Freedom, when it comes to what has become, effectively, a commodity? (SW)

[Carlo Daffara]: The problem originates from the intersection of different aspects and different communities; as such, it tends to create a strong polarization among people.

First of all, the only, real definition of both Free Software and Open Source is a purely legal one: software distributed under a Free license (for FSF) or Open (for OSI).  If we take an in-depth look, licenses are pretty much the same – so the two definitions at the moment coincide (apart from the two largely unused licenses RPL and NOS). In theory there should be no clash between the two “sides”, since the two definitions describe mostly the same things; but the reality is that those are ideological positions, and as for many political and philosophical movement they feel themselves differentiated more for the underlying motivations than for the reality of their actions.

I have chosen a more, let’s say, “mathematical” position. If the distinction between two set is largely irrelevant, I consider them more or less the same – so for me the difference between Open Source and Free Software is so small as to be irrelevant. Both definitions allow the user to enjoy the set of freedoms that are essential from a philosophical and practical point of view.

A different phenomenon, that’s more important to me, is the dilution of the term “Open”. For a long time (and partially even today) Free Software was seen as gratis (a perceived association with price more than freedom). In a similar way, there are vendors that sell products as open source under a definition that’s so wide that you can put anything in it.

When I act as a consultant, I suggest my customers to check the license under which a product is issued, the source availability and whether the source covers all of a product or only a part. During the FLOSSMETRICS project we found a substanital percentage of companies (around 10%) that were supposed to be providing an open source product, but in fact did not meet any of those conditions – thus making the choice of a product much more risky.

[SC]: What is the future of the Free Software Foundation and Open Source Initiative? is it a common future?

[CD]: My hope goes to a form of collaboration that is more broad and less “political”. The first steps taken together seem promising, for example the joint statement on the sale of Novell patents to CPTN, I would be happy to see this initial collaboration to expand further.

[SC]: Is it possible that the winning approach, if we think about projects such as Android, is that of pragmatism, in a sense of limiting project democracy, for example with the anti fragmentation agreement, in favor of a greater capacity to deliver value?

[CD]: The “pragmatism” that you mention is really the result of a confusion between projects with the same name but different licenses. Android, commonly used as an example, in its open source side has no anti-fragmentation clause; Google has in this sense no discretion in preventing changes or fork. The parts Google has a power to control are the closed source apps (like GMail, the Android Market, and so on) that can be distributed only after signing one or more contracts that, among other things, affect not only the basic choices of the carrier/OEM itself but also its ability to change the product.

Noone (including Google) could stop a carrier that wants to take the truly open source Android code, add the missing parts and create a new configuration. China Mobile oPhone project was a first attempt and it is possible for other to try it as well (ed: actually oPhone project seems going to be discontinued, so the attempt to fork Android is tough also for China Mobile).

[SC]: I agree but I wonder how many chances of success of has an Android fork. In general what success could, a fork that can not access the original ecosystem (the apps, if we talk about Android), or that suffers from hardware incompatibilities, have? In this sense, a pragmatic governance model do even if not much democratic, has right to exist? Don’t you think that’s what was missing for GNU / Linux?

[CD]: The problem with GNU / Linux is a structural community problem, that sometimes pushed for a set philosophical choices that were counter-productive and clashed with the user’s needs. The drive for usability largely came from meta-projects, such as those from Novell, Canonical, Red Hat, KDE, Gnome, which have invested heavily (along, of course, the individual communities) to package an experience that at the moment is on a par with that of their proprietary counterparts. Android also takes a set of projects and package them for a better user experience, similar to what was done with Maemo and now Meego.

About the forks there are many possible answers: if a community emerges and is self-sustaining (eg Debian, KDE), we can surely imagine an Android open community. It’s obvious that he would probably follow closely the original project, until the fork takes its own life, as is happening with LibreOffice – that is showing extraordinary activity in a very short time. It is still an economic problem: if the cost of Googlès governance becomes more than the the cost of handling a fork, you can be sure that soon a fork starts and will grow. If this differential is small, the odds of such a fork to succeed will be small as well.

In general, the problem of governance can be overcame – the important thing is that there should be a plan, a direction that meets the needs of users. If a project runs counter to their user base, a fork usually is created and gets a life of its own.

[SC]: Don’t you think is time to talk (and consolidate) open governance models instead of only open source? What it takes to make a project truly collaborative further than granting access to sources?

[CD]: Governance is one of the aspects of my “Triaxial” evaluation model: license, development, sustainability (ed: see this). The licensing model relies simply on both OSS or FS definition: the license under which a product is released must be one of the recognized licenses from the foundations. The development model is independent from the license: it describes third parties collaboration barriers or enablers, and matches the concept of project “governance”. In fact, there are open source projects, released under the GPL, in which outside contributions are not accepted (for example projects that have a specific safety validation), exactly like there are proprietary projects that accept external contributions. Part of the communication problems of the FLOSS world stems from the confusion between licenses and development model, which are considered to be coincident but are not (always).

On governance in general, there are a number of issues that may or may not become the subject of external contribution: beyond code, there are meta-issues such as roadmap, policy of patch acceptance, forums … Simon Phipps has created an effective scorecard  to evaluate many of these issues, and is currently the best tool not only for those who must assess the openness of a project, but also for the developers themselves – in order to have a guide to decide in a transparent manner what kind of evolution they can give to their projects.

[SC]: What do you think of the proliferation of code related legal conflicts? Given the increasing complexity (to refer again to Android, we’re talking 15 different licenses, 80k members, 2GB of code) how do you think we can move further? Are legal implications something we will never overcome? We need a new license or are the major problems related to patents, that in some sense, are excluded from the license policy?

[CD]: The problem of different licenses comes up in a very natural way when you integrate a large number of projects – it is a physiological fact, that hardly leads to problems (any incompatibility usually is easily overcame, and is more often due to deficiencies in the verification process than to willful violations). Sometimes the problem stems from embedded applications – the supplier may not be fully aware of the characteristics of the various licenses, and in that case it’s mainly a problem of information and, sometimes, enforcement (GPL-Violations is very active in this sense). A far more ‘serious’ problem is embodied by software patents, especially broad patents or patents on technologies so basic that basically any software that gets distributed breaches it.

There is an extraordinarily intense debate over software patents – whether or not are useful, how to reduce the social cost of “patent trolls” and so on. The possible solutions are different, some of which are also under discussion at the USPTO. In general, just by eliminating too “broad” patents or those with obvious prior art would greatly reduce the problem. Preventing non-performing entities (companies whose sole purpose is to seek fees on patents owned) to invoke patent infringement suits and seek damages even though it may not prove the existence of an economic damage would also help, like requesting that a patent filing must contains a working implementation of the patent (not only a simple pseudocode or flowchart). The issues related to licensing are, in comparison, much simpler and easier to solve.

[SC]: Leaving the world of software, the paradigm of “open” is occurring throughout many other areas, from hardware to data centers (eg opencompute) from public data to the collaborative design of large projects. You have already addressed the issue: could you give us an idea of other playgrounds the open paradigm has proved to work?

[CD]: In general, the collaborative model works well when there are technological tools to enable collaboration. For example, collaboration in architecture has become easier with the rise of collaborative CAD tools, that perform better than simply transmitting dozens of files back and forth. With the gradual transformation of atom based objects in digital artifacts of systems, circuits and models the collaborative landscape will continue to spread more and more.

In the OpenTTT project I have found many examples of collaborative development from agriculture to mathematical models for pharmaceuticals, even prayer books. The benefits of collaboration and openness that we see now in the software world will be seen in the same way in the world of non-software as computer representations of physical artifacts will improve in quality, as well as with improved collaboration tools.

[SC]: Do you know of new fields in which the application of the open, collaborative paradigm should perform well?

[CD]: The collaborative model is still poorly adopted outside of the software world – there are only a few instances that can be considered a success. it is very difficult to imagine what could be the evolution of an ecosystem in which such cooperation becomes massive and affects a large number of projects: if I had to choose a specific area, I believe that creative production can be an interesting field (just look at the phenomenon of “fan fictions”, in which the reviewers work together to improve texts), and physical models to be created using the 3D printers (such as RepRap). If – as I think – now we are at the beginning of the “S” growth curve typical of these phenomena, I believe that the more interesting opportunities will arise fast and will be totally unexpected.

[SC]: In my opinion we are experiencing a sort of infrastructure singularity on the web: the advent of the *aaS paradigm, coupled with the definitive take-off of OSS has made the development of new online products truly immediately (standard-oriented interfaces, scalable platforms) and quite cheap.

I remember a few years ago, I was attending a Red Hat Open Source Day in Rome and Jan Wildeboer called this, the era of “Build and Play“. You are an expert in open source and embedded software, as well as distributed systems: how the collaborative development paradigm will integrate with the Everything as a service mantra?

[CD]: The most important consideration is economic: an open device or an open service that is able to crystallize around itself an ecosystem of independent actors *always* grows more rapidly than one that is not. This goes against many of the rules previously considered valid for products (especially in the consumer area), in which the manufacturer should be the only one to control the ecosystem of accessories so that it can maximize profits.

The reality is that the modern world is too big and complex for a single manufacturer – however large – and, although the closed ecosystem can lead to a higher profit margin at the start (ed: Android vs. IOS) the open one will eventually win. Another aspect that has become important in recent years is time to market: an open system grows and occupies more rapidly new niches and in a less expensive manner. As an example, Palm to create its WebOS reused 106 different products, for a total of 1.2GB of source code to which they had to apply only 4.58% of changes (see details here),  it thus reduced its development time (and cost) in an extraordinary way. Android follows a similar path, even if the code created from scratch by Google in this case is substantially higher, around 25% (details here).

This type of advantage is so strong that it makes any other choice fundamentally uneconomic: that’s why the reuse model has expanded so rapidly, despite the hesitation of CEOs to adopt open source solutions.

[SC]: Open Source, Open Data, Open Hardware: is this the only the Internet of Things that can guarantee the real technological advance expected by Cyborgs and Transhumanists? Will the constraints that vendors will impose inevitably will put the brakes to this development?

[CD]: As I said before, I believe that ‘openness’ in itself has so many advantages that it will become an unstoppable movement, even considering that there will certainly be attempts to go in the other direction (patents, DRM, licensing, and so on). The worldwide Open Science and Open Access movement that is pushing for new models of research and production of pharmaceuticals designed for developing countries is an example of this conflict between a traditional market needs and a part of the world population that is currently excluded from that kind of goods. Health care (medicine, proteomics, genomics, prosthetic instruments) is one of the areas where this tension is more visible, due to the obvious conflict between big pharma profits and human needs. The same technological conflict will soon be evident in all other areas such as literature, music and so on. Maybe I’m optimistic, but I think the barriers that are imposed from outside hardly stand the pressure of humanity against them.

Mine is a vision of the evolution of the economic fabric of the world, of which software is a part. Imagine a company that – thanks to free software – manages to introduce better and cheaper products in a shorter time. If, as it has proven several times, this advantage is stable and repeatable other companies will inevitably have to adapt and work together, or must spend more to keep up and lose their advantage anyway.

The same goes for public bodies: with budgets decline they will have to do more, with less, by connecting systems that were created to be mutually incompatible. Open Systems allow to do it, and do it better. With successive IT generations the benefits are multiplied, so the open systems always win in the end.

The incumbents who do not want to lose their positions can take advantage from lobbying (as the various actors of copyright protection and patents do), but they are struggling with their own users, adding to the cost of goods or services the cost of “supervision” and of the measures needed to exclude non-paying users from consumption. In my (very optimistic) point of view legal means cannot keep up with this inefficiencies forever. As the TCP / IP won over OSI and all the rest, open systems have too many advantages from all points of view to be stopped by the proprietary world.

Tweet this

Italian translation follows.

Cosa c’è dopo e oltre l’Open Source.

Carlo Daffara è una voce importante nel mondo “libre” IT da più di 20 anni, spesi lavorando come ricercatore in 8 progetti della commissione Europea (tra i quali COSPA, una delle più grandi migrazioni verso il desktop aperto per le amministrazioni pubbliche in Europa), muovendosi tra tecnologia, processi di adozione, esperimenti per estensione del paradigma open source nel mondo “materiale”. Carlo è un imprenditore (due volte), co-fondatore di uno dei primi consorzi open source, e ha lavorato per aziende come Pfizer, Ansaldo o Insiel, per istituzioni di salute pubblica come l’ospedale Beaumont o l’istituto neurologico Besta, pubbliche amministrazioni italiane come la regione Friuli, Veneto e Piemonte, e anche a sostegno dei paesi in via di sviluppo tramite l’International Open Source Network delle Nazioni Unite.
Membro della FSFE European Legal Network, e dell’OSI Policy and Economic Development group, presiede il Comitato di redazione della iniziativa di cloud standardization SIENA  e diversi altri gruppi di lavoro, in particolare nel contesto europeo. Carlo ha inoltre trasformato il più grande studio di modelli di business open source, il progetto FLOSSMETRICS , in una metodologia per aiutare le aziende a esplorare e sviluppare un proprio processo di adozione per trasformare l’open source in una opportunità di mercato e di sviluppo. Per questi ed altri motivi ho ritenuto che fosse la persona giusta per capire cosa c’è dietro e oltre il paradigma open source, oggi e domani.

[Simone Cicero]: Per anni, parlando di differenze tra Free Software e Open Source software, della confusione tra termini e concetti delle differenze di principio (a volte) e sostanziali (in alltre) è stato cruciale. Oggi che queste soluzioni sono “mainstream” ha ancora senso secondo te discutere questioni di principio? Esiste ancora una differenza sostanziale tra Free Software e Open Source Software, e quali impicazioni e spazio hanno ancora i diritti e le Libertà quando si parla di quella che è diventata a tutti gli effetti una commodity? (il SW)

[Carlo Daffara]: Il problema deriva dall’incrociarsi di aspetti diversi tra loro, che poi (vista l’esistenza di community diverse) porta a una sorta di polarizzazione tra le parti. Cominciamo con un distinguo: la vera, sola definizione sia di software libero che di open source è una definizione puramente legale: significa software coperto da una licenza Free (per la FSF) o Open (per OSI).

Se andiamo a guardare bene, le licenze sono le stesse – per cui le due definizioni, al momento, sono coincidenti (a parte alcune marginali eccezioni, la RPL utilizzata da un unico prodotto, e la NASA OS agreement, usata da una trentina di software scientifici e per lo sviluppo). In teoria non dovrebbero esserci quindi scontri tra le due “fazioni”. La realtà è che si tratta di due posizioni ideologiche che, come molti movimenti politici e filosofici, si ritengono distinti per la motivazione che è alla base delle scelte, più che per le scelte stesse. Nel mio piccolo ho scelto la posizione, per così dire, matematica presentata sopra: se tra due insiemi non vi sono differenze nell’istante T, i due insiemi sono identici. Per cui non mi pongo in modo stretto il problema; entrambe le definizioni consentono di godere di quell’insieme di libertà che, indipendentemente dal nome, sono secondo me essenziali – sia da un punto di vista filosofico che da quello più pragmatico e pratico.

Un aspetto diverso, e sostanzialmente più importante secondo me, e il fenomeno della “dilution” del termine Open. Cosi’ come per molto tempo (e in parte anche ora) il Free Software era visto come “gratuito” (quindi veniva percepita una associazione con il prezzo più che con la libertà) adesso ci sono vendor che spacciano prodotti come “open source” sotto una definizione di Open talmente larga da farci passare qualsiasi cosa. Questo è un aspetto diverso dalla definizione legale, e riguarda più gli aspetti di scelta, di selezione del software, di evoluzione nel lungo periodo; la cosa che di solito suggerisco nella mia attività di consulente è di verificare sotto che licenza viene rilasciato un prodotto, se il sorgente è disponibile e se il sorgente ottenuto corrisponde al prodotto o solo a una sua parte. Durante il progetto FLOSSMETRICS abbiamo trovato una percentuale non tanto piccola (attorno al 10%) di aziende che parlavano di prodotto open source, ma in realtà non rispettavano almeno una di queste condizioni – rendendo quindi la scelta di un prodotto molto più rischiosa.

[SC]: Quale futuro pensi possano avere Free Software Foundation e Open Source Initiative? un futuro comune?

[CD]: La mia speranza è quella di una forma di collaborazione più stretta, e meno “politica”. I primi passi fatti assieme mi sembrano promettenti, ad esempio nel joint statement sulla vendita dei brevetti di Novell alla CPTN; sarei felice di vedere questa collaborazione allargarsi ulteriormente.

[SC]: Credi sia possibile che il principio che è andato affermandosi nel tempo, se pensiamo a progetti quali ad esempio Android, sia quello del pragmatismo, teso in un certo senso anche a limitare la democrazia in questo tipo di progetti (si pensi all’anti fragmentation agreement) in favore di una maggiore capacità di deliverare?

[CD]: Il pragmatismo che viene presentato è in realtà una confusione tra progetti con lo stesso nome e licenze diverse. Android, comunemente utilizzato come esempio, nella sua parte open source non ha alcuna clausola anti-frammentazione, nè Google ha alcun potere nell’impedire modifiche o fork. Quello su cui Google ha un potere è la parte proprietaria (le applicazioni come GMail, l’Android Market, e cosi’ via) che sono utilizzabili da un carrier solo dopo l’adesione a uno o più contratti di collaborazione che, tra le altre cose, condizionano non solo le scelte di base del carrier stesso ma anche le sue possibilità di modifica. Se un carrier volesse, potrebbe prendere la parte veramente open di Android, aggiungere le parti mancanti e poter creare la configurazione che vuole, senza nessuna possibilità di interferenza da parte di Google o altri; il passato progetto oPhone di China Mobile era un primo tentativo, e non è detto che non ne nascano altri.

[SC]: Sono d’accordo ma mi chiedo: quante probabilità di successo ha un fork di Android? In generale, un fork che non può accedere all’ecosistema originario, per esempio dei contenuti (le app, se parliamo di Android) che soffre di incompatibilità hardware. In questo senso, un modello do governance pragmatico anche se poco democratico, ha ragione di esistere? Non credi sia un po’ quello che è mancato a GNU/Linux?

 [CD]: Il problema di GNU/Linux è in parte un problema strutturale della community che lo ha spinto, in modo a volte controproducente, con una base filosofica che si scontrava con le esigienze degli utenti. La spinta verso l’usabilità è venuta in larga parte da meta-progetti, quali quelli di Novell, Canonical, RedHat che hanno investito pesantemente (insieme naturalmente alle singole communities) per pacchettizzare una esperienza che, al momento, è alla pari di quella delle controparti proprietarie. Anche Android prende un insieme di progetti e li pacchettizza per una migliore user experience, così come è accaduto per Maemo e poi Meego. La pacchettizzazione può avvenire anche in progetti democratici, se c’è un progetto dietro: KDE è un ottimo esempio di questo.

Sul problema dei fork, le risposte possono essere molteplici: se una community emerge ed è in grado di autosostenersi (ad esempio Debian, KDE) non vi sono ragioni per cui non possa emergere una large community dietro a una versione libera di Android. è ovvio che sarebbe sempre indietro, rispetto all’originale, fino al momento in cui il fork non prende vita propria – come sta succedendo a LibreOffice, che sta mostrando una attività straordinaria in brevissimo tempo. Si tratta sempre di un problema economico: se il costo della governance di Google diventa superiore al costo di gestire un fork, puoi stare sicuro che in breve tempo un fork nasce e cresce anche con successo; se invece tale differenziale rimane piccolo, rimangono piccole anche le probabilità che accada.

In generale, il problema della governance è spesso un problema superabile; la cosa importante è che ci sia un progetto, una direzione che vana incontro alle esigienze dei suoi utenti. Se un progetto va contro alla propria user base, o il progetto muore o si crea un fork che poi vive di vita propria.

[SC]: Non sarebbe ora di parlare (e consolidare) di modelli di open governance e non di “open source“? Mi spiego: cosa ci vuole piu che l’accesso ai sorgenti per rendere un prodotto veramente collaborativo?

[CD]: La governance è un altro degli aspetti presentati nel mio modello “triassiale”: licenza, sviluppo, sustainability (cfr. qui per i dettagli). Il modello di licenza è semplicemente la definizione di OSS o FS: che la licenza sotto cui un prodotto viene rilasciato sia una delle licenze riconosciute dalle rispettive fondazioni. Il modello di sviluppo è indipendente dalla licenza; descrive le barriere o i facilitatori alla collaborazione da parte di terzi, e combacia con l’aspetto di “governance”. Esistono progetti open source, sotto licenza GPL, in cui non sono accettate collaborazioni dall’esterno (ad esempio i progetti che hanno una validazione di sicurezza specifica), così come ci sono progetti proprietari che accettano collaborazioni. Parte dei problemi nella comunicazione del mondo FLOSS derivano dalla confusione tra licenza e modalità di sviluppo, che vengono ritenute coincidenti ma non lo sono (sempre).

Sulla governance in generale, ci sono una serie di aspetti che possono o no diventare oggetto di una partecipazione esterna: al di là del codice, vi sono meta-aspetti quali la roadmap, la policy di accettazione delle patch, i forum… Simon Phipps ha creato una efficace scorecard per valutare molti di questi aspetti, e rappresenta al momento lo strumento migliore non solo per chi deve valutare la openness di un progetto, ma anche per gli stessi sviluppatori – in modo da avere una guida per decidere in modo trasparente che evoluzione dare al proprio progetto.

[SC]: Cosa ne pensi del proliferare dei conflitti legali sul codice? Data la complessità crescente (per fare riferimento ancora ad Android, parliamo di 15 licenze diverse, 80k componenti, 2GB di codice) come pensi sia possibile andare oltre? Le implicazioni legali sono qualcosa che non riusciremo mai a eliminare? C’è bisogno di una nuova licenza o i problemi maggiori sono legati ai brevetti che, in un certo senso, derogano dalle license?

[CD]: Il problema delle licenze diverse sorge in modo naturale quando si integrano un numero elevato di progetti – si tratta di un fatto fisiologico, che difficilmente porta a problemi (le eventuali incompatibilità di solito si sanano facilmente, e sono più dovute a mancanze nel processo di verifica più che a volontarie violazioni). A volte il problema deriva da applicazioni embedded, dove magari il fornitore non è a conoscenza delle caratteristiche delle varie licenze, e in quel caso si tratta di un problema di informazione e eventualmente di enforcement (gpl-violations è molto attivo in questo senso). Un problema ben più grave è dato dai brevetti sul software, in particolare dai brevetti particolarmente estesi o su tecnologie così basilari da garantire che ogni software distribuito più o meno lo infranga.

C’è al momento un dibattito straordinariamente intenso sui brevetti software – se siano o no utili, come ridurre il costo sociale dei “patent troll” e così via; le ricette sono molte e alcune sono anche in discussione in questi mesi presso l’USPTO. In generale, già eliminare i brevetti troppo “allargati” o con evidente prior art ridurrebbe di molto il problema, così come impedire alle non-performing entities (aziende che hanno come unico scopo quello di chiedere fees sui brevetti posseduti) di invocare la violazione di brevetti e chiedere danni nonostante non ne possano dimostrare la consistenza, o che la richiesta di deposito del brevetto contenga una implementazione funzionante del brevetto stesso. Gli aspetti legati alle licenze sono di gran lunga meno preminenti e difficili da risolvere.

[SC]: Uscendo dal mondo del software, il paradigma “open” sta pervadendo molti altri campi, dall’Hardware, ai data center (es: opencompute), dai dati pubblici, al design collaborativo di grandi progetti. Tu che hai già affrontato il tema (rif: tua presentazione) ci potresti dare un’idea di dove il paradigma ha dimostrato di funzionare bene?

[CD]: In generale il modello collaborativo funziona bene quando vi sono gli strumenti tecnologici per consentire la collaborazione stessa. Ad esempio la collaborazione in architettura è diventata più facile con il nascere degli strumenti CAD collaborativi, o di metodi di collaborazione piùsemplici dell’invio avanti e indietro di decine di file. Con il progressivo trasformarsi in artefatti digitali di oggetti, sistemi, circuiti, modelli il panorama collaborativo continuerà ad estendersi sempre più; nel progetto OpenTTT abbiamo trovato esempi di sviluppo collaborativo di trattori, modelli matematici per la medicina, persino libri di preghiere. I vantaggi che già adesso si osservano nel software si vedranno allo stesso modo anche nel mondo del non-software via via che le rappresentazioni fisiche troveranno un buon incontro con le rappresentazioni al computer, e con il migliorare degli strumenti di collaborazione.

[SC]: Hai idea di nuovi campi in cui l’applicazione del paradigma “open”, collaborativo, possa e debba ancora dire la sua?

[CD]: Il modello collaborativo è ancora relativamente poco applicato fuori dal software – ci sono solo pochi esempi, relativamente diffusi, ma comunque pochi. è molto difficile immaginare quale possa essere l’evoluzione di un ecosistema in cui tale collaborazione diventa massiva e su un numero di progetti elevato; se dovessi scegliere un ambito specifico, credo che la scrittura creativa possa essere un primo ambito interessante (basti vedere il fenomeno della “fan fiction”, in cui i reviewer collaborano a migliorare i testi), oppure i modelli fisici da creare tramite le 3D printers come il RepRap. Se adesso siamo ai piedi della curva di crescita tipica di questi fenomeni, credo che le opportunità più interessanti saranno totalmente inaspettate.

[SC]: A mio parere stiamo vivendo una sorta di singolatità infrastrutturale sul web, l’avvento del paradigma *aaS, accoppiato con l’affermazione definitiva dell’OSS ha reso lo sviluppo di nuovi prodotti online veramente immediato (orientato a interfacce standard, scalabile) ed economico.

Ricordo che, qualche anno fa ad un’Open Source day a Roma Jan wildeboer si riferì , a praoposito, all’era del “Build and Play“. Tu sei un’esperto di open source e embedded software, oltre che di sistemi distribuiti: come immagini che il paradigma dello sviluppo collaborativo possa integrarsi con il web dell’ Everything as a service?

[CD]: La considerazione più importante è di tipo economico: un device aperto, o un servizio aperto che riesce a cristallizzare attorno a sè un ecosistema di attori indipendenti vale di più e cresce più rapidamente di uno che non lo è. Questo va contro a molte delle regole ritenute valide per i prodotti (in particolare consumer), in cui se il produttore è l’unico a controllare l’ecosistema degli accessori ne può massimizzare il profitto. La realtà è che il mondo moderno è troppo grande e complesso per un singolo produttore, per quanto grande sia; per cui un sistema aperto “cresce” più in fretta e meglio di uno chiuso, anche se al principio può portare al suo creatore un margine di guadagno più alto. (Ndr: Android vs iOs) Un altro aspetto che è diventato importante negli ultimi anni è la velocità, o il time to market: un sistema aperto cresce ed occupa nuove nicchie più rapidamente e in modo meno costoso per il produttore; ad esempio, Palm nel creare il suo WebOS ha potuto riutilizzare 106 prodotti open diversi, per un totale di 1.2Gb di codici sorgenti, a cui ha dovuto applicare il 4.58% di modifiche (qui per i dettagli) riducendo il tempo di sviluppo (e il suo costo) in modo davvero straordinario. Android segue una strada simile, anche se il codice creato ex-novo in questo caso è sostanzialmente maggiore, attorno al 25% (qui per i dettagli) Questo tipo di vantaggio è tale da rendere ogni altro sistema fondamentalmente antieconomico; per questo il modello del riuso si è allargato con tale rapidità, nonostante le titubanze dei CEO ad adottare soluzioni open source.

[SC]: Open Source, Open Data, Open Hardware: è solo questa l’Internet of Things che può garantirci il vero progresso tecnologico atteso da Cyborg e Transumanisti? Abbiamo speranza che possa diventare una realtà o i vincoli che i vendor di tutto il mondo porranno la freneranno inevitabilmente?

[CD]: Come dicevo prima, ritengo che l'”open” abbia in sè tali e tanti vantaggi da farne un movimento inarrestabile, anche se i tentativi per chiuderlo ci saranno senz’altro (brevetti, DRM, licenze e quant’altro). Il movimento mondiale che sta spingendo verso nuovi modelli di ricerca e produzione di farmaci per i paesi in via di sviluppo è un esempio di questo conflitto tra un mercato tradizionale e le esigienze di una parte della popolazione attualmente esclusa. Se la salute (medicina, proteomica, genomica, strumenti protesici) rappresenta una delle aree in cui questa tensione è più visibile per l’evidente conflitto tra la necessità di profitto delle case farmaceutiche e i bisogni umani, la stessa tensione e lo stesso conflitto tecnologico sarà evidente anche in tutti gli altri ambiti, quali la produzione letteraria, musicale e così via. Sarò forse ottimista, ma ritengo che le barriere che vengono imposte dall’esterno difficilmente reggono alla pressione dell’umanità per aggirarle.

La mia è una visione evoluzionistica del tessuto economico di cui il software (e non solo) fa parte. Immaginiamo una azienda che, grazie al software libero, riesce ad introdurre prodotti migliori, a un costo più basso, o più in fretta. Se (come più volte ho dimostrato) questo vantaggio è stabile e ripetibile, le altre aziende dovranno per forza di cose adeguarsi e collaborare, o spendere di più per stare al passo, perdendo quindi comunque il proprio vantaggio.

La stessa cosa per gli enti pubblici: con il calare dei budget dovranno fare di più a meno, collegando sistemi nati per essere tra loro incompatibili, e questo lo si riesce a fare meglio e prima con i sistemi aperti. Con le generazioni IT successive i vantaggi si moltiplicano tra loro, per cui i sistemi aperti alla fine vincono. Gli incumbent che non vogliono perdere le loro posizioni possono sfruttare le lobby (come i vari attori del mondo del copyright e dei brevetti) ma si trovano a combattere con i loro stessi utenti, aggiungendo al costo del bene o servizio il costo del “controllo” e delle misure necessarie a garantire l’esclusione dalla fruizione comune.

Nella mia visione (ripeto: ottimistica) con strumenti legali è possibile contenere per un po’ questo differenziale di efficienza – ma non lo si può fare per sempre. Così come il TCP/IP ha stravinto su OSI e tutto il resto, i sistemi aperti hanno troppi vantaggi sotto tutti i punti di vista per essere fermati.