Alessio Biancalana Grab The Blaster di Alessio Biancalana

Perfect, Apache, GitHub e le licenze permissive

Chi ha visto un po’ del mio GitHub (almeno) sa che tendo a dotare dei miei software la licenza MIT, perché credo che sia quella che più si confà ai miei bisogni; sono sempre stato anche un grande fan delle licenze permissive in generale, sia per questioni pratiche che di puro idealismo.

Gli autori di Perfect, anche loro, si sono chiesti abbastanza di recente se la licenza GPL non fosse un peso per chi contribuiva al loro framework. La risposta corta è che lo era (quindi adesso la licenza è Apache), ma in particolare mi piace molto questo stralcio tra le loro motivazioni:

The eureka moment, however, came when I was sitting in a small office with Bob Young, the founder of Red Hat, discussing how we could explain the importance of the GPL in our context. His advice was simple and powerful. To paraphrase: “make sure the license isn’t a roadblock. If developers are confused by it in the slightest, it’s getting in the way.”

The simplicity of GitHub’s pull request has killed the GPL. We want people to play with Perfect, screw with it, and recommend improvements so we can strengthen and enhance it. Plus, Swift is licensed under Apache, and Perfect is Swift. It’s a no-brainer.

Ho sempre pensato che la GPL fosse leggermente fastidiosa da un punto di vista di contributi non strutturati. Ho sempre pensato che GitHub, per via del suo modello, avesse promosso un tipo di scambio (se vogliamo culturale, anche) molto più libero.

Quello che non mi era mai saltato in mente (abbastanza lampante, tuttavia) era di mettere in correlazione le due cose: pensavo che semplicemente la gente si fosse rotta le scatole di un ecosistema basato fortemente sull’economia dei vincoli.

Geek Cookies, episodio 22 – Open Data et al.

Era un sacco che non registravo nulla a livello di podcasting, e i ragazzi di Geek Cookies, manco a farlo apposta, mi hanno proposto di unirmi a loro per questa puntata a tema open data del loro show. Devo dire che mi sono divertito molto, ho imparato cose nuove, e come sempre sono veramente contento di aver messo a disposizione quello che ho imparato in molti “posti dell’Internet” riguardo queste tematiche.

Presso il link nel titolo del post potete ascoltare l’episodio oppure scaricarne il file audio per ascoltarlo altrove e/o in un altro momento. Io, dal canto mio, ringrazio i ragazzi per avermi invitato, stimolato e, ehm, sopportato durante tutta la registrazione :-)

Making Jack the dull boy

Headphone jack

Ho un mucchio di roba da scrivere, ma esattamente come Joey sono un procrastinatore seriale e piuttosto che parlare di questioni serie voglio virare verso il faceto. Parliamo quindi un po’ di Apple che vuole rimuovere il connettore jack audio (secondo rumor più o meno confermati) dal prossimo iPhone. A me sinceramente non è che interessi tantissimo, ma è innegabile che le scelte di Apple abbiano un impatto su come gli altri produttori costruiscono le proprie soluzioni.

Non ho letto molto sulla cosa: ho letto sostanzialmente poche fonti, di cui la più presente è stata Daring Fireball, su cui John Gruber riporta ripetutamente la sua opinione positiva riguardo questa scelta:

Ora, io sono particolarmente d’accordo con questo punto di vista:

Removing the iPhone headphone jack is a fine long-term goal. Complaining about the short-term annoyances is also fine. These are compatible.

Tuttavia penso che Apple la stia facendo un po’ fuori dal vaso. Mica per altro: è che secondo me la tray del CD rimossa dal Macbook Air non portò così tanto casino nell’ecosistema dei laptop; la rimozione del floppy drive nemmeno.

La rimozione di un alimentatore SafeMag a bordo dell’ultimo Macbook, viceversa, in favore di un unico slot USB-C a mio parere compromette l’usabilità del dispositivo, ponendo l’utente davanti a due scelte: o colleghi un dispositivo tramite USB, o carichi il portatile. Allo stesso modo, considerare l’attacco delle cuffie solo tramite Thunderbolt, di fatto mi sembra che vada nella stessa direzione.

Guardando con un po’ di visione di confluenza (grazie Ludovico per questo splendido termine che mi hai insegnato) gli eventi, probabilmente Apple sta tentando di convincere i suoi utenti – e il resto del mercato, come side effect – a collegare ogni cosa tramite Bluetooth.

Non è detto che sia un errore. È sicuramente una spinta un po’ coatta verso le tecnologie wireless. Dover cambiare le mie Piston per una coattata di Apple, viceversa, mi fa comunque rodere il, ehm, deretano.

Photo courtesy of Hernán Piñera

Epiphany vuole essere il nuovo Electron

GNOME Web

E così, anche GNOME si sta buttando nei runtime per desktop orientati alle tecnologie web. La cosa sinceramente mi lascia un po’ perplesso, ed è il sintomo di una mania che vedo sempre più dilagare nell’ecosistema Linux, in maniera però meno costruttiva del passato.

Si sta infatti affermando la prassi del risolvere un problema già risolto da qualcun altro nello stesso modo in cui l’altro l’ha risolto, semplicemente “because reasons”, senza un motivo apparente. È così, che, per esempio, come riportato da Joey Sneddon per GNOME Web:

The hope is that by widening access to Web’s web-app features it can attract developers who might otherwise build and package their apps using the Chromium-based Electron.

Stiamo parlando, per chi non lo conoscesse, di Electron, ossia la precedentemente detta Atom Shell: un framework per infilare un’applicazione web in un “corpo” da applicazione desktop. Per alcune cose funziona, per esempio Atom lo utilizza, e sicuramente consente di sviluppare in fretta un MVP che possa andare in produzione alla velocità della luce, i cui bug possono essere aggiustati in un secondo momento con una riscrittura, o con qualche bestemmia.

Ma questa speranza (quella di un altro Electron), c’è veramente? Perché dovremmo usare Epiphany al posto di Electron come container? Perché non cercare di spingere oltre il limite invece di limitarsi a raggiungerlo a malapena?

E questo, per essere totalmente chiari, vale per il motore di Epiphany, ma vale anche per tante tecnologie di Canonical come il vecchio Upstart – o il nuovo Ubuntu Snap in competizione con Flatpak (non voglio discutere su quale dei due sia meglio: ma uno prima o poi soccomberà e sarà stato solo lavoro buttato).

Twitter acquisisce Magic Pony

Twitter parla così della sua acquisizione di Magic Pony, compagnia con un focus particolare sul machine learning:

Magic Pony’s technology – based on research by the team to create algorithms that can understand the features of imagery – will be used to enhance our strength in live and video and opens up a whole lot of exciting creative possibilities for Twitter. The team includes 11 PhDs with expertise across computer vision, machine learning, high-performance computing, and computational neuroscience, who are alumni of some of the top labs in the world.

Qualche giorno fa, in un impeto di rimbecillimento posprandiale ho scritto due righe su Snapchat sul mio tumblog, puntando un po’ il dito verso il fatto che usiamo tecnologie come quelle di face recognition per farci le foto con la faccia a forma di panda.

Questa acquisizione va nella stessa direzione: un team che comprende già 11 PhD, messo a lavorare a un mucchio di codice per far fare dei video a Justin Bieber, o a Obama, o a mia sorella.

Fà strano, no?