4.4 Model de desenvolupament de projectes de Programari...

El model de desenvolupament FOSSCrıtiques al model de desenvolupament FOSS

4.4 Model de desenvolupament de projectes deProgramari Lliure

Josep M. Ribo

Universitat de Lleida

2 de juliol de 2012

Josep M. Ribo 4.4 Model de desenvolupament de projectes de Programari Lliure


Outline

1 El model de desenvolupament FOSSUn model de desenvolupament de programari privatiuLa Catedral........ i el Basar

2 Crıtiques al model de desenvolupament FOSSCrıtiques referens al model de desenvolupament FOSSCrıtiques respecte el model de negoci FOSSCrıtiques respecte la qualitat dels projectes FOSSPerspectives del model de desenvolupament FOSS



Un model de desenvolupament de programari privatiuLa Catedral........ i el Basar

Index






Algunes idees basiques per comencar

Tradicionalment, l’enginyeria de programari s’ocupa del desenvolupamentde sistemes de programari de mida mitjana i gran:

Per part d’un equip d’enginyers/programadors

A traves d’un model de desenvolupament de programari

Al desenvolupament d’un sistema de programari especıfic se l’anomenaprojecte de desenvolupament de programari

Si es tracta d’un sistema de programari llicenciat com a programari lliure,parlem d’un Projecte de desenvolupament FOSSFOSS= Free/Open Source Software

El model de desenvolupament de programari defineix el proces quecas seguir per tal de completar un projecte de desenvolupament deprogramari.




Algunes idees basiques per comencar (2)

El model de desenvolupament de programari consisteix en unaserie d’activitats que cal desenvolupar en un ordre adient amb unesrestriccions especıfiques i determinades pel propi model.

Aquestes activitats inclouen:

Captura de requeriments de programari,Especificacio,Disseny,Test (verificacio i validacio),Manteniment-evolucio,Gestio del projecte...

Aquestes activitats solen usar notacions estandar (UML, OCL,casos d’us, DFDs...)

La qualitat s’assoleix seguint el model sistematicament d’acord a laplanifiaccio, costos i riscs estimats pel cap del projecte (projectmanager).




Index






El model de desenvolupament de programari Catedral

Els processos de programari s’han vingut desenvolupant tradicionalmentusant el que Raymond anomena estil catedral [Ray2000]:

Gestio del projecte centralitzat,

Llista tancada de desenvolupadors i beta-testers

Poques distribucions (nomes de versions estables),

Model de desenvolupament estricte (sovint, iteratiu),

Us extensiu de documents formals

Les fases de disseny i implementacio son desenvolupades per expertsaıllats dels usuaris,

Usualment,

El programari es desenvolupat per experts per assolir elsrequeriments establerts per un client.Els desenvolupadors no son usuaris del programari.




Index






El model de desenvolupament de programari Basar

El 1999, Eric S. Raymond vaplantejar com n’era de diferent eldesenvolupament d’un projecte deprogramari lliure (FOSS) respecteun de tradicional.

Va anomenar model basar almodel de desenvolupament deprojectes FOSS.

El proces desenvolupament de programari de codi obert [es] elproces d’usar sistematicament el desenvolupament obert i larevisio d’iguals (peer review) per reduir els costos i incrementarla qualitat del programari.Eric S. Raymond (La catedral i el basar) [Ray2000]




El model de desenvolupament de programari Basar

Els projectes FOSS habitualment s’originen per tal de resoldre unanecessitat o interes d’un desenvolupador (scratch an itch).

L’iniciador del projecte crea un prototipus d’una aplicacio.Usualment el crea ell mateix o amb un molt reduıt equip dedesenvolupadors.

El prototipus es distribuıt a la comunitat i el seu desenvolupamentcontinua en comunitat.

Aquesta es propiament la fase basar.




El model de desenvolupament Basar

Als projectes de programari tradicionals, els desenvolupadors hand’assistir a la catedral, escoltar l’homilia del bisbe (cap del projecte)i actuar en consequencia.

Als projectes FOSS, els desenvolupadors participen a les discussionsd’un basar de carrer i actuen segons indica la majoria delsparticipants o els participants mes experts i respectats.




Per que es caracteritza el desenvolupament durant la fasebasar?

Un grup petit de desenvolupadors centrals (core depvelopers) iuna com-mes-gran-millor comunitat de usuaris/col.laboradors(voluntaris).

Desenvolupament i depuracio es fan concurrentment per part delsdesenvolupadors i dels usuaris/col.laboradors.

Revisio d’iguals ( peer review)

Distribucions rapides i frequents.

S’escolta als usuaris/col.laboradors.

L’organitzacio es basa sovint en una meritocracia i un dictadorbenevolent.

El disseny ha de ser simple i modular.




Desenvolupadors centrals i usuaris/col.laboradors

Desenvolupadors centrals

1-5 es el nombre habitual.

Son els responsables del disseny i del desenvolupament del projecte.

Tenen permisos per tal d’enregistrar els canvis al repositori del codidel projecte.

Usualment, un d’ells es el coordinador/lıder del projecte.Aquest lıder es habitualment el dictador benevolent.





Usuaris/col.laboradors

Poden ser centenars o milers....

Son voluntaris.

Usen el programari i el depuren.

Poden proposar nous requeriments.

Poden enviar pegats (patches) per resoldre errors.

Poden enviar codi que implementi noves funcionalitats.

Alguns col.laboradors molt actius poden esdevenir desenvolupadorscentrals.

En general, els col.laboradors no tenen permisos d’escriptura sobre elrepositori.





La llei de Linus (probablement l’essencia del model basar)

Si es te un nombre important de codesenvolupadors i col.laboradors,quasi qualsevol problema es podra caracteritzar rpidament i la sevaresolucio sera obvia per algu.(Eric S. Raymond)

Dit d’una altra manera...Donat un nombre suficient d’ulls, tots els errors son visibles.

Llei de Pareto

El 80% del codi el desenvolupa el 20% dels desenvolupadors.

20% del codi el desenvolupa el 80% dels desenvolupadors.(inclou els pegats enviats pels col.laboradors).




Desenvolupament i depuracio concurrents

Objectiu:

Fer que el desenvolupament i la depuracio d’un projecte FOSS esfaci tan en paral.lel com sigui possible amb tants col.laboradors comsigui possible.

Escoltar als usuaris i col.laboradors. Les seves idees son els aspectesmes valusoso en un projecte FOSS.

Alliberar noves versions del projecte tan aviat com sigui possible.

Per que:

Aquesta poıtica accelerara el desenvolupament del projecte i mantindraels desenvolupadors i els col.laboradors actius.




Revisio per iguals

Objectiu:

Incrementar la qualitat del programari promovent la inspeccio per altresdesenvolupadors o col.laboradors del codi ja escrit.

Per que:

La practica de la revisio per iguals esta reconeguda com una moltbona practica de control de qualitat.

Un benefici d’obrir el codi a la comunitat es que qualsevol potrevisar el codi i cercar errors.

La consciencia de que el codi que hom escriu sera vist i revisat peraltres fa que el codi escrit sigui, en general, millor.

Els projectes FOSS exitosos es beneficien d’una gran base decol.laboradors i desenvolupadors que inspeccionen el codi peridentificar punts febles i errors.




Distribucions rapides i frequents

Objectiu

Distribuir noves versions, incorporant pegats als errors coneguts tan aviatcom sigui possible.

Per que:

Els col.laboradors no es distreuen amb antics errors pels quals jaexisteix un pegat.

EL projecte es percep com a viu i aixo estimula els col.laboradors iseguir fent-hi contribucions.

Els col.laboradors mantenen el projecte a la seva ment.




Dictador benvolent

Objectiu

Les aptituds personals i tecniques del lıder del projecte han d’ajudar aque el frojecte FOSS progressi de manera continuada.

Pe que:

Un projecte FOSS es una meritocracia en la que elsdesenvolupadors obtenen el prestigi dels seus iguals a partir de lesseves habilitats tecniques i de la valua de les seves aportacions alprojecte.

El lıder del projecte ha de tenir aquest tipus de prestigi entre elsusuaris, col.laboradors i desenvolupadors del projecte.

El lıder del projecte actua usualment com un dictador benevolentque te la responsabilitat de prendre les decisions en cas de conflicteen que diferents parts no poden arribar a un acord.




Dictator benevolent (2)

De tota manera, el lıder del projecte ha d’usar aquest poder demanera responsable, doncs:

Els col.laboradors i els desenvolupadors son sovint voluntaris i, pertant, poden abandoanr el projecte quan ho desitgin,

Encara mes: poden crear un nou projecte (bifurcacio o fork) sipensen que el lıder actua d’una manera irresponsable.

En la majoria dels casos, el seny preval i el dret a fer un fork d’unprojecte s’usa en molt comptades ocasions.



Crıtiques referens al model de desenvolupament FOSSCrıtiques respecte el model de negoci FOSSCrıtiques respecte la qualitat dels projectes FOSSPerspectives del model de desenvolupament FOSS

Crıtiques al model de desenvolupament FOSS

Tradicionalment, el model de desenvolupament FOSS amb filosofia basarha patit crıtiques que podem encabir en tres categories diferents:

Crıtiques referens al model de desenvolupament FOSS.

Crıtiques referens al model de negoci FOSS.

Crıtiques referens als aspectes de control de qualitat dels projectesFOSS.

Parlem-ne una mica....




Index






Crıtiques referens al model de desenvolupament FOSS

Els col.laboradros en un projecte FOSS poden ser volatils [Ray2001]

Els projectes FOSS no tenen una gestio de projecte convencional[Ray2001]

La llei de Brook [Ray2001]

Els projectes FOSS no tenen un proces de disseny formal [Fitz2005]

El proces de desenvolupament FOSS no es en realitat un nou modelde proces [Fug2004]

Els projectes FOSS depenen de la modularitat. Pero moltamodularitat pot dur a problemes d’acoblament [Fitz2005, Ruso2005,Scac2002]

Els avantatges del FOSS son nomes clars per aquelles aplicacions perles quals els usuaris son tambe programadors [Glas2005]

Proliferacio de versions en productes FOSS es problematica[Fitz2005]

La majoria dels projectes FOSS no reeixeixen.




Els col.laboradros d’un projecte FOSS poden ser volatils

Crıtica:Els projectes FOSS poden tenir un gran nombre de col.laboradors i/odesenvolupadors, pero no sempre es mantenen en el temps.

Entretant, els clients esperen que aquell programari tingui una continuıtati, per tant, una innovacio i manteniment continuat.

Pero...

Molts projectes FOSS han perdurat molts anys (e.g., linux, apache,firefox, thunderbird,...)

Tambe hi ha projectes de codi privatiu que es deixen de mantenir ievolucionar. Si aixo passa els seus usuaris tenen un problema moltimportant doncs, en ser el codi tancat, no hi ha manera de queningu de la seva comunitat d’usuaris els faci evolucionar.




Llei de Brook

Llei de Brook:Afegir desenvolupadors a un projecte de programari endarrerit fa ques’endarrereixi encara mes.Aixo es degut a:

El proces d’aprenentatge que hauran de passar les novesincorporacions al projecte.

L’increment del volum de comunicacio entre el grup dedesenvolupadors (un increment lineal en el nombre dedesenvolupadors porta a un increment quadratic en lescomunicacions).

Pero...Aquest efecte es redueix al model basar ja que els col.labordors sonessencialment independents els uns dels altres.L’increment del volum de comunicacions afecta nomes al grup dedesenvolupadors centrals. Ells son els qui reben les comunicacions delgrup de col.laboradors.




Llei de Brook (2)

Exemple: Apache:

La feina dels desenvolupadors centrals es implementar novesfuncionalitats (10-15 desenvolupadors centrals desenvolupen el 88%del codi nou).

La feina dels col.laboradors es essencialment, detectar errors iproposar pegats:

10-15 desenvolupadors centrals envien menys del 5% dels errors iprodueixen el 66% de les reparacions (vs. 88% de codi nou) .Milers de col.laboradors de la comunitat Apache detecten (i envien)la major part dels errors.

Aquesta feina es pot fer de manera independent sense incorrer ensobrecarrega en les comunicacions.




Els projectes FOSS no tenen una gestio convencional deprojecte

Crıtica:El model FOSS menyste el factor multiplicador de la productivitat de lagestio convencional de projectes.

Pero...Segons Raymond [Ray2001], la tasca d’un gestor de projectes es o beinnecessaria en projectes FOSS o be realitzada pel lıder del projecte opels desenvolupadors.

Revisem el seu punt de vista....




Els projectes FOSS no tenen una gestio convencional deprojecte (2)

Segons Raymond [Ray2001], les tasques d’un gestor de projectes son:

Definir els objectius del projecte (FOSS: lıder del projecte)

Monitoritzar el projecte i els seus detalls (FOSS: revisio per iguals)

Motivar el personal per fer la feina avorrida (FOSS: Hi hacol.laboradors pels quals una determinada feina no es avorrida).

Organitzar el personal per maximitzar la productivitat (FOSS: Elsdesenvolupadors de projectes FOSS estan altament motivats).

Assignar recursos per desenvolupar el projecte (FOSS: Innecessari)




Els projectes FOSS no tenen un proces formal de disseny

Crıtica:Al model de desenvolupament Basar no hi ha un proces formal real dedisseny. No hi ha avaluacio de riscos ni objectius mesurables. No hi haincentius economics per la majoria dels desenvolupadors. [Fitz2005]

Pero...

Moltes decisions importants en relacio a l’analisi de requeriments,disseny i analisi de riscos es prenen abans que el projecte arribi ala fase Basar.

Molts projectes FOSS existosos s’han iniciat en el context d’unaempresa de programari amb personal assignat i amb una gestio deprojecte tradicional. Posteriorment, s’han convertit en projectesFOSS publics.




Els projectes FOSS no tenen un proces formal de disseny(2)

Pero... (cont.)

L’analisi de requirements es mes facil que en desenvolupament deprogramari tradicional perque la majoria dels desenvolupadors sontambe usuaris.

El disseny dels projectes FOSS es, usualment, molt modular per fermes senzilla la seva extensio.




El proces de desenvolupament FOSS no es en realitat unnou model de proces

Crıtica:

La majoria dels projectes FOSS estan desenvolupats, en realitat, pernomes un o dos desenvolupadors.

Els projectes FOSS grans (Linux, Apache, Mozilla) tenen un modelmolt ben estructurat que s’assembla al dels projectes privatius.

Algunes caracterıstiques dels projectes FOSS es poden observartambe en els privatius.

[Fug2004]




El proces de desenvolupament FOSS no es en realitat unnou model de proces (2)

Pero....El model Basar es clarament innovador en molts aspectes:

Depuracio paral.lela i desenvolupament per part d’un conjunt decol.laboradors distribuıts i interoperant per internet.

Proces de revisio per iguals.

Relacio de meritocracia entre col.laboradors.

Polıtica de distribucions rapides.

El codi del projecte pot ser estudiat i millorat per qualsevol.

Reduccio de la burocracia.

Els voluntaris que s’afegeixen al projecte solen ser tecnicamentcompetents i estar motivats.




Projectes FOSS i modularitat

Crıtica:Els projectes FOSS depenen fortament de la modularitat. Pero massamodularitat pot dur a problemes d’acoblament que afectin la reutilitzacioi el manteniment [Fitz2005, Ruso2005, Scac2002].

Un exemple especıfic:El nombre d’instancies acoblades al kernel de Linux creixexponencialment amb el numero de versio [SJW2002]

Aquest advertiment cal tenir-lo en consideracio quan esdissenyen/redissenyen projectes FOSS.




Usuaria-programadors

Crıtica:Els avantatges dels projectes FOSS son clars unicament per aquellesaplicacions en que els usuaris son tambe els desenvolupadors [Glas2005].

Pero....Cada cop hi ha mes projectes FOSS en qualsevol domini, en particular, endominis en els quals els usuaris no son especıficament els desenvolupadors(suits ofimatiques, ERPs ...)




Proliferacio de versions

Crıtica:La proliferacio de versions de productes FOSS es problematica. [Fitz2005]Es difıcil mantenir diferents versions del mateix producte actualitzades.

Es cert. Per aquest motiu, a voltes, nomes les configuracions mespopulars d’un projecte FOSS han estat comprovades suficientment.




Index






Crıtiques respecte el model de negoci FOSS

El model de negoci FOSS pot no ser un model de negoci efectiu.




El model FOSS pot no ser un model de negoci efectiu

Crıtica:El model economic FOSS es poc practic [Glass2005]No es clar si les empreses poden sobreviure i obtenir beneficis simplementvenent serveis [Fug2004]

Pero.....

La possibilitat de “vendre serveis” d’integracio, adaptacio,manteniment i capacitacio de productes FOSS permet la creacio depetites i mitjanes empreses que proporcionen aquests serveis.Actualment hi ha moltes empreses que es limiten a vendre paquetsprivatius i enviar royalties a l’empresa matriu del programari).

No tot el programari es ven:

La majoria de desenvolupadors treballen en programari per a la sevapropia empresa i que no es ven [Ray2001c].Molt programari privatiu es dona lliuremnet per mantenir una posiciodominant al mercat (.NET, Internet explorer)




El model FOSS pot no ser un model de negoci efectiu (2)

Cada cop mes organitzacions ( empreses, universitats...) destinentemps dels seus desenvolupadors a treballar en projectes FOSS queson d’interes per a elles.La participacio en aquests projectes FOSS es una aposta estrategicade l’empresa que permet impulsar una determinada tecnologiad’interes per a l’empresa o li dona prestigi.

A vegades, algunes organitzacions amb necessitats similars endeguenun projecte comu per crear un programari que pugui servir a toteselles. Aquest programari el poden llicenciar com a lliure (exemple:Sakai, un campus virtual FOSS desenvolupat per un consorcid’universitats).

Algunes empreses estan interessades en oferir aplicacions FOSS ambmoduls privatius.

Algunes empreses han creat un projecte FOSS i el llicencien ambuna doble llicencia (exemple: MySQL, ZOPE).




El model FOSS pot no ser un model de negoci efectiu (3)

Algunes empreses usen un model de negoci anomenat software as aservice.D’acord a aquest model, els seus clients accedeixen a l’aplicacio perinternet i paguen una subscripcio pel seu allotjament i us.L’aplicacio pot ser FOSS.

Algunes empreses de hardware estan interessades en desenvoluparcontroladors FOSS per a dispositius i aixı facilitar un us mesuniversal dels seus dispositius.

[Ray2001c] fa una descripcio de models de negoci FOSS.




Index






Crıtiques respecte la qualitat dels projectes FOSS

S’han generat crıtiques respecte:

La fiabilitat dels projectes FOSS

La revisio per iguals.

Manca de polıtica formal de testos.

Mala qualitat del codi FOSS.

Manca de documentacio en projectes FOSS.




Fiabilitat dels projectes FOSS

Crıtica:L’afirmacio que els projectes FOSS son mes fiables que els privatius esingenua i indemostrable.[Glas2005]

Pero....

Molts productes FOSS han estat lloats ampliament per la sevafiabilitat (en comparacio amb les seves alternatives privatives):Linux, Apache, Tomcat, JBoss, Mozilla, Gimp...Veieu, per exemple, [Whee2005]

Sovint, les aplicacions FOSS son mes fiables que les privativesequivalents [MKL1995]

La densitat d’errors en els projectes FOSS exitosos es inferior o igualque la dels projectes privatius [Bou2005]




Fiabilitat dels projectes FOSS (2)

Els errors trobats en projectes FOSS se solucionen mes rapidamentque els trobats en projectes privatius ([Bou2005]) perque:

Hi ha mes provadors treballant-hi iEls projectes FOSS distribueixen patches per solucionar els errors enlloc de service packages que contenen les solucions d’una col.lecciod’errors detectats en les darreres setmanes o mesos.Per cert, els service packages son usualment, productes privatius.

En un estudi localitzat a Suıssa l’any 2000, els servidors que usavenprogramari de Microsoft estaven aturats mes del doble de temps queels que usaven Apache.http://web.archive.org/web/20011011215009/http:

//www.syscontrol.ch/e/news/Serversoftware.html

De tota manera, aquests estudis es refereixen nomes als grans projectes.


http://web.archive.org/web/20011011215009/http://www.syscontrol.ch/e/news/Serversoftware.html

http://web.archive.org/web/20011011215009/http://www.syscontrol.ch/e/news/Serversoftware.html



Seguretat dels projectes FOSS

Crıtica:La disponibilitat del codi font es una amenaca significativa a la seguretatde les organitzacions governamentals que usen FOSS, ja que els hackerspoden estudiar aquest codi i explotar les seves vulnerabilitats.[Bro2002]

Pero...

Aquesta frase promou una polıtica de seguretat del programaribasada en la seguretat per l’obscuritat.

L’experiencia no dona suport a aquesta idea:

S’han trobat mes errors en sistemes privatius usats massivament queen els sistemes FOSS corresponents.Com el codi es accessible per a tothom, mes persones podentreballar en aquells errors i resoldre’ls.




Revisio per iguals als projectes FOSS

Crıtica:La hipotesi que el codi lliure es revisat detalladament pels seuslectors/usuaris es falsa. Aquesta revisio es molt minoritaria.[Glas2005]

Pero...

Els procediments de revisio per als projectes FOSS importants sonexhaustius:

Mozilla: Tots els canvis passen dos nivells d’inspeccio.Apache: Els canvis han de ser revisats pel grup de desenvolupadorscentrals.




Depuracio i projectes FOSS

Crıtica:

El 80% dels projectes FOSS no tenen plans de depuracio. Nomes el40% usen eines de depuracio [Glas2005]

Hi ha una manca d’atencio a molts projectes FOSS a tecniques detest basiques, acceptades i madures [Zhao2003].

Els projectes FOSS s’han d’aplicar a moltes configuracions. Es difıcili llarg provar-les totes.




Depuracio i projectes FOSS (2)

Pero...

El 80% de projectes FOSS que no disposa de plans de depuraciocorrespon als projectes petits. No es just avaluar els projectes FOSSpetits amb les mateixos criteris que els privatius grans.

A mesura que els projectes FOSS es fan mes grans, les tecniques dedepuracio dels projectes es fan mes madures.Per exemple: Mozilla disposa d’equips per mantenir els plans de testi usen eines de depuracio automatitzades.

Una part important del proces de depuracio en projectes FOSS la fala comunitat (ex: Apache ha rebut avisos d’errors de milers depersones diferents. Centenars de persones han enviat codi perresoldre aquells errors detectats).




Mala qualitat del codi d’alguns projectes FOSS

Crıtica:Algunes parts del codi de projectes FOSS es dolent [Scac2002, Ruso2005]Heterogeneıtat, manca d’estandars de codificacio...

Pero...

Aquest argument es difıcil d’usar en contra dels projectes FOSS,simplement perque no el codi no es pot comparar amb el privatiu.




Manca de documentacio als projectes FOSS

Crıtica:Usualment, la documentacio no es una tasca atractiva i els col.laboradorsno hi dediquen massa temps.Fins i tot si hi ha voluntaris que volen contribuir en aquest aspecte, rebenpoca ajuda per part dels desenvolupadors del projecte.[Mich2005]

Pero...Hi ha molts projectes FOSS amb una documentacio excel.lent.En particular, els projectes grans o populars solen tenir molt bonadocumentacio, tant per a desenvolupadors com per a usuaris.




Index






Perspectives del model de desenvolupament FOSS

Als darrers anys s’ha observat una evolucio al model FOSS [Fitz2006]

Algunes practiques compatibles amb FOSS comencen a ser apreciadesper les empreses de programari

Model de negoci pagar per serveis de programari.

El programari lliure pot ajudar a la creacio de mercat en un ambitespecıfic de les aplicacions de programari.

Involucrant-se en projectes FOSS, una empresa pot aprofitar-se deles aportacions de la comunitat.

Aixo ha portat a que el model FOSS hagi estat incorporat per un nombrecreixent d’empreses.




Perspectives del model de desenvolupament FOSS (2)

Aquest fet ha portat a una evolucio als projectes FOSS:

Molts desenvolupadors son treballadors d’una empresa ambdedicacio a temps complet al projecte FOSS (pagats per l’empresa).

La motivacio del projecte es mes una estrategia de negoci que usaprogramari lliure que un itch worth scratching (que era la motivacioper involucrar-se en un projecte FOSS, segons Raymond)

Els projectes FOSS passen de projectes backoffice (sistemesoperatius, llenguatges de programacio, gestors de bases de dades,servidors web) a projectes frontoffice (suites d’ofimatica, ERPs...).




Perspectives del model de desenvolupament FOSS (3)

Les tasques d’analisi de requeriments i disseny guanyen una majorrellevancia.

El proces de desenvolupament perd algunes de les caracterıstiquesdel model basar.En particular, els desenvolupadors centrals son treballadors del’empresa, pagats per l’empresa.En qualsevol cas, els canals de comunicacio i dicussio oficials segueixen

essent les llistes de distribucio.

La contribucio externa s’orienta mes a la identificacio i correcciod’errors.




Relacions entre empreses i comunitats de programari lliure

Les empreses es poden beneficiar d’idees i productes que procedeixende les comunitats...

... Pero han d’introduir canvis al seu model de negoci.

Un possible canvi es passar de propietaris dels recursos acoordinadors.




LibreOffice: Un exemple de projecte FOSS amb lideratgeempresarial i obert a la comunitat

Hem vist que, actualment, molts dels projectes FOSS mes exitososprocedeixen d’iniciatives empresarials i aixo introdueix canvis a algunsaspectes del model de desenvolupament basar proposat per Raymond.Aquest es el cas de LibreOffice.

LibreOffice es una suite ofimatica de codi obert amb llicencia GNULGPLv3 que procedeix de la bifurcacio d’OpenOffice.

Fem una mica d’historia.....




LibreOffice: Historia i evolucio

1999: Sun Microsystems compra la suite ofimatica privativaStarOffice a Oracle i n’allibera el codi.D’aquesta manera Sun pot disposar i desenvolupar una suite ofimatica

alternativa a Microsoft Office utilitzable en les estacions de treball de Sun

i en plataformes Linux (i tambe a plataformes Windows).

2000: Sun allibera el codi de StarOffice i crea un nou projecte FOSSanomenat OpenOffice.Sun dona recursos (en particular, desenvolupadors) al projecte i l’obre ales contribucions de la comunitat.

Mante StarOffice com a projecte que afegeix moduls privatius als lliures

d’OpenOffice.

2001-2010: Diferents empreses, juntament amb la comunitat,s’afegeixen a l’esforc de desenvolupament d’OpenOffice: Novell,RedHat, RedFlag CH2000, IBM, Google.Ho fan perque consideren estrategic disposar d’una suite ofimaticaalternativa a Microsoft Office i de codi obert.

Aquestes empreses aporten desenvolupadors al projecte.

2010: Oracle adquireix Sun Microsystems.2010: Un grup de desenvolupadors involucrats en eldesenvolupament d’OpenOffice crea The Document Foundation.Ho fan perque temen que Oracle canviara la llicencia d’OpenOffice o

deixara de desenvolupar-la.




LibreOffice: Historia i evolucio (2)

2010: The Document Foundation (TDF) crea una bifurcacio (fork)de OpenOffice.Aixı neix LibreOffice, un nou projecte FOSS.

Les empreses Google, Novell, RedHat, Canonical i Intel col.laborenamb el projecte i formen part del Consell d’assessorament de TDF.Un dels objectius de TDF es obrir el nou projecte mes a la comunitati tenir una polıtica de governanca (presa de decisions sobre elprojecte) mes oberta.En particular, les decisions tecniques sobre l’evolucio del projecte esprenen en comunitat en base a consensos. Si no es pot arribar a unconsens, decideix un steering committee (comite directiu).El resultat ha estat una major involucracio de la comunitat en elprojecte i una mes gran rapidesa en el seu desenvolupament.

2011: Oracle deixa de desenvolupar OpenOffice i dona el projecte ala Apache Software Foundation que li canvia el nom a ApacheOpenOffice.




LibreOffice: Diferencies amb el model basar basic

Podem establir unes diferencies clares entre el model de desenvolupamentLibreOffice i el model basar basic proposat per Raymond:

El projecte LibreOffice (ni tampoc el projecte del qual procedeix:OpenOffice) no es van iniciar com a consequencia d’una necessitatd’un o varis desenvolupadors (scratch an itch), sino a partir d’unainiciativa empresarial.Aquesta iniciativa empresarial neix de que les empreses participantsdetecten una oportunitat de negoci o un forat al mercat o jutgen elprojecte com estrategic per als plans de l’empresa o per afeblir alsseus rivals).

La majoria dels seus desenvolupadors centrals no son voluntaris quedesenvolupen en les seves estones lliures sino que ho fan a carrec deles empreses que col.laboren i esponsoritzen el projecte.

A la presa de decisions s’hi involucra un comite amb representaciode les empreses participants.




Referencies

BCG2002 bcg The Boston Consulting Group: A Survey Provides New Insights intothe Hacker Culture:http://www.bcg.com/news media/

news media releases.jsp?id=935&yearpub=

Bou2005 bou A. Boulanger: Open-source versus proprietary software: Is one morereliable and secure than the other?. IBM SYSTEMS JOURNAL, VOL 44,NO 2, 2005.

Bro2002 bro K. Brown. Opening the Open Source Debate. White paper releasedby the Alexis de Tocqueville Institution. 2002. Available athttp://www.adti.net/ip/opensource.pdf

Fitz2005 fitz B. Fitzgerald: Has Open Source Software a Future?. In J. Feller etalt. (ed): Perspectives of free and open source software MIT press 2005

Fitz2006 fitz2 B. Fitzgerald: The Transformation of Open Source Software. In MISQuarterly, Vol.30, n. 3, 2006.

Fug2004 fug Alfonso Fuggetta: Open Source and Free Software: A New Model forThe Software Development Process? Upgrade Vol V, No. 5 Oct. 2004.

Glas2005 glas R.L.Glass: Standig in front of the open source steamroller. In J. Felleret alt. (ed): Perspectives of free and open source software MIT press 2005




Hall2003 hall T.J. Halloran, W. L. Scherlis: High Quality and Open SourceSoftware Practices. The 2nd Workshop on Open Source SoftwareEngineering. May-03. It was held at the 24th International Conference onSoftware Engineering (ICSE 2002).

Mich2005 mich M. Michlmayr et alt. Quality Practices and Problems in FreeSoftware Projects. First International Conference on Open SOftwareSystems. Genova. July-2005

MKL95 mill B. Miller, D. Koski, C. Lee, V. Maganty, R. Murthy, A. Natarajan,and J. Steidl, Fuzz Revisited: A Re-examination of the Reliability of UNIXUtilities and Services, Technical Report, Computer Science Department,University of Wisconsin (November 1995),ftp://ftp.cs.wisc.edu/paradyn/

technical papers/fuzz-revisited.pdf

Mock2005 mock A. Mockus et alt.: Twoe Case Studies of Open Source SoftwareDevelpoment: Apache and Mozilla. In J. Feller et alt. (ed): Perspectivesof free and open source software MIT press 2005




Ray2001 ray E. S. Raymond: The Cathedral and the Bazaar. In the book of thesame title. O’Reilly, January 2001.ISBN 0-596-00108-8 (paperbackedition). Accessible des dehttp://www.catb.org/esr/writings/homesteading/.

Ray2001b rayb E. S. Raymond: Homesteading the Noosphere. In E.S. Raymond:“The Cathedral and the Bazaar”. O’Reilly, January 2001. ISBN0-596-00108-8 (paperback edition). Accessible des dehttp://www.catb.org/esr/writings/homesteading/.

Ray2001c rayc E. S. Raymond: The Magic Cauldron. In E.S. Raymond: “TheCathedral and the Bazaar”. O’Reilly, January 2001. ISBN 0-596-00108-8(paperback edition). Accessible des dehttp://www.catb.org/esr/writings/homesteading/.

Ruso2005 ruso S. Rusovan et alt.: Open Software Development: Future or Fad? InJ. Feller et alt. (ed): Perspectives of free and open source software MITpress 2005

Scac2002 scac S. R. Schach et alt.: Maintenability of Linux Kernel. IEE Proc.Software. VOl 149, n. 1. Feb 2002


http://www.catb.org/esr/writings/homesteading/





Seny2004 seny A. Senyard, M. Michlmayr: How to Have a Successful Free SoftwareProject. Procds. of the 11th Asian-Pacific Software EngineeringConference (APSEC04). 2004

Whee2005 whee D. A. Wheeler: Why Open Source Software / Free Software(OSS/FS, FLOSS, or FOSS)? Look at the Numbers! Accessible athttp://www.dwheeler.com/oss_fs_why.html

Zhao2003 zhao L. Zhao, S. Elbaum: Quality assurance under the open sourcedevelopment model. The Journal of Systems and Software 66 (2003)65-75


http://www.dwheeler.com/oss_fs_why.html

4.4 Model de desenvolupament de projectes de Programari...

Documents

Transcript of 4.4 Model de desenvolupament de projectes de Programari...