L’Open Source, quando funziona, e quando no.

Il titolo può fuorviare. In realtà non sto scrivendo di ambiti in cui funziona la politica opensource, e altri in cui non funziona: ho avuto un’interessantissima discussione a proposito di questo col mio amico Antonio, su Facebook (chi dice che ci sono solo idioti?), e forse potrei riportarne gli esiti qui, tuttavia adesso, in questo post, voglio parlare di qualcos’altro. Qualcosa che mi preme, che ho visto succedere più volte, che affossa, molte volte, i progetti open.

Leggevo proprio l’altro giorno infatti il post di Emanuele, che consiglio a tutti, il quale illustra come nasce e come cresce un progetto open, le dinamiche che lo portano alla vittoria, al fallimento, allo stallo; ebbene, il carissimo Emanuele ad un tratto, verso la parte finale dell’articolo ha parlato di qualcosa a cui tengo veramente molto: l’essere poi realmente open. Questo non ha molto a che fare con la licenza, ovvero: ok, ovviamente devi licenziare il tuo progetto per essere realmente aperto, ma, quando le persone cominciano a modificare il tuo codice, devi essere in grado di apprezzare tali cambiamenti, ed un bravo sviluppatore (soprattutto un bravo project manager) ha la sobrietà e la lucidità di giudicare codice concorrente dall’alto, senza far scendere minimamente in campo l’orgoglio.

In molti purtroppo, hanno ridimensionato il fenomeno dell’opensource, non perchè non funzioni, ma perchè alcuni progetti molto spesso per una ripicca di qualcuno hanno subito ritardi, stalli, portando poi ad un nulla di fatto. È questo poi il motivo per cui GIMP è ancora fermo e non vengono rilasciate versioni stabili da eoni, così come accade per Compiz. Tutti progetti cari al buon telperion, che ne parla come un padre di un figlio che va male a scuola; ci espone di una fantastica patch per GIMP che ne modifica sensibilmente l’interfaccia grafica, portando in alto i controlli dello strumento che si sta utilizzando.

Proposta tale patch, quale risposta viene data? “No ma, noi abbiamo deciso così, guarda, è facile: fai un fork e applica il tuo cambiamento”.

Ma siete scemi? L’ottica del forka o muori è morta da anni. Bisogna essere dei leader calibrati per saper condurre un progetto in totale apertura, e se non lo si è, preferisco accettare che mi venga chiuso il ciclo di sviluppo, piuttosto che vedere esclusi tutti i miei contributi. Ci sono un po’ di progetti che, grazie a queste alzate d’ingegno, sono rimasti fermi anni anzichè portare la ventata d’innovazione che il loro manifesto prometteva: è ora di smetterla con quest’ottica dittatoriale del “si fa come dico io”. No: si deve fare cos’è meglio per tutti. E cos’è meglio per tutti si vede, semplicemente usando il programma, provando le patch concorrenti. Potrebbe sembrare che il tutto rallenti, ma in realtà se si cominciano a scartare i contributi esterni, i tempi si faranno ancora più stretti. E col tempo l’apporto di codice al GIT del progetto calerà drammaticamente, perchè in un’ottica del genere, o sei pagato, o sei fortemente legato (in maniera sentimentale, dico) ad altri membri del progetto, oppure non ci stai, a fare la pecora.

L’opensource è anche fantasia, e chi non lo capisce merita che il proprio progetto affondi.

Post correlati:

This entry was posted in Informatica, Linux and tagged , . Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.
  • Pingback: Tweets that mention L’Open Source, quando funziona, e quando no. | Bl@ster's Home -- Topsy.com

  • telperion

    Si, nel caso proposto, quello che scoccia è l’atteggiamento di chiusura.
    La patch ha tantissimi problemi da risolvere, spazio allineamento eccetera, ma cosa costa rispondere “ci sono buone idee ma molti problemi, se vuoi prosegui, noi siamo molto impegnati, ma se devi chiederci qualcosa sul codice ti risponderemo, se ne esce qualcosa di valido, potremmo considerare di inserilo come opzione, in fondo un pannello in più o in meno che cambia.”

  • telperion

    PS il testo non scolla nella finestra di input, difficoltoso scrivere.

  • http://andrealazzarotto.com/ Lazza

    Direi che hai parlato molto molto alla leggere a proposito di Gimp (Compiz non so, visto che non ne seguo alcuna news). Le modifiche fatte alla GUI sono state tante, e non tutte le proposte, evidentemente, possono essere accettate.
    Non è una motivazione il fatto che tu (o io, o qualcun altro) trovi fondamentale che GIMP copi in tutto e per tutto la GUI di Photoshop.
    La risposta che ha avuto l’ideatore delle modifiche ha perfettamente senso: “vuoi che la tua patch stasera sia già parte della GUI di GIMP? Forka… Vuoi proporla, bene proponila. Adesso le priorità sono altre”, come ad esempio GEGL (basta leggere in homepage su gimp.org).
    Ad ogni modo non si può avere un’opinione chiara sulla faccenda senza aver prima letto opportunamente questo articolo: http://www.libregraphicsworld.org/news.php?readmore=675

  • http://azzsthoughts.netsons.org/ azzarcher

    Veramente un bel post! Bravo! :)

  • http://anonimoconiglio.blogspot.com Coniglio

    Condivido il post, ovvero il messaggio. Alla fine uno può rilasciare il codice aperto ma non essere disposto a cambiamenti e quindi gestire il suo prodotto open come una cosa chiusa.

    Tuttavia, io credo che il fork sia sempre legittimo, anzi è parte del mondo open proprio perché la stessa licenza lo garantisce. Non so, mi vengono in mente tanti esempi, ma quello di Zeitgeist non accettato in Gnome forse è il più evidente. (qui so bene che non è un fork però non è stato accettato per motivi di “impegno”).

  • http://twitter.com/Stefanauss Stefanauss

    “potremmo considerare di inserilo come opzione, in fondo un pannello in più o in meno che cambia.”

    La risposta a questo la trovi esposta nella ML che tu stesso hai linkato: ogni concetto di interfaccia supplementare sarebbe una rogna pazzesca in quanto a manutenzione; in secondo luogo, renderebbe l’interfaccia inconsistente attraverso installazioni multiple, con tutti i problemi di documentazione, supporto e bug report che ciò comporta.

    L’eccessiva rudezza della risposta rimane, e probabilmente non si è fatto granchè per dare ulteriori motivazioni allo sviluppatore della patch, ma non è come se il tono della risposta quotata sia quello generale del feedback che sigetch sta ricevendo. A quotare solo quel pezzettino e articolare una polemica sopra, sembra un intero team a fare ostruzionismo becero. Non è così.

    Per la patch in sè, creare un prototipo di GUI non è la tipica patch del tipico sviluppatore volenteroso che vuole dare il suo contributo. Non è un lavoro di implementazione, migliorìa o correzione di qualche (nuova?) funzionalità nel quale lo sviluppatore ha una sua forte autonomia che gli deriva dal suo dedicarsi al task specifico.

    Sigetch ha prodotto del codice che tipicamente ha bisogno di derivare da un attento processo di design SENZA partecipare al processo di design. Che in GIMP è collaborativo, con dei responsabili/coordinatori designati dal team.

    E va tutto bene fintanto che si tratta del famoso “Scratch Your Own Itch” (ed è questo il caso), ma se sigetch si aspettava fin da quando ha cominciato a lavorare sul codice (e a leggere la ML, sembra assolutamente così) di vederselo integrato in GIMP attraverso un lineare commit > revisione > merge/merge opzionale allora ha fatto quantomeno un ingenuo errore di valutazione, visto che stava operando sulla _GUI_ di *GIMP*.

    La patch poteva anche essere perfetta e alla fine del controllo qualità. Possono mandarne 5 altre nella settimana entrante con altrettanti prototipi di GUI con codice di altissima qualità. Se si tratta di prototipi lontani da quanto stabilito, sia in termini di specifiche che in termini di flusso di lavoro, dal processo di design allora non è che devono entrare nel codice di GIMP solo perchè è codice esistente, funzionante o perchè il team di GIMP è esiguo quindi “quel che viene viene”.

    5-6 thread sotto ["developer with spare time..."] c’è un esempio di come il team di GIMP fornisca le idee di base sulle specifiche stabilite, cosa utilissima PRIMA di cominciare a codare se davvero si desidera massimizzare la possibilità di vedere il proprio codice integrato nel progetto.

    Ripeto, la polemica sul “vai a fatti forkare” è pretestuosa secondo me.

    @ Blaster

    Non so come mai o cosa intendessi quando hai accostato Compiz e GIMP sulla base della rarità/ritardo dei rilasci.
    Gli stalli che fronteggiano GIMP e Compiz in quanto a rilasci di versioni stabili non hanno *niente* in comune tra loro. Per dirne una, Compiz nell’ultimo anno e mezzo è stato riscritto da capo, e GIMP no.

  • http://picchiopc.blogspot.com Picchiopc

    post davvero interessante :D

  • telperion

    Guarda ho scritto delle considerazioni:
    http://telperion.wordpress.com/2011/01/17/gimp-gui-enhancement-patch-e-non-considerazioni-sullinterfaccia/

    che io ritengo valide per un uso razionale dello spazio “a prescindere” dalla patch.

    Su

    “ogni concetto di interfaccia supplementare sarebbe una rogna pazzesca in quanto a manutenzione;”

    se esamini con attenzione gimp, vedi che è gia cosi, pannelli, finestre agganciabili, puoi comporre già ora decine di interfacce completamente diverse tra loro, un pannello opzioni strumenti orizzontali in più, opzionale, ti assicuro non ammazzerebbe nessuno.

    Poi se tutto il mondo è abituato a trovare le opzioni strumenti li, ci sarà un perchè.

    Ad esempio su OOwriter non li hanno messi in basso per non copiare MSoffice …

  • http://dottorblaster.it/ Bl@ster

    Compiz nell’ultimo anno e mezzo è stato riscritto da capo per orgoglio, così come per orgoglio è chiaro che GIMP ha subito rallentamenti nella scrittura (soprattutto della one-window-mode) per nepotismo.
    Ripeto, non è un voler condannare progetti in particolare, erano solo esempi di come una maggior apertura ai contribuenti esterni porterebbe un po’ più di velocità.

  • http://dottorblaster.it/ Bl@ster

    Esattamente, in realtà la fatica sarebbe molta meno, e come ho già detto oggi su oneOpenSource, e credo che tu mi abbia letto, se una cosa *merita* di stare in un posto non c’è concetto di copia che tenga.

  • http://dottorblaster.it/ Bl@ster

    Certo che il fork è legittimo, per carità, ma non dev’essere l’unica strada. Semmai l’ultima risorsa.

  • http://dottorblaster.it/ Bl@ster

    È chiaro che il lavoro da fare è tantissimo, ma non mi pare che la risposta fosse stata *proprio* quella :D

  • http://dottorblaster.it/ Bl@ster

    Disqus MERDA maledetti

  • http://dottorblaster.it/ Bl@ster

    Eeeesatto =)

  • http://dottorblaster.it/ Bl@ster

    Grazie :)

  • Shaytan

    Ci sono tre punti che vanno approfonditi a mio avviso, i costi, umiltà e democrazia.
    Anche se il “vil denaro” in questi casi dovrebbe avere un impatto minimo e non considerabile ci si trova spesso di fronte a costi spesso insormontabili.
    Iniziare e tirare avanti un progetto tutto da soli è una cosa difficile se non impossibile ed allora ecco che si cercano proseliti per la propria causa con effetti strani.
    Chi si rende subito disponibile in modo gratuito ed invece chi pensa subito al denaro, purtroppo in questi casi devi rivolgere il tuo sguardo ad ambienti poco raccomandabili (leggi banche) che nel 99% dei casi snobbano il tuo progetto per milioni di motivi diversi.
    Conclusione il progetto va a rilento, sopravvive per qualche tempo e poi inesorabilmente muore sotto i colpi di un mercato veloce e pieno di soluzioni immediatamente pronte a costi tutto sommato abbastanza accettabili.
    Fattore umiltà, in questo caso esiste una semplice frase che è necessario ripetersi tutte le mattine davanti allo specchio appena alzati “per quanto io sia bravo c’è sempre qualcuno più bravo di me, se ne trovi un tipo del genere zitto ed osserva magari tra qualche tempo potresti essere tu che insegni ad altri”.
    Ultimo punto, democrazia.
    In una società che ne ha sempre meno di questa sana abitudine e che piuttosto ci infonde modelli umani, ma preferirei definirli casi umani, che fanno delle loro decisioni virtu insindacabili un tocco di sana democrazia aiuterebbe molto, il progetto è open a mio avviso va immaginato come una grande piazza dopo ogni collaboratore, con garbo, dice la propria opinione e consiglia le proprie soluzioni.
    Sta ad un capo illuminato far si che molte voci diventino un unico ed armonio coro.

  • http://twitter.com/Stefanauss Stefanauss

    Per “inserire come opzione” facevo riferimento alle opzioni a tempo di compilazione. Questo è stato categoricamente escluso per le ragioni di cui sopra.

    La flessibilità che menzioni tu c’è, ma è tutta già integrata nel codice, viene compilata di default e segue il resto del codice in caso di grossi cambiamenti. Non aumenta la complessità della manutenzione.

    Poi è chiaro che ha il potenziale per diventare una modalità di disposizione opzionale degli strumenti, ufficialmente inclusa nel codice di GIMP. Ma ripeto, non deve diventarlo solo perchè “è qui e funziona, mettiamola”. Pressochè qualsiasi cosa può essere opzionale, non significa che debba essere inclusa per tale ragione.

  • http://dottorblaster.it/ Bl@ster

    Esattamente ciò che ho cercato di dire (a parte i costi) con questo post. Grazie del commento Shà ;)

  • telperion

    e tra l’altro riscritto in C++ nemmeno troppo bene a dirla tutta, perchè è abbastanza inusabile.

  • telperion

    Il punto fondamentale è
    rivedere, mettere in discussione l’attuale pannello “opzioni strumenti”, che onestamente, è un vero obrobrio, poi del “come”, se ne può parlare tranquillamente mediando le varie opzioni.

  • http://twitter.com/Stefanauss Stefanauss

    È stata proprio il ritmo di sviluppo frenetico di Compiz, ottenuto accettando praticamente qualsiasi cosa o giù di lì, a trasformarlo in una matassa di codice non mantenibile e con pochissime prospettive di estensione. Per questo è stato riscritto, altro che orgoglio.
    La velocità nei rilasci non può essere ottenuta a scapito della stabilità e mantenibilità del codice, che non sono capricci da developer, ma una cosa che si ripercuote sull’utente alla fine (tant’è vero, 0 evoluzione sul Compositing Manager della distro linux più usata, per oltre un’anno).

    GIMP soffre di mancanza di sviluppatori, in quanto a numero. A questo è dovuta la lentezza di sviluppo, oltre al fatto che non è il software della Domenica, è GIMP, ce n’è di che spulciare prima di toccare il codice. Ad esempio, lo sviluppatore della OWM è assente da 3 mesi, motivo principale per il quale questa parte del codice è in stallo (dovrebbe ricominciare il mese prossimo). Ma non vuol dire che non appena sbuca un contributo esterno (questo come già detto è anche “troppo esterno”) debba essere necessariamente accettato perchè è merce rara.

  • telperion

    No, tutto il “qualsiasi cosa” di compiz erano plugin scritti già in c++, o interfacce (ccsm tool vari) scritti perlopiù in python-
    Ora è il core che è stato riscritto, per un motivo semplice, “C” è un gran casino e pochi ci sanno mettere le mani senza far danni.

    GIMP soffre di mancanza di sviluppatori, perchè è in “C”, gnome ha gli stessi problemi, rispetto a KDE ad esempio, che è tutto in C++.

  • http://anonimoconiglio.blogspot.com Coniglio

    Sì, anche su questo siamo d’accordo. Il fork alla fine è l’ultima via di uscita, non dovrebbe essere preso alla leggera.

    Il problema è la cattiva gestione, se uno non gestisce le cose con un minimo di “democrazia” per così dire, poi ti forkano tutto. Infatti progetti FLOSS che vengono tenuti al chiuso o gestiti in modo poco “open” hanno ben poco da condividere della filosofia del free software

  • http://andrealazzarotto.com/ Lazza

    Infatti ‘sta storia dell’orgoglio non si regge in piedi, e non ho capito da dove salta fuori…

  • http://twitter.com/Stefanauss Stefanauss

    Non so in che linguaggio fossero scritti originariamente i plugin, e mi sembra che in effetti siano già passati da una riscrittura all’epoca, ma molti plugin di default sono stati riscritti (di nuovo?) dopo il cambio di core, tant’è vero che gli ultimi lotti di plugin portati al nuovo core stavano arrivando poco prima dell’annuncio di Compiz come WM di Unity per Ubuntu. Poi non ho sentito più niente di nuovo su quel fronte, ma di certo c’erano dei port in corso.

    Per il resto, assai probabile che il grosso della motivazione per la riscrittura sia il cambio del linguaggio di programmazione, per via della doppia faccia della stessa medaglia: poca base di programmatori capaci di maneggiare il C a dovere + difficoltà intrinseca del programmare a così basso livello, quindi più difficoltà a generare codice bug-free e via dicendo…

  • http://twitter.com/emanuele_r Emanuele Rampichini

    Ti ringrazio per aver citato il mio post e faccio dei commenti al tuo. Il mio punto di vista è che l’apertura è un processo tanto umano quanto tecnico. Tutti e 2 gli aspetti devono coesistere. Tecnicamente un progetto deve saper mantenere delle barriere all’ingresso molto basse per chi vuole ed è in grado di contribuire. Avere una documentazione degna di nota, predisporre strumenti per far familiarizzare un nuovo programmatore con la codebase, avere strumenti per tracciare le regressioni dovute a pezzi di codice in modo che un nuovo contributo non sia visto dai core developer come un fardello da mantenere etc… Naturalmente progetti che inseguono le feature da subito lasciando in secondo piano questi aspetti arriveranno ad un punto in cui la complessità del progetto finirà per scoraggiare anche il più abile dei programmatori.

    Il lato umano è invece quello che interviene quando si decide di non accettare un contributo. Ci sono 1000 motivi per non accettare un contributo, ma 0 per cui si possa evitare di dare una spiegazione e liquidare una persona volenterosa (stiamo parlando di gente che arriva “patch in mano”) con un “mantieniti una tua versione”.

    L’uovo di colombo in questo caso consiste nel facilitare la collaborazione al progetto nelle modalità giuste e fare della partecipazione un processo inclusivo. Secondo me un qualsiasi programmatore che si presenta con una patch (che non sia qualcosa di triviale) va accolto come un “potenziale” futuro core developer e sarebbe bene accompagnarlo all’interno del progetto sia tecnicamente che umanamente per vedere se è in grado si esprimere quel potenziale.

    Solo in questo modo si può creare quel ricambio essenziale a mantenere vivo il progetto a lungo termine.

  • http://dottorblaster.it/ Bl@ster

    Esattamente, il punto sta proprio nel non essere scortese. Ogni modifica, anche non accettata, va comunque un minimo discussa e il contribuente non deve avere l’impressione di trovarsi davanti a un muro di mattoni anzichè davanti a persone :P

  • http://andrealazzarotto.com/ Lazza

    Magari hanno trovato scortese uno che dopo mesi di studio sull’interfaccia e definizione della Vision arriva e dice “io sono più bravo, vi ho fatto tutto”. Ipotizzo eh, succedono cose simili anche nei LUG…

  • http://twitter.com/emanuele_r Emanuele Rampichini

    Mi sono andato a leggere tutta la discussione sulla mailing list e devo dire che il comportamento degli sviluppatori e di chi ha contribuito è stato nel caso della di gimp estremamente corretto. Sono state date tutte le motivazioni del caso sulla patch e su cosa fosse interessante e cosa no, tutto in un ambiente calmo e rispettoso delle reciproche posizioni.

    La mia era un’opinione generale e non legata a nessuna vicenda in particolare. ;-)

  • http://andrealazzarotto.com/ Lazza

    Infatti lo sospettavo anch’io, per questo rispondevo a Bl@ster. :)

  • telperion

    Il comportamento, nel caso specifico, sarà pure formalmente corretto, ma ne fatti, evita di ridiscutere, mettere mano al tallone d’achille dei gimp, ovvero l’interfaccia più farraginosa e confusa mai vista, e il recente lavoro fatto per l’interfaccia unica, non migliora affatto la situazione, anzi.
    Come dici tu il punto in cui la complessità del progetto finisce per scoraggiare anche il più abile dei programmatori. è già arrivata da un pezzo, frutto di continue aggiunte su aggiunte ad uno schema base errato di partenza (parlo sempre di interfaccia) mentre ad esempio progressi vengono fatti nel motore grafico (lasciamo perdere GEGL per ora che trasforma gimp in un bradipo su un quadcore) mentre l’interfaccia resta quella di 6 anni fa.
    E gli utenti passano ad altro …
    Ovvio queste sono mie considerazioni personali.

    PS leggo sempre i tuoi articoli su AD, e ti faccio i miei complimenti.

  • http://dottorblaster.it/ Bl@ster

    Piccolo OT: GEGL lo abiliti a tempo di compilazione?

  • http://andrealazzarotto.com/ Lazza

    “l’interfaccia più farraginosa e confusa mai vista”
    “lasciamo perdere GEGL per ora che trasforma gimp in un bradipo su un quadcore”
    Sei sempre libero di dimostrare di sapere fare di meglio. A fare critiche “a bomba” siamo capaci tutti, io, tu, Bl@ster, chiunque… Ma lasciano il tempo che trovano.

  • http://dottorblaster.it/ Bl@ster

    È proprio questo il problema: persone che l’hanno fatto… e si sono sentite dire “si ma adesso abbiamo altre priorità”.
    Ciò che mi fa specie peraltro è che gli stessi sviluppatori di GIMP *sanno* che l’interfaccia è pessima (e non parlo dei multipli pannelli flottanti, che a me piacciono), ma preferiscono… beh il resto l’hai letto :D

  • http://andrealazzarotto.com/ Lazza

    “e non parlo dei multipli pannelli flottanti, che a me piacciono”
    Il punto è che la gente che parla a sproposito critica 24 ore su 24 i pannelli flottanti, che oltre ad essere utili sono anche assai simili a quanto si ha con Photoshop su Mac, quindi si straparla tanto per nulla. Le priorità sono altre, ovvio…
    GIMP non supporta ancora la quadricromia, oltre a tante altre cose… Se permetti la GUI si riesce ad usare anche adesso.

    Ah tra parentesi, come ti ho già detto, diverse proposte fatte da quel tizio verranno integrate in GIMP, specialmente la parte dei pennelli. Le modifiche alla GUI sono un’altra cosa, semplicemente perché sono avventate e cozzano con la vision generale. Perciò prima di accettare qualsiasi cosa, i developer saggi ci riflettono un attimo. E poi posticipare non è rifiutare.

  • telperion

    lazza mavaffa … provocatore del c.

    scusami blaster ma sto cogli. supponente proprio non lo reggo.

    Paece&love

  • telperion

    lo lo abiliti dai menu colore e visualizza, di default non è attivato.
    Visualizza uda gegl per renderizzare l’immagine in finestra, colori lo usa per le operazioni con i vari filtri.

  • http://andrealazzarotto.com/ Lazza

    Mi fa davvero ridere che uno dopo aver mollato critiche gratuite sul lavoro di sviluppatori che ci hanno permesso di avere un software di tale livello, venga a dire “supponente” al primo che capita.
    Ti prego, continua… :D

  • Anonymous

    Nel mio piccolo di sviluppatore, condivido appieno.
    Seguo parecchio la scena open spulciando tra github, ohloh, sourceforge ecc ecc e molti progetti assolutamente promettenti arrivano a un punto morto unicamente per via della “immaturità” del core developer di turno. E proprio l’immaturità (unita spesso alla flessibilità mentale di un palo della luce) è la causa della mal riuscita di un sacco di programmi open.
    Insomma, siamo tutti buoni a straparlare di open source ma poi quando si coda diventiamo gelosi come delle siciliane nei confronti dei nostri prodotti ^^’
    Concordo pienamente anche sul discorso del “fork selvaggio” come pessima abitudine, anche se spesso proprio a causa della testardaggine di chi tira le fila del progetto in questione è l’unica soluzione :S

    Ciao e complimenti per il blog, ti leggo spesso anche se non ho mai commentato

  • http://dottorblaster.it/ Bl@ster

    Grazie a te per il commento, non conoscevo Oloh e mi sembra una piattaforma fantastica :)

  • FkCek

    “Il punto è che la gente che parla a sproposito critica 24 ore su 24 i pannelli flottanti, che oltre ad essere utili sono anche assai simili a quanto si ha con Photoshop su Mac, quindi si straparla tanto per nulla.”

    Funzionano in maniera differente, quelli di GIMP perdono il focus a ogni click.

  • FkCek

    “Il punto è che la gente che parla a sproposito critica 24 ore su 24 i pannelli flottanti, che oltre ad essere utili sono anche assai simili a quanto si ha con Photoshop su Mac, quindi si straparla tanto per nulla.”

    Funzionano in maniera differente, quelli di GIMP perdono il focus a ogni click.

  • telperion

    oppure si fa un golpe come ffmpeg (e scusa se è poco)
    http://www.ossblog.it/post/7336/ffmpeg-nuova-gestione

  • telperion

    Ecco spiegaglielo tu, l’orrido bordello del focus su gimp, che io ho consumato i tasti della tastiera.

  • http://dottorblaster.it/ Bl@ster

    Ah questa me l’ero persa :D
    Un altro argomento (e anche grosso) contro il “forka o muori” :P

  • http://jellycube.org tragic0mic

    Si avevo letto… personalmente condivido i motivi dell’incazzatura contro niedermayer, ma mi chiedo cosa farà adesso lui e soprattutto quali saranno gli sviluppi (fork del fork?)

  • http://dottorblaster.it/ Bl@ster

    Beh il software rimane quello ;)
    Hanno isolato il tizio, e buona lì :P

  • telperion

    Comunque un fork non è cosa semplice, specie per grandi codici.
    Per forkare seriamente bisognerebbe avere:
    - un team almeno paritetico come numero/competenze a quello originale
    - almeno uno sviluppatore del team originale che conosce bene tutto il codice
    - la stessa quantità di denaro disponibile, e le infrastrutture

    altrimenti il fork si esaurisce molto rapidamente.

    E i developer lo sanno benissimo, ecco perchè “se non ti piace forkalo” è una gran presa per il culo, ed ecco anche perchè “se non ti piace invece di criticare fallo tu” è un’altra fesseria retorica.
    Dammi mezzi e team paritetici all’originale, e vedi se te lo faccio io, e pure meglio.

    LOL

  • http://andrealazzarotto.com/ Lazza

    Non ho detto che sono identici, né che l’interfaccia di GIMP (o di Photoshop) sia perfetta. Non esistono interfacce perfette (anche se la Apple cerca di convincerci da anni del contrario). La GUI di GIMP è migliorabile, anche se va tenuto conto che i cambiamenti radicali vanno fatti con cautela. Diamine, c’è gente che è impazzita persino quando hanno cambiato il tema di Facebook. XD
    Non sono sicuro di aver capito a quale problema di focus ti riferisci, immagino tu intenda quello che avviene su GIMP per Mac. In quel caso è colpa di X11 di Apple, ma comunque nessuna paura. È facilmente risolvibile, come scritto qui: http://gimpitalia.it/download/install_mac
    Se invece ti riferivi ad altro allora ho capito male. :P