En aquest estudi seguim el plantejament dels economistes i analitzem el programari en el context de les indústries de la xarxa. [1] El punt de vista que s'ha pres és el d'una empresa fabricant de productes de programari per als mercats competitius. Estem interessats principalment en el programari com un producte econòmic del sector del programari. A continuació, expliquem com els conceptes desenvolupats en la documentació de l'economia de la xarxa s'apliquen als mercats de productes de programari.

Per desgràcia, això no és tan senzill com sona, ja que és difícil jutjar quins conceptes econòmics son els més rellevants. El fet és que actualment hi ha una oferta excessiva de caracteritzacions econòmiques i classificacions dels mercats del programari que a més són molt exhaustives. [2] Per exemple, el llibre de text de Shy identifica quatre atributs principals com compatibilitat i estàndards; externalitats de la xarxa; costos d'immobilització i de substitució; i economies d'escala. [3] Gottinger fa un llistat amb setze "característiques estratègiques". [4] A més, hi ha arguments sensats i amb base empírica de, per exemple, Liebowitz i Margolis suggerint la funció general i el poder d'explicació del plantejament econòmic de la xarxa limitat al context del mercats del programari [5] Mentre ells reconeixen la rellevància de la teoria, les implicacions i la utilitat dels resultats no són sempre vàlids en totes les situacions de mercat.

Tenint en compte aquests defectes, avancem amb la teoria.

Programari com un bé informatiu. El punt inicial per a l'anàlisi és la teoria econòmica de la informació. El supòsit és que el programari es pot descriure com un bé que inicialment és costós de produir, però que després és barat de reproduir. Això significa que la producció de programari implica el que els economistes anomenen l'economia d'escala. Podem il·lustrar els costos de producció i reproducció dels productes de programari amb la següent xifra:

Figura 8. Funcions de cost diferents en la producció de béns d'informació. [6]

La xifra p_O indica els costos de producció inicials i els p_m costos de reproducció de cada còpia addicional. La funció de costos total és un conjunt de les altres dues i la mitjana dels costos és igual als costos totals dividits entre el número de còpies. La xifra ajuda a explicar que per a cada preu indicat a dalt p_m hi ha un cert nivell de vendes (q) després del qual cada còpia reproduïda implica un benefici. Ja que el preu del producte no depèn de p_O, podem apuntar que els costos de desenvolupament no són una bona base per a la cotització del producte de programari.

Encara que el model sigui simple i s'expliqui en molts llibres de text econòmics, té severes limitacions d'aplicabilitat en la indústria dels productes de programari. El model no té en compte els costos de venda i manteniment del producte, com per exemple, els costos de màrqueting, manteniment i millora no estan inclosos en els "costos marginals", que se suposen que són constants i mínims en comparació amb els costos de producció. El model de programari com un bé d'informació es pot aplicar, per exemple, al programari d'entreteniment i a altres aplicacions de l'usuari final amb un esforç mínim de vendes i suport per part del productor.

Programari com un bé capital. Els béns capitals són costosos de produir i el distribuïdor del producte treu un benefici de la instal·lació, manteniment i suport. La teoria del bé capital s'ha aplicat, per exemple, a projectes de construcció.

Però els productes de programari més grans també es poden comparar, en molts aspectes, amb els béns capitals. Especialment els primers productes de programari eren molt costosos de produir, i un cop el sistema estava en alça s'esperava que anés adquirint experiència al llarg dels anys venidors. Per exemple, avui en dia el programari de la gestió global de l'empresa (ERP) es pot descriure millor com un bé capital.

Es podria pensar que els efectes econòmics de fer còpies depenen de si l'obra s'hauria de contemplar com un producte de consum o un producte capital. És freqüent reivindicar, per exemple, que els costos socials de copiar béns de consum són menys perjudicials ja que la societat consisteix majoritàriament de consumidors individuals. També és costós controlar el comportament del consumidor. A més,es pot defensar que, en els béns capitals, la difusió de tecnologia augmenta la innovació i també el benestar social. Especialment quan els productes de programari s'utilitzin com a mitjans de producció, haurien de tenir probablement uns drets d'ús més flexibles que els adoptats en la llei del copyright. Per altra banda, sempre és possible reconvenir que copiar disminueix la creació d'obres noves sempre i quan siguin consumidors de béns capitals. [7]

El programari com un bé públic. Independentment de la teoria de la informació i dels béns capitals, el programari com un producte també pot ser contemplat com un bé públic. Per establir una distinció entre bé públic i bé privathi ha dos subconceptes que requereixen ser definits:

• No excloïble. Pot haver-hi un número il·limitat d'usuaris simultanis d'un bé. L'un no pot restringir als altres l'ús del bé. La quantitat del bé no pot ser controlada, és igual per a tothom. Exemples de béns no excloïbles són els espais públics i el programari de codi obert. [8]

• No rivals Els béns no consumeixen. L'ús d'un bé per part d'una persona no disminueix la seva capacitat d'ús pels altres. No es pot controlar la qualitat del bé. És igual per a tothom. Els exemples típics de béns no rivals són l'aire i el programari privatiu.

Els béns públics són tant no rivals com no excloïbles. Així, el seu valor no disminueix sinó que augmenta amb l'ús. [9] Els béns privats, en comparació, són tant rivals com excloïbles. Això potser pot il·lustrar-se millor a la taula següent:

Taula 5. Els béns públics, com el programari lliure, són tant no excloïbles com no rivals.

La teoria dels bens públics sembla atractiva en el context del programari de codi obert. Els drets de la propietat intel·lectual, per la seva part, privatitzen la naturalesa del bé públic del programari en oferir capacitat d'exclusió. A més, el programari privatiu és no rival: copiar programari en contra dels seus termes de llicència (pirateria) no disminueix el seu valor per als usuaris (però alguns productes o serveis complementaris com la garantia i el suport poden no estar disponibles).

Finalment, el programari pot caracteritzar-se com un producte del sistema. Sabem que el programari s'utilitza en els sistemes informàtics que consten de diferents components de maquinari i programari. El programari mai no s'utilitza aïlladament, sinó com una part del sistema. El sistema pot constar de components separats de maquinari i de programari i perquè el sistema funcioni, els components han de treballar, d'alguna manera, conjuntament. És a dir, han de ser compatibles els uns amb els altres. En aquest estudi, definim els termes compatibilitat, interoperabilitat i estàndard de la següent manera:

• Un component és compatible amb un altre si poden intercomunicar-se sense que es modifiquin. A més, la compatibilitat pot ser en un o en dos sentits. Si els dos components poden comunicar-se l'un amb l'altre (compatibilitat en dos sentits), es diu que són interoperables. Per exemple, el programari nou pot ser compatible amb el programari antic (compatible "cap enrere") però no viceversa. En aquest cas, el programari nou i el programari antic no són interoperables.

• Un estàndard és un conjunt de regles ex ante dirigit a la compatibilitat entre components. Els components interoperables segueixen el mateix estàndard. A més, els estàndards poden ser oberts o tancats. En principi, qualsevol persona és lliure d'escriure una implementació pròpia per a un estàndard obert. [10] Òbviament, la documentació d'un estàndard obert ha de ser oberta i les successions de proves han d'estar disponibles obertament. Per exemple, molts llenguatges de programació i de formatació són clars exemples d'estàndards oberts. L'estàndard tancat és el complement d'un estàndard obert.

Més avall hi ha una il·lustració del plantejament de components al programari:

Figura 9. Plantejament de components als productes de programari.

Els dos fabricants A i B produeixen dos components, aquí anomenats 1 i 2. Si només són possibles les combinacions A₁A₂ i B₁B₂, llavors els components són incompatibles. I si A₁B₂o B₁A₂ és possible, llavors són compatibles en un sentit (o, per exemple, cap enrere). Si totes les combinacions són possibles, els components són compatibles en dos sentits i perfectament interoperables.

La compatibilitat pot ser gradual. Una compatibilitat perfecta significaria que no hi ha cap cost ni reducció del rendiment entre les comunicacions entre dos components. A la pràctica, per exemple, els sistemes operatius Unix són més o menys compatibles els uns amb els altres. Mentre el nucli del sistema Unix està estandarditzat (estàndard POSIX obert), cada implementació segueix l'estàndard només parcialment o afegeix característiques pròpies incompatibles.

Si els components pertanyen a diferents empreses, pot produir-se una fragmentació. Si hi ha massa propietaris amb drets exclusius per a diferents components del sistema, pot produir-se una subutilització perquè els costos per negociar els drets necessaris per a la totalitat del sistema poden ser massa elevats. [11]

Tot sovint es pensa que el programari de codi obert ha de ser compatible per la seva pròpia naturalesa (codi font disponible i modificable) i ha de seguir els estàndards oberts. No obstant, aquest no és sempre el cas. És possible, tal i com s'explicarà posteriorment, que el codi obert segueixi un estàndard tancat. [12] A més, algunes llicències de fonts obertes poden ser incompatibles les unes amb les altres i fins i tot poden sorgir problemes de fragmentació com amb qualsevol component privatiu. [13]

L'enfocament del producte de sistema es pot utilitzar per explicar perquè és típic en la indústria del programari que només uns quants productes dominin el mercat en un moment determinat. En resum, potser no té gaire sentit per als usuaris canviar d'una trajectòria de producte a un altra perquè es podria perdre la compatibilitat del sistema o els beneficis del la xarxa existent de l'usuari. Això porta a definir els costos de substitució i els costos d'immobilització.

• Els costos de substitució són els costos de la migració entre components incompatibles. A més, podem identificar costos d'imputació en un o en dos sentits. Per exemple, si es necessita aprendre com funciona un component abans d'utilitzar-lo, no hi haurà costos de substitució per retornar al component antic (un de ja conegut). En canvi, qualsevol cost a la transacció actual de substitució significa que també hi haurà costos a la substitució de retrocés. [14]

• Recentment, els costos de substitució s'han analitzat com una eina per crear situacions d'immobilització. Si els costos de substitució són suficientment elevats com per afectar l'opció de compra de l'usuari a favor del producte que utilitza actualment, llavors diem que existeix una situació d'immobilització. [15] La immobilització pot ser, per exemple, contractual, referent a una adquisició duradora o basat en programes de lleialtat. [16] Tant la immobilització del maquinari com del programari han estat comuns. En principi, els efectes de la immobilització del maquinari poden ser pal·liats amb l'arquitectura oberta dels sistemes i la immobilització del programari amb el programari de codi obert.

Un argument comú per a les migracions de codi obert és que no implica immobilització per als desenvolupadors particulars. En teoria, és ben possible canviar de desenvolupadors si el codi font està disponible i es pot modificar lliurement. No obstant, el desenvolupament d'un codi font particular pot requerir normalment el coneixement tàcit dels desenvolupadors originals, cosa que pot ser molt costosa d'adquirir, especialment si el producte és molt complex. [17] A més, tal i com s'indicarà més endavant, els termes de llicència poden incloure encara certes limitacions, que posteriorment tenen com a resultat una situació d' immobilització de facto.

Finalment, els efectes positius de la xarxa també caracteritzen els mercats del programari: [18]

• Si el valor del bé per a l'usuari depèn del número dels altres usuaris, es diu que el bé té efectes de xarxa. [19] En els mercats del programari, els efectes de xarxa normalment són positius: una gran base d'usuaris augmenta el valor del producte per a un individu.

• Els efectes de xarxa poden ser tant directes com indirectes. Els propis efectes del producte es diuen que són directes i els efectes a altres productes mitjançant la compatibilitat o no compatibilitat es diuen que són indirectes. [20]

• Els efectes de xarxa no estan restringits a béns materials. S'ha sostingut que, per exemple, no només es comparteix el programari sinó també la capacitat dels desenvolupadors i es gaudeix dels beneficis de la xarxa en expansió. [21]

A la pràctica, potser no sempre és apropiat parlar d'externalitats de la xarxa, ja que els productors de programari prefereixen interioritzar el resultat dels efectes de xarxa mitjançant, per exemple, copyright privatiu o la llicència de patents. No obstant, en el cas del codi obert, els desenvolupadors de programari en molts casos no tenen poder per internalitzar els efectes amb aquests mitjans directes. Així, es pot argumentar que, per exemple, la còpia i ús del nucli del sistema operatiu GNU/Linux - el copyright del qual està permanentment sota una llicència de codi obert - causa externalitats de la xarxa a les companyies que competeixen en els mercats del programari de sistemes operatius. [22]

.^1. La investigació teòrica rellevant ens porta a Katz i Shapiro (1985) que estudiaven la natura dels efectes de la xarxa i del poder del mercat, especialment des de la perspectiva dels fabricants, i a Teece (1986) que es plantejava com podien també generar beneficis els fabricants complementaris. Es presenta en l'exemple una visió general del plantejament econòmic de la xarxa tal i com s'aplica en la indústria del programari. Shapiro i Varian (1999), Shy (2001) i Messerschmitt i Szyperski (2003).

.^2. Westrap (2003), pàg. 5.

.^3. Shy (2001).

.^4. Gottinger (2003), pàg. xv-xvi.

.^5. Liebowitz i Margolis (2001), Liebowitz (2002).

.^6. Shy (2001), p. 54.

.^7. Watt (2000),pàg. 25-26.

.^8. Els béns no excloïbles tot sovint s'anomenen comuns. Un ús en excés i egoista dels béns comuns té com a resultat la tragèdia dels comuns, un terme encunyat per Hardin (1968).

.^9. Alguns autors anomenen aquest tret dels béns públics com la comèdia dels comuns. Vegeu e.g. Rose (1986).

.^10. Els estàndards oberts no s'han de confondre, en aquest aspecte, amb els principis del codi obert. Els estàndards oberts tradicionalment poden incloure els anomenats termes de llicència de patents raonables i no discriminatòries (RAND), que són contràries als principis del codi obert. Els defensors del codi obert reclamen que els estàndards no haurien de tenir cànons per poder ser oberts mentre la majoria dels grups d'estàndards de la indústria permeten cànons de patents. Vegeu e.g. Rosen (2004), pàg. 304-311, W3C Política de patents (2004) com un exemple de la definició d'estàndard lliure de cànons recentment adoptada i Kane (2002)

.^11. D'això se n'ha dit problema dels anticomuns, un terme encunyat per Heller (1998).

.^12. Secció 5.5.2

.^13. Secció 5.3.4

.^14. Farrell i Klemper (2001).

.^15. Vegeu e.g. Basen i Farrell (1994), Arthur (1989) i Katz i Shapiro (1985).

.^16. Shapiro i Varian (1999), pàg. 117.

.^17. Per exemple, els projectes de Mozilla i de l'OpenOffice van afrontar aquest tipus de problemes després de tenir codi obert. Es va trigar molt a trobar nous desenvolupadors per un projecte tan gran i complex.

.^18. Von Westrap (2003), pàg. 100- 103, fa una llista amb sis estudis empírics on l'existència dels efectes de la xarxa han estat estudiats i provats en el sector del programari, del maquinari i de les telecomunicacions. Ell també identifica nombrosos models teòrics per a l'anàlisi detallada dels efectes de la xarxa.

.^19. Un altre terme és is "bandwagon effects", un terme proposat per Weblen i analitzat per primer cop per Leibstein (1950).

.^20. Vegeu e.g. Katz i Shapiro (1985), Economides (1996).

.^21. Vegeu Garzarelli (2003) que fa referència a la teoria econòmica dels clubs professionals.

.^22. Vegeu el primer exemple de Rahnasto (2003), pàg. 1.