Desenvolupament col·laboratiu

Establir la necessitat d’experiència en codi obert com a condició de solvència tècnica.

Per moltes condicions que es posin al contracte, si l’empresa adjudicatària no té experiència participant en projectes de codi obert, el més probable és que el producte no acabi sent obert del tot. En la majoria de casos això no té perquè ser resultat d’una mala disposició, sinó fruit del desconeixement.

Ho han de fer aportant referències a la seva participació individual en repositoris i fòrums oberts (StackOverflow, etc.), dels projectes en que hagin participat.

Es pot fer constar aquesta demanda com a criteri de solvència tècnica o com a criteri d’execució.

Això és més important en projectes de codi obert que en projectes tradicionals perquè adquirir usuaris i desenvolupadors fora dels confins de l’Ajuntament pot determinar el grau d’èxit del projecte.

Es poden trobar algunes indicacions més concretes a http://producingoss.com/en/getting-started.html#choosing-a-name.

La declaració de propòsit és un text curt, d’un o dos paràgrafs, que permet a la gent decidir en 30 segons si els interessa seguir llegint sobre el projecte o no. Ha d’anar acompanyada dels enllaços necessaris per si la resposta afirmativa. En el redactat es pot donar per suposats uns coneixements mínims de l’àrea d’aplicació del projecte. Les persones que no disposen d’aquests coneixements probablement no estaran interessades en el projecte.

El text s’ha de tenir redactat com a mínim en anglès i en català, per utilitzar la versió que convingui en cada cas.

Ha d’aparèixer com a mínim als següents llocs:

És important, a més, indicar sota quina llicència concreta es distribueix el programari (incloent la versió), utilitzant el nom complert o bé l’identificador, el que més convingui en cada cas, exactament com apareixen a https://spdx.org/licenses/. Especificar la llicència com a mínim en els següents llocs:

En quant a la web orientada a usuaris del projecte, és important no relegar aquesta informació a una pàgina de «descàrregues» o de «desenvolupament» que requereixi més d’un clic.

Serveix per què la gent acabi de decidir si el projecte pot cobrir o no les seves necessitats.

Enllaçar de forma visible com a mínim des de:

Millor en forma de llistat amb vinyetes i frases simples, o d’una manera encara més gràfica. Molts cops és una mena d’extensió de la declaració de propòsit.

Si una funcionalitat encara no està implementada es pot especificar entre parèntesis: planned o work-in-progress.

Especificar i mantenir una pàgina amb l’estat de desenvolupament del projecte, no té sentit, i de fet pot ser molt contraproduent, falsejar o exagerar els veritables mèrits tècnics del producte.

Per exemple quina arquitectura hardware/software es necessita per instal·lar-ho, quin sistema operatiu, etc. També és una informació necessària per què un potencial usuari esbrini si pot utilitzar la solució o no.

Enllaçar de forma visible com a mínim des de:

Millor en forma de llistat amb vinyetes i frases simples.

Es tracta d’escriure un llistat, que es va actualitzant periòdicament a cada release o fita important, que contingui:

L’objectiu d’aquesta pàgina és contribuir a visibilitzar tres coses:

Enllaçar com a mínim des de:

És molt important ser transparents i no falsejar l’estat real del projecte. És més perniciós atraure usuaris amb expectatives que no es podran complir que no pecar de conservadorisme a l’hora d’exposar el progrés realitzat o esperat. Tots els projectes tenen defectes i facilita la vida a tothom (desenvolupadors, promotors del projecte i potencials usuaris externs) tractar-los amb transparència. Molts projectes de programari lliure exitosos contenen a la seva pàgina un apartat titulat "Known bugs", i alguns d’aquests defectes romanen allà durant anys.

A més, en el cas del codi obert, tot el codi i tot el procés de desenvolupament està a la vista de tothom, i tothom pot instal·lar i provar el producte. Qualsevol pot refutar les nostres afirmacions si no son certes, com s’explica a http://producingoss.com/en/marketing.html#goldfish-bowl.

No incloure al codi dades específiques d’un desplegament, o d’un client.

La parametrització, tant del procés de build com de l’execució, s’ha de poder realitzar a través de fitxers de configuració, fins i tot si hi ha altres mètodes (per exemple, opcions de línia de línia de comandes). Aquests fitxers de configuració s’han de mantenir en un repositori privat diferent.

Això fa més senzilla la reutilització del codi. És incorrecte posar la configuració:

És molt important no esperar gens a construir i documentar un sistema de build del programari, ja que sense això l’esforç que ha de realitzar qualsevol desenvolupador per provar l’eina serà probablement massa gran com perquè ningú ho intenti.

La documentació ha de ser suficient perquè un tercer entengui com configurar i desplegar el producte. Les organitzacions adjudicatàries de contractes han d’entendre que no tindran el monopoli de la configuració, desplegament i manteniment del producte.

Per suposat no es pot obligar als usuaris i potencials col·laborador d’un projecte de codi obert a dependre d’eines que no siguin alhora programari lliure, i dins d’aquestes convé triar les d’ús més estès i que resultin més familiars a la majoria de desenvolupadors. Això últim pot variar d’una comunitat a una altra. Alguns exemples d’eines de build (algunes també serveixen per als procediments de configuració i instal·lació) d’ús comú i que recomanem son:

Com a condició de transparència, el codi font que en cada moment s’utilitza per construir (build) i desplegar els serveis en producció ha d’estar disponible en el repositori públic de l’Ajuntament, preferentment sota la branca master. Qualsevol patch de seguretat, millora o modificació de qualsevol tipus que s’apliqui al codi en producció s’ha de reflectir al repositori.

El codi disponible al repositori públic és el que està cobert totalment per una llicència lliure. No s’hi pot fer cap afegit.

Les interfícies web d’usuari, tant les d’ús per als ciutadans com les d’administració i ús intern, han de complir amb els estàndards del World Wide Web Consortium (W3C) i no han de requerir l’ús de funcionalitats proporcionades per extensions propietàries dels navegadors.

La presentació s’ha de visualitzar correctament, i el producte ha de ser plenament funcional, amb els navegadors de la família:

Tot l’intercanvi de documents amb el ciutadà que impliqui la descàrrega o càrrega de fitxers s’ha de produir exclusivament amb formats oberts, segons la definició que en dona la Guia de Compra Tecnològica de l’Ajuntament de Barcelona.en/tech-sovereignty:interoperability.adoc.

Pels documents de text, fulls de càlcul i presentacions, els següents formats son acceptables:

Rebutgem formats propietaris com els de Microsoft Office i Apple iWork (.doc[x], .ppt[x], etc.)

L’intercanvi d’imatges, àudio i vídeo també es realitzarà mitjançant formats oberts pels quals existeixin implementacions lliures en les principals plataformes informàtiques incloent GNU/Linux.

Tots els missatges mostrats a l’usuari han d’estar internacionalitzats. Utilitzar els mecanismes habituals en cada llenguatge/plataforma.

L’eina estàndard per a missatges multi-lingües en projectes de programari lliure és gettext.

Abans de publicar sota llicència lliure un component o sistema software ja existent i en ús a l’Ajuntament de Barcelona cal comprovar que:

Es tracta d’explicar que el projecte ha funcionat fins a un determinat moment com un projecte tancat i per tant cal esperar certes inconveniències. Convé reduir les expectatives del nous usuaris i desenvolupadors en quant a qualitat i transparència d’alguns elements del projecte. S’han d’explicar els compromisos als que s’ha hagut d’arribar per fer possible l’obertura. Per exemple, és possible que en el repositori de codi hi hagi moltes dades sensibles (dades d’usuaris concrets, etcètera) i que s’hagi optat per perdre l’historial del control de versions i crear un repositori nou top-skim que només contingui la darrera versió.

Aquesta informació convé publicar-la com a mínim a:

L’objectiu d’aquesta mesura és evitar un allau de peticions inassumibles.