26 Oct 2012
Ho letto un post che mi stimolato ad una riflessione sulla community, e l'ecosistema open source. Aldo infatti ha pubblicato una dichiarazione interessantissima di Bruno Maag, a capo del team che ha disegnato il font Ubuntu; ve la riporto per intero perché effettivamente merita.
Google con i suoi caratteri liberi, o “libre fonts” come a loro piace chiamarli, è un qualcosa che mi fa particolarmente paura. Vedi, se qualcuno vuole rendere disponibili gratuitamente i suoi caratteri è un affar suo e non ho nulla in contrario. Invece è una cosa molto diversa se una grande realtà aziendale, che ha un valore di mercato immenso, chiede a disegnatori giovani e senza esperienza di inviarle i loro caratteri per poche miserabili migliaia di dollari sotto la condizione di una licenza open source. Per me questo è sfruttamento e anche disprezzo della creatività. Purtroppo il risultato è che in molti casi i caratteri non sono di ottima qualità, visto che sono stati creati da artisti senza esperienza. Il ragionamento di colui che contribuisce è che questo è un modo per far conoscere il proprio lavoro e riceverne un qualche beneficio economico. Ma sono del parere che sarebbe stato molto più proficuo per chiunque se Google avesse investito questi soldi in borse di studio per creativi in modo da far frequentare loro uno stage da qualche parte, oppure per fargli studiare come si progettano i caratteri e, in cambio, poterli aggiungere nel loro sito. Investire così poco nei caratteri è un’offesa, considerato che tutto ciò dà un grosso valore aggiunto ai servizi web di Google. Abbiamo disegnato la famiglia dei caratteri Ubuntu ed è disponibile per tutti sotto una licenza aperta. Ma abbiamo ricevuto un adeguato compenso per crearla, un compenso che riconosce la competenza necessaria per la creazione di caratteri di qualità, sia dal punto di vista creativo che tecnico. Google dovrebbe prendere esempio da ciò.
Molto bene. Effettivamente, si corre sempre il rischio che il proprio repository di software, documentazione o altro diventi un posto dove gli sviluppatori vengono a farsi pubblicità, se non gratuita addirittura pagati da chi ha messo su l'infrastruttura - con moneta, o in altri modi. Questo che viene descritto è il modello di Google, che effettivamente non piace nemmeno a me (almeno per quanto riguarda i font), dato che può accadere sin troppo spesso che uno sviluppatore - si ché possiamo equiparare un designer a un developer ed un font ad un software, almeno in questo caso - prostituisca la qualità del programma in funzione dell'abbassamento del tempo di progettazione, e se questo accade troppo spesso ovviamente incorriamo in un decremento della qualità del codice complessivo. Esistono invece esempi ottimi di come la formazione possa essere un ottimo volano per l'open source.
Casi di studio da cui partire? KDE è finanziato da Blue Systems, la quale oltre che contribuire monetariamente al progetto ha anche assunto gli sviluppatori principali i quali adesso possono dedicarsi totalmente a migliorare la user experience dell'ambiente desktop - che guarda caso è lo stesso che viene usato nelle workstation di tutta la compagnia. La quale, in maniera furbissima, investe in questo modo anche sul proprio outsourcing. Lo stesso Bruno Maag ci ha raccontato di come Dalton Maag abbia ricevuto per l'Ubuntu font un adeguato compenso monetario per la preparazione delle persone nel team.
Altri esempi negativi invece? A dispetto dell'ottimo lavoro di Canonical in altri campi, l'Ubuntu App Showdown è stato, complessivamente, un vero disastro. L'applicazione che ha vinto, Lightread, è ottima, e anche il secondo classificato non se la cava male, ma il resto è stato un piattume mostruoso in cui pochi hanno veramente fatto emergere le proprie qualità, dedicando risorse (mentali) ad un progetto vero invece di presentare esercizi di stile di una difficoltà progettuale prossima allo zero.
Al contrario investendo in formazione, concludendo, viene a crearsi un processo virtuoso in cui si genera un riuso di conoscenza acquisita per soddisfare un bisogno del singolo (azienda o community che sia) per cui, in un lasso di tempo che va da A a B si generano dei cambiamenti a livello mentale, in un gruppo di programmatori, positivi (acquisizione di conoscenza) e persistenti, per cui il nostro differenziale sulla preparazione degli sviluppatori di un progetto sarà necessariamente positivo. Tutto questo con un investimento minimo, non in attrezzatura, non in cicli di clock di una PaaS ma in formazione.
Photo courtesy of Kristina Alexanderson
23 Oct 2012
Questo 27 ottobre si terrà a Roma (contemporaneamente con il Linux Day) CrowdFuture, una conferenza divisa in numerosi workshop che puntano a sensibilizzare gli uditori sulla tematica del crowdfunding in diversi ambiti. Sulla potenza della "folla" si sono già spese troppe parole: uno degli ambiti migliori su cui testare tutto questo è proprio l'open source; ce lo spiegheranno i ragazzi di Goteo, introducendoci al mondo del crowdfunding per le comunità open source (in inglese eh).
Goteo è una piattaforma di crowdfunding spagnola che è specializzata nel crowdfunding di progetti Open Source. Il workshop fornirà una panoramica dei vari modelli di finanziamento collettivo e aiuterà i partecipanti di acquisire skill teoriche e pratiche per usare il crowdfunding sia come strumento di finanziamento sia come strumento di comunicazione per la promozione, sia per la costruzione di una community intorno al prodotto o progetto Open Source.
Quindi:
Orario: 17:00 – 20:00*
Chi: Goteo.org
Target audience: per tutti quelli che hanno una mente “open”, che vogliono imparare a valutare iniziative innovative e sapere come promuoverle e finanziarle tramite canali off- e on-line.
Durata: 3h
Partecipanti max: 25
La parte interessane, oltretutto, è che usando SPECIALCOMMUNITY nel campo coupon potrete applicare uno sconto del 40%.
13 Oct 2012
Oggi Patryk su Twitter ha fatto una domanda abbastanza intelligente: "ma se io se cambiassi licenza (dalla GPL) al mio software nella prossima versione, sarebbe legale?" - ora, a prescindere da tutto, la domanda non è per niente banale, tan'è che la General Public License in un punto ammette proprio che sia possibile cambiare licenza, a patto però che tutti i contributori del progetto siano consenzienti, per ovvie ragioni di proprietà del diritto d'autore e della proprietà intellettuale. Al che è sorto un bel discorso anche con altri; è giusto infatti che da una versione all'altra un software diventi proprietario?
tl;dr: per me si. Ma andiamo per gradi.
Libertà
Come diceva Voltaire, la libertà è tale finché non danneggia quella degli altri; ebbene, a prescindere dai contributor potenziali di un progetto open source, abbiamo da una parte gli sviluppatori e dall'altra gli utenti divisi da un gap abbastanza profondo: gli sviluppatori a volte sono costretti a prendere delle vie che nemmeno a loro piacciono, eppure debbono farlo. E se per qualche motivo al proprietario del diritto d'autore non potesse essere permesso di cambiare la licenza in tempi successivi alla prima versione, questo sarebbe assolutamente restrittivo anche nei confronti dell'artefice del software. E se la libertà è tale finché non danneggia quella degli altri, chissà cosa dovrei pensare di qualcosa che danneggia in primis la mia, di libertà.
In vino veritas
C'è poi il punto fondamentale della "verità del vino", ossia che in alcune occasioni - diciamocelo - mantenere un layer di sviluppo in ottica proprietaria può fare la fortuna di alcuni progetti, anche con successivo rilascio di codice. L'esempio più lampante è quello di una compagnia che vuole imprimere al suo prodotto un form factor caratteristico che magari la comunità distorcerebbe - senza per questo essere nazisti come mi diceva Rosario ieri sera mentre eravamo seduti davanti al nostro lauto aperitivo.
In fondo a volte la comunità è come una donna: nonostante tutto, ci sono casi in cui cerca di cambiare tutto nel software, e quando ci riesce poi dice che non gli piace più. Mi scuso con le donne per il riferimento sessista, ma dovete ammettere che ci stava. :)
In alcuni casi quindi il non-rilascio del codice e il mantenimento del tutto ad uno status quo declinato in una licenza proprietaria non è necessariamente un male: in fondo ad un livello successivo l'azienda, o chi per essa, può sempre decidere di riaprire lo sviluppo anche rendendolo community-based e svincolando di fatto sé stessa da tutta l'attività di licensing.
Everything but licenses (but use GPL)
Questo paragrafo lo intitolo riprendendo una celebre frase di Matt Mullenweg, il creatore di WordPress e CEO di Automattic. Sul palco di non mi ricordo quale WordCamp, alla faccia del fact-checking, disse: "Open source is everything but the license (but use GPL)". Questo significa che tutta la nostra attività di sviluppo in ambito open source dipende da una serie di fattori che dopo un rapido controllo sono effettivamente verificabili come aventi poco o niente a che fare con una licenza software: d'altronde le licenze copyleft sono state create per fronteggiare i colossi e le dotcom dei miei stivali che già dagli anni '80 scorrazzavano senza timore per la Silicon Valley uccidendo l'innovazione libera sfruttando una serie di cavilli burocratici per togliere le licenze d'uso ai concorrenti. Qualcosa di molto vicino al patent trolling di oggi.
Quindi, la conclusione è: non state a guardare il pezzo di carta. Programmate liberi, distribuite, moltiplicate il software come i pani e i pesci. Ma possibilmente, rendetelo open source.
Photo courtesy of JD Hancock
11 Oct 2012
Negli anni che stiamo vivendo, ci sono stati dei cambiamenti a livello di marketing "delle cose" (quindi meccaniche generali) che mi hanno fatto riflettere abbastanza. Abbiamo attraversato infatti un periodo di transizione in cui il software, i bit, venivano venduti in maniera variabile, mentre nell'ultima finestra temporale, di circa un paio d'anni, ormai chiunque voglia offrire un prodotto è obbligato a farlo secondo alcuni canoni impostisi prima con l'avvento di alcune tecnologie "onnicomprensive", successivamente con prodotti che hanno compenetrato l'ambito fatto di ossa e carne, ossia il reale, portando i bit ad assumere un'importanza prevalente rispetto a tante, tantissime altre cose.
Di cosa sto parlando? Sto parlando di marketing del contesto. Come primo esempio possiamo prendere le Google Apps: dalla nascita di GMail, Google ha cominciato ad offrire all'utente non più un prodotto, ma un pool di prodotti fortemente concatenati in un contesto. E parliamo sempre di bit eh. Come secondo esempio, possiamo indicare Apple in funzione di una delle compagnie che maggiormente hanno contribuito a portare nell'ambito "reale", di oggetti di ferro e plastica, quello che ormai eravamo quasi assuefatti a veder succedere coi bit.
Ovviamente ci sono tantissimi altri esempi, ma diciamo che questi due sono facilmente comprensibili e lampanti: iTunes, l'iPod e dopo l'iPhone con anche iCloud sono una piattaforma che integra e collega in maniera quasi (?) inscindibile i dispositivi, racchiudendo l'utente in un contesto dove gli basta allungare una mano per far dialogare dispositivi e tecnologie. Stessa cosa per il contesto offerto da Google: prima GMail, dopodiché Reader, Calendar, e tutte le Google Apps, fino ad arrivare ad Android e Google Music.
Ormai l'offerta di un contesto è imprescindibile per chiunque voglia anche solo pensare di sopravvivere nel medio/lungo periodo, con risultati impressionanti: bisogna trovare il modo infatti di proporre in maniera creativa il proprio panorama di prodotti, oppure "se non puoi combatterli alleati con loro" - ossia integrare la propria applicazione, il frutto del proprio lavoro in un ecosistema di largo uso in mano a milioni di persone, così che possano raggiungere il programma che ho scritto, ad esempio, io, con la stessa facilità con cui raggiungono le applicazioni integrate in maniera predefinita nel proprio contesto "nativo".
Abbiamo quindi questo nuovo modo di ragionare nel proporre prodotti - soprattutto nel campo dell'innovazione: la tendenza ad integrarsi od offrire un proprio contesto, in modo da risultare fascinevoli via via sempre di più, e costruirsi una userbase. Tante startup e tanti software stanno affrontando la sfida: Rovio ha proposto adesso un libro di cucina (digitale) basato sul contesto ormai popolare costruito da Angry Birds e Bad Piggies, mentre addirittura in ambito Linux (desktop) c'è chi cerca di seguire la scia integrando infrastrutture cloud all'interno degli ambienti di lavoro. Casi come Canonical con Ubuntu One e GNOME che includerà OwnCloud ne sono una prova quantomai palese.
Image courtesy of Will Lion
03 Oct 2012
Incuriosito da un post su Wired che lessi qualche tempo fa, ho approfondito il discorso di una rete wifi con autenticazione legata a Facebook, un concetto che mi è parso interessante sin da subito in quanto molto più accessibile per le strutture pubbliche, in modo da non dover più richiedere noiosi dettagli personali quando qualcuno vuole utilizzare la connessione wireless della struttura.
È così che ho pingato i ragazzi di wiMAN, startup non solo italiana ma pure pugliese (regione in cui ho lasciato il cuore), di cui mi ha particolamente attratto il claim, "Libera il wifi", che prende un po' spunto anche da quella che è l'ottica Fon e dalla comunità dei Foneros. Loro non hanno solamente risposto con pazienza alle mie domande per #opencore, ma si sono dimostrati molto gentili e abbiamo chiacchierato anche di altro, come di business model comprensivi di strategie open source e tanti bellissimi argomenti squisitamente più tecnici (tipo OpenWRT, dd-WRT, eccetera eccetera). Bando alle ciance, eccovi quindi la mi intervista a Michele Di Mauro, in arte @wiM1K.
L'intervista
Ciao Michele, visto che abbiamo già rotto il ghiaccio su Twitter iniziamo subito: ogni sistema software fa affidamento a dei software chiave per il suo funzionamento; questi sono appunto detti "stack software"; come è composto lo stack software di wiMAN? Ci sono software open source al suo interno?
Dunque, la nostra startup è fortemente legata al mondo dell' open source. 4 anni fa da buon studente di ingegneria delle telecomunicazioni ed appassionato Linux, mi imbattei per caso in questo progetto https://openwrt.org/, ho pensato subito: "wow che figata"! Lo installai sul mio router ed iniziai ad utilizzarlo per un po' (senza tante pretese). Poi dopo un anno con il mio attuale co-founder in wiMAN (Massimo Ciuffreda) iniziammo ad installare hotspot "convenzionali" (con registrazione via sms) nel nostro paese (Mattinata) utilizzando soluzioni proprietarie; ben presto peró capimmo che innanzitutto la soluzione non era scalabile ed in piú l' approccio al wifi era comunque sbagliato: non si puó costringere un utente a compilare form di registrazione, ricevere codici via sms o ancora peggio inserire carte di credito per navigare, un approccio di questo tipo costituisce una vera e propria barriera all' ingresso, senza contare che gli stranieri non possono ricevere sms sui propri telefoni con SIM estera. Allora ci siamo detti: "dobbiamo inventarci qualcosa". Così iniziai a rispolverare OpenWRT in accoppiata col Linksys wrt54gl (un must), mi serviva a questo punto un demone che mi fornisse il captive portal e mi imbattei in CoovaChilli. A questo punto sul router avevamo tutto quello che ci serviva. Ci studiammo le api e le classi PHP messe a disposizione da Facebook per autenticare gli utenti attraverso il social network. A questo punto mancava solo una solida base dati per chiudere il cerchio open source, scegliemmo MySQL. Poi dopo 12.500 ore di lavoro wiman era pronto per essere testato in pubblico. Oggi dopo soli 3 mesi abbiamo raggiunto quasi 50.000 connessioni di cui 20.000 ad agosto con soli 80 router circa dislocati in tutta Italia, e siamo solo all' inizio :)
Informazioni illuminanti: sono lieto di vedere che tutto quello su cui vi basate è aperto e "hackabile". Parliamo invece delle vostre postazioni e dello stack "lato sviluppatore": quali sono gli strumenti che usate per sviluppare? (IDE, eventuali VPS)
Beh, lato server è tutto open source! Per quanto riguarda le nostre postazioni si dividono tra Mac OS e Ubuntu. I tool che utilizziamo maggiormente sono Komodo Edit come IDE, Wireshark, Filezilla, Firefox, Sequel Pro, PHPMyAdmin, GPG, GIMP, Vi e personalmente abuso di JQuery !
Pensa che ho chiesto ad un ragazzo del team quali software open source usasse personalmente, mi ha risposto un po' stizzito "io uso solo open source!", ehehe... direi che ci siamo, no? :D
Grandissimi :D
Qual è la vostra opinione sul rapporto tra processo di innovazione e open source? In quale punto della catena, secondo voi, deve essere inserito lo step del rendere un prodotto aperto?
Ti parlo della nostra esperienza: senza open source non avremmo neanche iniziato a pensare a wiMAN. Quando ci dicemmo: "sarebbe bello accedere al wifi con Facebook" immediatamente pensai ad OpenWRT, andai a casa ed iniziai a smanettarci; se non ci fosse stato OpenWRT (o qualsiasi altro firmware open) sarebbe rimasta la classica frase: "sarebbe bello se....". L'open source dà la possibilità a chiunque di FARE! Abbatte qualsiasi tipo di barriera e ti mette a disposizione gli strumenti di cui hai bisogno a costo zero e per una startup vuole dire tantissimo. Quindi l'innovazione non può prescindere assolutamente dall'open source.
Per la seconda domanda, varia a seconda dell'azienda e del prodotto. Ma qui la questione non è il punto della catena in cui inserire lo step "del rendere un prodotto open". Il punto è far capire alle aziende, il cui obiettivo è generare profitti, che possono farlo anche con politiche aziendali aperte all'open source. Ad oggi non sappiamo in quale direzione andrà il nostro prodotto per quanto riguarda l'open source, quello che sappiamo per certo è che all'open source wiMAN deve tanto.
Lavorando al vostro progetto, avete contribuito con delle patch verso i progetti originali, o non c'è stato bisogno perché erano già adatti ai vostri scopi?
In effetti noi abbiamo implementato il login con i social network partendo da CoovaChilli che principalmente fornisce la possibilità di autenticare gli utenti su server Radius, cosa che a noi non serviva, dopodiché abbiamo aggiunto una patch sviluppata da noi che si interfaccia con le API di Facebook (ed altri social network) e con i nostri server. Quindi la risposta è sí :)
E avete rilasciato questa patch upstream, o una versione di Coovachilli modificata?
Per il momento stiamo ancora pensando la nostra politica sull'open source, sicuramente abbiamo pianificato il rilascio in futuro della patch in una forma ancora da definirsi.
