On Sun, Aug 02, 2015 at 09:08:51PM +0200, aperi2007 wrote: > QGIS tenta di proporre un modello unificato per i vari stakeholder: > > -"chiedi cio' che ti serve, discutiamone in lista, mettiamoci > daccordo su come va fatta, la funzionalita' che finanzi ci sara' > nella prossima versione rilasciata"-
[...] > E' invece un problema per uno stakeholder pubblico, il quale ha > difficolta' a operare con queste modalita'. > Non che non si possa in assoluto, ma sicapisce bene che se si da' un > incarico a un developer di studiare un problema, non si puo' poi > dargli un nuovo incarico per l'implementazione del lavoro stesso. Scusa ma io questo non lo capisco. Non "si capisce bene", almeno io non lo capisco bene. Perche' un ente pubblico non puo' dare un incarico per la sola analisi e progettazione ? Non e' proprio la pianificazione una delle fasi piu' importanti in qualunque progetto ? > Per semplificare tutto il discorso: > non basta saper programmare in C e compilare un qgis dai sorgenti. > Ma occorre che abbiano un flusso di lavoro che preveda gia' una > interoperazione con una community. Esatto. Cambia proprio l'approccio. Perche' si interviene su un bene condiviso. > Ma qui nasce poi il secondo problema: > Ovvero, la community stessa, la quale e' essa stessa una entita che > oserei definire "liquida" e variabile. > > Il risultato di questa liquidita' e' che cambia spesso opinione, > dimentica cio'che e' stato fatto, si focalizza troppo su l'oggi e > sottovaluta la visione strategica di un prodotto. Questa mi sembra una generalizzazione, e bisognerebbe portare esempi specifici e concreti per capire meglio di cosa parli. La modalita' aperta dello sviluppo rende davvero difficile "dimenticare" qualcosa di quel che e' stato fatto. Per quanto riguarda la visione strategica, entra in gioco la capacita' del proponente di convincere i maintainer della validita' di un approccio. Mi viene in mente il caso di Pierre Racine con i PostGIS Raster. Non solo Pierre non era nel PSC, ma non era neanche uno sviluppatore. Da utilizzatore ha lavorato su un piano strategico cosi' dettagliato e convincente da far digerire perfino a Paul Ramsey l'idea di supportare i raster nel db (lui ne era notoriamente contrario). Va da se che se Pierre non si fosse anche occupato di trovare i fondi per finanziarne lo sviluppo difficilmente la cosa sarebbe andata avanti (nel senso che non basta convincere a parole, ma bisogna pure offrire la nuova funzionalita' ...) > L'approccio bazar , alla lunga finisce per far nascere anche lui i > forks , perche' costringendo gli stakeholders a difendrsi dalla > inevitabilita'del rischio del cambio "bottone <-> zip" li spinge a > ricercare la sicurezza nella tranquilla oasi di un fork > "istituzionale". A me sembra un problema generale legato ai cambiamenti. Non e' specifico del software libero, ma ben presente anche con quello proprietario. Nel software libero semmai e' attenuato proprio perche' avendo il diritto legale di distribuire il software non si pone mai il problema di non trovare piu' disponibile una versione vecchia di un programma (avendo l'accortezza di tenerne copia). Se poi parliamo di "funzionalita' scomparse" e' un altro paio di maniche, e rinnovo il mio invito a segnalare tali casi come bug. > Come si evita che oggi ci siano i bottoni e domani ci sia la zip ? > Che oggi si operi in notazione algebrica usuale e domani in polacca > inversa (rpn) ? La mia impressione e' che con il software libero se oggi c'e' la zip domani ci puo' essere sia la zip che i bottoni (a scelta dell'utente). La cosa da evitare e' che venga meno la zip se qualcuno la usa. Ma dovra' chi la usa occuparsi di "difenderla" in qualche modo. Dal conservare la vecchia versione (ultima spiaggia, ma sempre valida) al far sentire la propria voce nel caso si proponesse di rimuoverla o quando ci si accorga che e' sparita (se avviene vuol dire che non si sta avendo cura dei propri strumenti come si dovrebbe). > Come avere una visione strategica comune. Partecipando alle liste di discussione. --strk; () Free GIS & Flash consultant/developer /\ http://strk.keybit.net/services.html _______________________________________________ Gfoss@lists.gfoss.it http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 750 iscritti al 18.3.2015