Ogni tanto mi capita di pensare alla quantità di volte che sento pronunciare il termine “open“. E proprio perchè non ho niente di meglio da fare, ma ci tengo a dare segni di vita, riepilogo di seguito quando:
- open access
- open archives initiative
- open url
- open knowledge
- open definition
- open data
- open content (da non confondere con il public domain)
- open standard
- open source (o meglio FOSS)
Ora, dopo esservi fatti questa scorpacciata di definizioni e loro storia su Wikipedia, ci tenevo a spiegare che il termine OPEN da solo vuol dire semplicemente “aperto”, come il termine DOOR vuol dire semplicemente “porta”. La vera differenza la fa il contesto in cui è usato. E non solo, nei contesti elencati qui in alto assume uno specifico valore. Per quanto possa sembrare ridondante dover dare una spiegazione di open definition, ci tenevo a evidenziare che questa non si esaurisce nella definizione stessa. E capire il contesto è quanto mai importante, considerando che tutti questi termini travalicano spesso diversi campi di attività e altrettanto capita siano usati a sproposito.
L’esempio più concreto che mi viene in mente riguarda i software open source. Affermare che ho sviluppato un software utilizzandone altri di open source, non rende il mio altrettanto open. Così come, senza voler essere troppo estremista, volendo essere estremista, personalmente non ritengo che un software sia open source per il semplice fatto che è stato rilasciato con una licenza di tipo open source. Anche se nelle licenze di questo tipo non ci sono riferimenti a un ruolo attivo del licenziatario, sono fermamente convinto che la vera differenza con la “moda open”, sia l’atteggiamento assunto nella fase di sviluppo e di distribuzione. Insomma, ben vengano i migliaia di progetti caricati su sourceforge o github, ma per come la vedo c’è ancora troppa differenza tra porgetti realmente accessibili e progetti open di nome ma non di fatto. [aggiornato 27/04/11]
Quindi ora, per la gioia di tutti gli utenti di ClavisNG, stiamo facendo il manuale utilizzando DokuWiki, un motore wiki, che spero possa contribuire a migliorarne la documentazione e a incentivare la partecipazione (altre due parole chiave legate e diversi concetti “open”). Spero anche che riusciremo a rilasciare il manuale con licenza CC BY-SA 3.0.
Detto questo, mi piacerebbe sapere se qualcuno conosce: altre declinazioni del termine “open” (ad esempio guardate Microsoft come lo usa), altri manuali di sw per biblioteche distribuiti su piattaforme wiki (ogni tanto mi assalgono dei dubbi sulla scelta di dokuwiki…).
Ho modificato la parte in questione. In ogni caso è esattamente come dice Shaitan, l’importanza di documentare e comunicare cosa si sta facendo è fondamentale, secondo me. D’accordo però che così si esce dalla definizione e si entra nell’implementazione della licenza.
Purtroppo non confido troppo in una base utenti evoluta, ma spero che fornire la possibilità possa spingere i curiosi a provare a fare qualche modifica.
Sulla struttura gerarchica, il wiki mette veramente in crisi. Per questo sto cercando di fare attenzione ai namespaces e di dimenticarmi le strutture classiche del sito di informazione. Appena lo pubblico vi faccio sapere così mi dite se avete suggerimenti….
Sai, sul termine “open” ormai si fa tanta di quella fuffa, di quel blabla, di quella moda, che è naturale non capirci nulla ogni tanto. (Un po’ come la parola “cultura” che mi fa rabbrividire ogni volta che la leggo nelle discussioni sulle biblioteche). E’ una di quelle belle parole che fanno tanto figo agli occhi dei neo-adolescenti (un giorno spiegherò questo mio neologismo) come molti bibliotecari o appassionati di software. Però oltre la fuffa ci sono definizioni rigorose e soprattutto ci sono degli *standard*, quindi, a essere un minimo attenti e rigorosi, non si scappa.
Ma sei sicuro che…
“Così come, senza voler essere troppo estremista, non ritengo che un software sia open source per il semplice fatto che è stato rilasciato con una licenza di tipo open source”…
Questa affermazione mi sembra un po’ contraddittoria – a dire il minimo: puoi spiegarti? 🙂
Posso provare a spiegartelo io Enrico: esistono dei software, anche nel nostro mondo delle biblioteche, con licenza libera (magari anche perché imposta dalle componenti che usano) che per avere il codice sorgente devi fare domanda in carta bollata e una volta ottenuto trovi un coacervo di moduli da installare senza uno straccio di README…
E allora dunque per essere aperti non basta segliere la licenza.
A domanda via mail fornisco esempi di software in questione 🙂
Tornando al manuale, qui all’università di Pavia ne stiamo scrivendo uno in docbook. Avevo pensato a lungo se usare il novello mallard, ma poi ho optato per la tradizione.
Docuwiki può essere un’idea. Soprattutto se si ha una base utenti evoluta che possa condividere tips and tricks vari.
Dipende anche da quanto strutturato è il manuale in questione. I wiki per natura diventano rapidamente reticolari, con collegamenti orizzontali più che verticali. Certo si può disegnare un wiki strutturato, ma mantenerlo tale vuol dire uno stretto controllo sui contributi.
Per il software di cui ci occupiamo adesso (un DOMS) dubito che la base utenti sia molto larga, magari se ne riparlerà in futuro quando sarà finito il nuovo software di descrizione archivistica.
A proposito di archivi, il manuale di ICA-AtoM è distribuito come wiki (loro usano mediawiki) http://ica-atom.org/docs/index.php?title=User_manual