Why Computing Students Should Contribute to Open Source Software Projects
Bella idea, con annessa struttura del corso che l’autore dell’articolo tiene nella propria università. Pratica da imitare, a mio parere. https://cacm.acm.org/magazines/2021/7/253459-why-computing-students-should-c... "By contributing to open source projects, students acquire in practice a formidable range of skills, knowledge, and experiences, allowing them to work productively as modern well-rounded developers rather than as the lone-wolf coders portrayed by Hollywood" antonio
On Wed, Jun 23, 2021 at 07:52:07AM +0000, VETRO' ANTONIO wrote:
Bella idea, con annessa struttura del corso che l’autore dell’articolo tiene nella propria università. Pratica da imitare, a mio parere. https://cacm.acm.org/magazines/2021/7/253459-why-computing-students-should-c...
... da imitare, e fortunatamente imitata da molti, compreso Diomidis. Lo sottolineo qui giusto per mettere in evidenza che questa (buona!) pratica esiste ormai da più di un decennio in svariate università europee. Nel mio piccolo tengo dal 2014 un corso di software libero à Université de Paris che applica questo tipo di approccio pratico con successo. Essere testimoni, anno dopo anno, della soddisfazione degli studenti quando la loro prima patch ad un "vero" progetto FOSS viene accettata è una delle ricompense più belle della mia carriera di insegnante. Il problema a questo punto è far diventare queste esperienze didattiche, che restano ad oggi sporadiche, la norma nella formazione degli sviluppatori. Un modo è quello di passare dai curriculum istituzionali tipo quello ACM citato da Diomidis, non perché siano adottati in toto dagli atenei (non è così e non sarebbe nemmeno il caso che lo fossero), ma perché aumenterebbero la visibilità dell'approccio. Ci sono poi anche problemi etici da discutere. In particolare si può argomentare che in questo modo l'università faccia offloading di una parte delle sue responsabilità didattiche su maintainer di progetti FOSS non pagati ne formati per questo (che siano volontari o pagati da altri, il problema resta). Personalmente ritengo possa essere accettabile perché "in cambio" gli studenti contribuiscono ad un bene comune (il software commons), ma i ruoli devono essere chiari a tutti i partecipanti. In secondo luogo si pongono spesso problemi di diritti, ad esempio nel caso di progetti FOSS che richiedono un copyright assignment ad aziende for-profit come condizione per accettare patch. Faccio stare i miei studenti alla larga da tali progetti, per evitare che l'università di fatto regali manodopera a costo zero a privati, ma questo tipo di verifiche non è particolarmente scalabile. Ciao -- Stefano Zacchiroli . zack@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader & OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »
Condivido le due problematiche. Condivido (in un altro senso) anche che, nel nostro piccolo del corso di Software Engineering 2 a PoliTO con il collega Torchiano, facciamo sviluppare progetti Open Source su GitHub in gruppi da 5-6 persone, anziché far intervenire gli studenti su progetti esistenti. Così facendo si limano se non eliminano questi due problemi da te citati. Se ne introducono altri, ovviamente, ma di diversa natura. Mi fa piacere leggere dalla tua mail che non sono poche le università che fanno cose simili da tempo. Ciao! A.
Il giorno 23 giu 2021, alle ore 10:18, Stefano Zacchiroli <zack@upsilon.cc> ha scritto:
On Wed, Jun 23, 2021 at 07:52:07AM +0000, VETRO' ANTONIO wrote:
Bella idea, con annessa struttura del corso che l’autore dell’articolo tiene nella propria università. Pratica da imitare, a mio parere. https://cacm.acm.org/magazines/2021/7/253459-why-computing-students-should-c...
... da imitare, e fortunatamente imitata da molti, compreso Diomidis. Lo sottolineo qui giusto per mettere in evidenza che questa (buona!) pratica esiste ormai da più di un decennio in svariate università europee. Nel mio piccolo tengo dal 2014 un corso di software libero à Université de Paris che applica questo tipo di approccio pratico con successo. Essere testimoni, anno dopo anno, della soddisfazione degli studenti quando la loro prima patch ad un "vero" progetto FOSS viene accettata è una delle ricompense più belle della mia carriera di insegnante.
Il problema a questo punto è far diventare queste esperienze didattiche, che restano ad oggi sporadiche, la norma nella formazione degli sviluppatori. Un modo è quello di passare dai curriculum istituzionali tipo quello ACM citato da Diomidis, non perché siano adottati in toto dagli atenei (non è così e non sarebbe nemmeno il caso che lo fossero), ma perché aumenterebbero la visibilità dell'approccio.
Ci sono poi anche problemi etici da discutere. In particolare si può argomentare che in questo modo l'università faccia offloading di una parte delle sue responsabilità didattiche su maintainer di progetti FOSS non pagati ne formati per questo (che siano volontari o pagati da altri, il problema resta). Personalmente ritengo possa essere accettabile perché "in cambio" gli studenti contribuiscono ad un bene comune (il software commons), ma i ruoli devono essere chiari a tutti i partecipanti.
In secondo luogo si pongono spesso problemi di diritti, ad esempio nel caso di progetti FOSS che richiedono un copyright assignment ad aziende for-profit come condizione per accettare patch. Faccio stare i miei studenti alla larga da tali progetti, per evitare che l'università di fatto regali manodopera a costo zero a privati, ma questo tipo di verifiche non è particolarmente scalabile.
Ciao -- Stefano Zacchiroli . zack@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader & OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » _______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
Buongiorno, grazie Stefano per aver condiviso la tua esperienza (e quella di altre università) in merito Stefano Zacchiroli <zack@upsilon.cc> writes: [...]
Ci sono poi anche problemi etici da discutere. In particolare si può argomentare che in questo modo l'università faccia offloading di una parte delle sue responsabilità didattiche su maintainer di progetti FOSS non pagati ne formati per questo (che siano volontari o pagati da altri, il problema resta). Personalmente ritengo possa essere accettabile perché "in cambio" gli studenti contribuiscono ad un bene comune (il software commons), ma i ruoli devono essere chiari a tutti i partecipanti.
Molto interessante quello che dici, mi verrebbe da considerare che le università dovrebbero avere come missione quella di contribuire ai commons in tutti i campi di ricerca, quindi non sarebbero tanto gli studenti che hanno qualcosa "in cambio" ma tutto ciò farebbe parte del compito istituzionale dell'università. Sul "rischio di offloading" poi, mi viene da dire che l'università dovrebbe considerare queste attività come un'estensione delle proprie responsabilità didattiche /anche/ nei confronti dei maintainer FOSS (pagati o non) che /a volte/ (spesso) non sono formati per quella parte di "didattica" che io vedo presente in /tutti/ i progetti FOSS... a volte gli "upstream maintainer" stessi avrebbero bisogno di un supporto formativo (tutoring?) per quelle attività per le quali non sono ben preparati (e ce ne sono). Insomma, nel rapporto tra FOSS e università io ci vedo solo un win-win e mi piacerebbe che nel ciclo di vita del software, dal kernel alle web app, le università fossero maggiormente coinvolte, istituzionalmente intendo. Tra l'altro, secondo me non è un caso che il software più innovativo che io vedo in giro [1] viene da lavori universitari, dove alcuni singoli docenti o bravi studenti coordinano il lavoro (anche dopo che sono usciti).
In secondo luogo si pongono spesso problemi di diritti, ad esempio nel caso di progetti FOSS che richiedono un copyright assignment ad aziende for-profit come condizione per accettare patch. Faccio stare i miei studenti alla larga da tali progetti, per evitare che l'università di fatto regali manodopera a costo zero a privati, ma questo tipo di verifiche non è particolarmente scalabile.
Sì questa è una condizione particolarmente delicata, tuttavia il /grosso/ della differenza la fa /quale/ licenza: copyleft o no. Fossi io il rettore di una università, nel 2021, scriverei nero su bianco che docenti e studenti NON devono collaborare (istituzionalmente ovviamente) a software non copyleft, perché la vera manodopera a costo zero regalata a privati è quella che sviluppa software non copyleft, ovvero software che può essere (ed è) redistribuito in forma proprietaria, modificato o meno, da /chiunque/. Se il software fosse copyleft, invece, il copyright assignment permetterebbe la proprietarizzazione solo al titolare: non è poca cosa ma nel caso fosse evidente un abuso di posizione dominante (o di sfruttamento manodopera gratuito) un fork sarebbe alla portata di "due click". Anche in questo aspetto, ovvero del rapporto tra aziende private e università, mi piacerebbe che quest'ultima fosse il /traino/ di un sano sviluppo di commons (tra cui il software ovviamente)... ma a me pare invece che negli ultimi decenni sia tutta una /rincorsa al contrario/, dove cioè sono le università a cui si chiede di diventare aziende per promuovere "startup spin-off", dove sostanzialmente la PRIVATIZZAZIONE (attraverso marchi, brevetti e copyright... la chiamano proprietà intellettuale... POVERA università!) è sia il mezzo che il fine della propria missione. Io ho il fondato sospetto, invece, che SE (quando?) fosse l'università a CONDURRE lo sviluppo dei commons (tutti), ANCHE invertendo l'assegnazione del copyright :-D, allora «si può sperare che il mondo torni a quote più normali» [...] Saluti, Giovanni. [1] io ho un criterio "mei generis" in mertio al grado di innovazione: GNUnet, Taler, Nix e NixOS, Guix... Plan9 e famiglia: quelli sono innovativi. P.S.: negli anni '70 del secolo scorso il governo USA investì quantità indecenti di denaro pubblico per promuovere nelle università lo sviluppo di software NON copyleft (sostanzialmente licenza MIT), quello che tutt'oggi permette agli USA di essere il mostro che sono, da questo punto di vista. Comunque quelli sono tempi andati, nessuno pensi di ripetere una roba del genere, manco la Cina riuscirebbe nell'intento oggi. Commons, roba antica che ci salverà il futuro. -- 380° (Giovanni Biscuolo public alter ego) «Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché» Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>.
participants (3)
-
380° -
Stefano Zacchiroli -
VETRO' ANTONIO