brightside
elephant
fundacioTiC
turro.org
El primer cop que vam obrir el codi va ser el 2002. En aquell moment Blai Capdevila i jo mateix ens barallàvem per trobar una solució a la comptabilitat sense assentaments. Comptabilitat documental basada en models. El projecte es deia XMLVocabulary, s'allotjava al domini xmlportal.net i va assolir la mitjana de 30 mil descàrregues mensuals. Mentre ens deixàvem els ulls en la creació de models, a altres llocs del mon desenvolupadors trobaven utilitats ben diferents a allò que estàvem fent. Una de les sorpreses més grans va ser quan una empresa de telecomunicacions a Taiwan va començar a usar el codi dins el seu seguiment d'incidències, afegint suport LDAP, i passant-nos el resultat traduït al xinés. Aquell dia no vaig dormir.
Entenent el risc, acceptant la ignorància
Tinc que dir que sóc poc ortodox. La metodologia utilitzada en aquells moments per vendre desenvolupament de software em semblava escandalosa, poc responsable i gens productiva. Encara ara hi ha gent que continua fent el mateix. I segueixo escandalitzant-me. Primer, no sempre s'entrega el codi. Segon, se li demana al usuari que accepti el disseny de formularis on breument es descriu la operativa. Tercer, es comença el desenvolupament pels formularis. Els supòsits de semblant metodologia són, que l'analista ha entès perfectament què vol el client i que aquest ha sabut explicar què vol a la perfecció. Es comença per la taulada perquè es suposa una bona fonamentació. Això no és cert, mai pot ser-ho.
El desenvolupament de software no s'hauria de vendre, simplement perquè comprar-lo és una ruïna. Entenem-nos, comprar el desenvolupament d'una solució completa no és recomanable. Desenvolupar és una inversió, no una despesa. Desenvolupar és car i no sempre surt bé. Segons les noves tendències, el software està en una constant fase beta on cada incidència és tractada amb màxima cura. El software està en constant millora, s'adapta i creix.
En casos reals, quan es decideix iniciar un nou projecte, l'anàlisi i el desenvolupament són només una part del tramat. Cal la plena implicació de l'usuari avançat. Aquell que entén quin és l'objectiu i és capaç de trobar on falla. I tot mitjançant l'ús, sense tocar el codi. Reportant cada incidència amb tots els detalls i donant idees. L'èxit d'un projecte es mesura en la quantitat d'usuaris avançats que reporten incidències i en la rapidesa en que es desenvolupen les solucions. L'usuari coneix i el desenvolupador realitza. L'analista catalitza el procés.
Particularitats, camins al no res
Fa més de deu anys que no desenvolupo codi que no vagi al tronc principal de Elephant i BrightSide. Això vol dir que tots els usuaris usen el mateix tronc. Ja ho dic ara, les dues aplicacions tenen usuaris ben diversos, des d'autònoms a petites i mitjanes empreses. L'ús que en fan és també molt divers. Què passa doncs amb les particularitats?
Quan un usuari demana una particularitat, allò que no serà útil a ningú més, el primer que faig és intentar eliminar-la. Dràstic? No pas. Iniciar una branca de codi per una particularitat només pot acabar malament. Per una banda, la resta de mòduls creix ignorant-la i podem acabar amb una incompatibilitat. Per altre banda, al no estar en el tronc principal, no es millora ni creix al mateix ritme. Amés, eliminar-la no sempre vol dir no fer-la. També pot dir tornar-la genèrica, es a dir, afegir-la al tronc principal i deixar que la resta d'usuaris en gaudeixi.
Tornar una particularitat en una característica general és un mal de cap. Primer cal barallar-se amb els conceptes, de particulars per una funcionalitat concreta a generals per tot. Després cal, per això és genèric, més configuració. El resultat, però, és més funcionalitat pel conjunt. Tothom hi guanya.
Quan és impossible la transformació a genèric cal provar a incorporar-ho sense que es noti. La via més ràpida són les factories de classes o funcionalitat afegida. Reconeixes una interfície però no saps qui la implementa. Un cop fet el reconeixement, implementes la interfície com un mòdul endollable.
Si finalment cap de les solucions anteriors és possible, crees la versió especial per aquella particularitat, sabent que tard o d'hora es transformarà en un malson.
Publicant el coneixement
El programari obert és coneixement aplicat. Al codi s'hi suma tot el que sap l'usuari avançat. La qualitat dependrà de la maduresa del projecte, dels coneixements de les eines que tingui el desenvolupador i del coneixement de l'objectiu que es pretenia assolir per part de l'usuari. El programari obert estalvia feina a tercers i permet integrar projectes. Això afavoreix la col·laboració i resulta en una millora pels elements integrats, converteix projectes sencers en usuaris avançats reportant incidències.
A cadascú el que li toca
Haureu notat que li dono especial importància a l'usuari avançat. Bé, encara pot tenir-ne més, normalment és així.
Els casos pràctics m'han ensenyat que sense un usuari que estigui disposat a implementar el projecte en el mon real, aquest no té masses possibilitats d'èxit. Disposició per anar provant en la mesura que es va fent, en els punts on s'aconsegueixen fites. Això vol dir temps, paciència i molta implicació. Com sigui, crec que cal donar-los el reconeixement que mereixen i traduir-ho en compensacions.
La millora constant afavoreix compensar la dedicació dels usuaris avançats d'una manera ben fàcil: gaudint de les millores que ells mateixos han proposat, més d'aquelles que hagin proposat d'altres. La Fundació TiC rep les contribucions de Turro.Org i les publica sense cap cost, en un intent de convertir el teixit empresarial català en un usuari avançat. Queda molt per fer, però ja hem començat.
