Archimista: il buono, il brutto e il cattivo

Il buono

C’è un accordo tra la Regione Lombardia e il Politecnico di Milano per un duplice intervento su Archimista. Da un lato aggiungere un po’ di funzionalità e fissare alcune cose che non vanno. Dall’altra creare un modulo per la pubblicazione web. Trovate alcuni dettagli sul blog di Erregi.

Il brutto

Non mi pare che nella lista di interventi ci siano gli indici e il tema generale dei vocabolari (interni e esterni) che a mio avviso andrebbe ripensato da 0 (magari prendendo spunto da quel bel software che è xEAC, utile come idea anche su come pubblicare le informazioni sul web).

Il cattivo

Io, che faccio notare come Archimista sia un software con licenza opensource, ma non opensource né come modello di sviluppo, né come modello di processo decisionale.

E questo, a mio avviso, è un male che si ripercuote sulla qualità del prodotto. Sono convinto che se nella prima fase ci fossimo aperti di più avremmo ora meno problemi strutturali (given enough eyeballs, all bugs are shallow) e probabilmente più partecipanti attivi (come codice e non solo)

2 pensieri su “Archimista: il buono, il brutto e il cattivo

  1. che dire… sai tutte le mie critiche prima del rilascio del software. Sarebbe stato un bel progetto su cui investire anche come collaborazione con la mia struttura a livello di programmazione.
    Le scelte tecnologiche del software sono discutibili, le funzionalità sono poche, non esiste documentazione tecnica (o almeno non è fruibile liberamente)….
    mah…

    • La sensazione che ho è proprio del “peccato”, “sì bello ma” etc.
      Insomma un’occasione persa per non fare il solito progetto da italioti. Intendiamoci visti certi chiari di luna e certi esempi passati già arrivare a un prodotto open (almeno nella licenza) può essere visto come un traguardo. Ma per me doveva essere un punto di partenza non di arrivo.

      Per il resto: per quanto riguarda le scelte tecnologiche, una volta fissato che tutto doveva essere web based per me passavano in secondo piano. Ovviamente poi la scelta sta a gli sviluppatori che alla fine sono stati anche gli unici che si sono voluti buttare in questa impresa prendendosi anche un rischio di impresa (va detto per onestà).
      Alla fine ArchivesSpace ha scelte tecnologiche similari. E, conoscendo almeno un paio di elementi che ci sono dietro, ciò mi tranquillizza molto.
      Personalmente tra rails usato da Archimista e ArchivesSpace, php (symfony) di ICA-AtoM o Java di xDams, preferisco la prima soluzione. Ma sono scelte personali. Di un profano.

      Possono esserci errori nella fase di modellazione (ci sono) e proprio quelli secondo me possono essere evitati aprendo di più la discussione (voglio dire, per un “banale” schema xml come EAD noi gruppo tecnico di revisione facciamo tutto su Github per raccogliere suggerimenti, segnalazioni di errori, etc. Andava fatto anche per qualcosa più complesso di uno schema.

      Anche sulle funzionalità mi voglio spendere per una difesa del prodotto: manca qualcosa (che da quello che ho capito sarà proprio oggetto di intervento del Politecnico), ma coperte quelle lacune farà bene ciò che è nato per fare (descrivere archivi storici). Certo questo si poteva raggiungere prima e meglio, ma si è evidentemente sottovalutato l’impegno necessario per le schede speciali. A posteriori probabilmente si sarebbe dovuto dire che non ce la si faceva a farle con i fondi disponibili, se non tagliando altro (come poi è accaduto). Un errore, evidentemente, di tutto il gruppo che ci ha lavorato (non so perché ma pare ci sia quasi paura a dire “abbiamo sbagliato”… io non ci vedo niente di male, sinché non diventa una costante :-D).

      Anche sul rilascio del codice posso capire che si sia atteso un rilascio definitivo per “timore” che qualcuno saltasse sulla barca e si prendesse parti dei meriti (capisco, ma non condivido… “è l’opensource baby” canterebbero i Pearl Jam).

      Qui finisce la mia difesa (non di ufficio, almeno non più) di Archimista e inizia la parte in cui ti do ragione: non si è fatto nulla (e non si fa nulla) per favorire la partecipazione di altri al progetto… Se il concetto è “i sorgenti sono su github ognuno può farne quello che vuole” temo che da qualche parte ci sia stato un fraintendimento su cosa significhi open source. Manca la documentazione tecnica (imho non esiste), mancano delle indicazione sul code style, non è pubblico il modello su cui si basa (ciò che imho doveva e deve essere pubblicato in corso d’opera per ricevere consigli) l’internalizzazione di Archimista doveva essere una priorità se si voleva allargare la partecipazione oltralpe (e invece è incompleta, nascosta e, secondo me, nemmeno tanto facile da ottenere in maniera totale con i vocabolari – leggi alla voce ripensare completamente indici e vocabolari). Proprio parlando con uno dei responsabili di ArchivesSpace mi ha detto che gli sarebbe piaciuto giocare un po’ con Archimista per vedere se potevano esserci dei punti di contatto (come appunto i sempre spinosi vocabolari controllati esterni). Che avrei dovuto rispondergli: “il codice è su github a disposizione di tutti”???

      Sono abbastanza convinto che Archimista sia un buon prodotto, sono altrettanto convinto che sarà tra i software più diffusi per l’inventariazione in Italia (vuoi anche grazie all’eredità di Sesamo), sono invece sicuro sia stato (e sia tuttora) una grandissima occasione persa.

Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...