Jedna z wie­lu burz­li­wych dys­ku­sji na temat open sour­ce w biz­ne­sie tak zosta­ła prze­ze mnie pod­su­mo­wa­na na pew­nym forum:

Z dys­ku­sji wyła­nia­ją się dla mnie takie wnio­ski: otwar­tość opro­gra­mo­wa­nia (kodu) czy­ni go bar­dziej wia­ry­god­nym, otwar­tość kodu skła­nia jego twór­ców do pod­no­sze­nie jego jako­ści (wstyd zabra­nia par­ta­ni­ny ;)), to czy jest dar­mo­wy czy nie, zale­ży wyłącz­nie od mode­lu biz­ne­so­we­go sprze­da­ży: twór­ca sam usta­la czy zara­bia na licen­cjo­no­wa­niu kodu czy na swo­jej wie­dzy i pra­cy, ​„zamy­ka­nie kodu”, to kwe­stia subiek­tyw­ne­go uzna­nia twór­cy kodu, czy sta­no­wi on (treść) chro­nio­ne know-how (jego prze­wa­gę kon­ku­ren­cyj­ną) czy nie… ale war­to dodać, że prze­wa­ga sto­ją­ca na takiej tajem­ni­cy ma jed­nak gli­nia­ne nogi (jak każ­da prze­wa­ga bazu­ją­ca w 100% na tajem­ni­cy). (dys­ku­sja Open Source w biz­ne­sie | LinkedIn).

To pod­su­mo­wa­nie to w zasa­dzie cała pla­no­wa­na treść tego wpi­su ale…

Kilka uwag dodatkowych

Wiele się mówi o tym, że open sour­ce nie zawsze jest darmowe:

Otwarte opro­gra­mo­wa­nie (ang. open sour­ce move­ment, dosł. ruch otwar­tych źró­deł) ? odłam ruchu wol­ne­go opro­gra­mo­wa­nia (ang. free softwa­re), któ­ry pro­po­nu­je nazwę open sour­ce softwa­re jako alter­na­tyw­ną dla free softwa­re, głów­nie z przy­czyn prak­tycz­nych, a nie filozoficznych.

Istnieje wie­le mode­li biz­ne­so­wych dla pro­du­cen­tów otwar­te­go opro­gra­mo­wa­nia. Obok dar­mo­we­go udo­stęp­nia­nia może ono być sprze­da­wa­ne i wyko­rzy­sty­wa­ne w spo­sób komer­cyj­ny. Sposób osią­ga­nia zysków moż­na tak­że ogra­ni­czyć do sprze­da­ży dodat­ko­wych usług, takich jak szko­le­nia z obsłu­gi, wspar­cie klien­ta czy dostęp do dodat­ko­wych roz­sze­rzeń, wty­czek, dodat­ków i modu­łów. Możliwe jest też wyko­rzy­sta­nie bez­płat­nej wer­sji open sour­ce, jako spo­sób na zachę­ce­nie do kup­na bar­dziej roz­bu­do­wa­nej wer­sji dostar­cza­nej na licen­cji komercyjnej.

Jak widać otwar­te nie zawsze zna­czy dar­mo­we. Sama otwar­tość to jedy­nie ujaw­nie­nie kodu, nie raz (ale nie zawsze!) tak­że zezwo­le­nie (licen­cja) na jego uży­cie do two­rze­nia dzieł zależ­nych (samo­dziel­ne­go roz­wi­ja­nia), ale otwar­tość nie zawsze też ozna­cza ​„jest Twoje”. Czym innym jest wgląd w treść a czym innym pra­wo korzy­sta­nia i mody­fi­ka­cji (war­to czy­tać licen­cje i sza­no­wać pra­wa autorskie).

Wiele się też mówi o tym, by otwar­te opro­gra­mo­wa­nie było uży­wa­ne w Administracji Państwowej bo jest ​„dar­mo­we” i jaw­ne. Ten mit nie­ste­ty roz­wie­wa­ją prze­tar­gi. Jeżeli pomi­nąć te ogło­szo­ne nie­zgod­nie z pra­wem (pre­fe­ren­cje w źle sfor­mu­ło­wa­nych Opisach Przedmiotu Zamówienia) to i tak jak widać nie wygry­wa­ją maso­wo pro­duk­ty z gru­py open sour­ce mimo, że więk­szość prze­tar­gów jako jedy­ne kry­te­rium oce­ny ma cenę.

W 2010 roku dwóch zna­nych eks­per­tów zaj­mu­ją­cych się eko­no­mią inno­wa­cji, Josh Lerner i Mark Schankerman, opu­bli­ko­wa­ło wyni­ki swo­ich sze­ro­ko zakro­jo­nych badań empi­rycz­nych doty­czą­cych otwar­te­go oprogramowania[3]. Wynika z nich, że wbrew ste­reo­ty­pom, w chwi­li obec­nej więk­szość opro­gra­mo­wa­nia open-sour­ce powsta­je w komer­cyj­nych fir­mach ofe­ru­ją­cych rów­nież opro­gra­mo­wa­nie zamknię­te. Wg Lernera i Schankermana, open-sour­ce i clo­sed-sour­ce nie są wobec sie­bie w opo­zy­cji, a raczej powin­no się je postrze­gać jako uzu­peł­nia­ją­ce się nawza­jem. Zwracają oni przy tym uwa­gę, że wie­lu użyt­kow­ni­ków jed­no­cze­śnie korzy­sta z pro­gra­mów zarów­no zamknię­tych (np. sys­te­mu ope­ra­cyj­ne­go Microsoft Windows), jak i otwar­tych (np. prze­glą­dar­ki inter­ne­to­wej Firefox). Jednym z głów­nych wnio­sków auto­rów jest stwier­dze­nie, że rzą­dy nie powin­ny wybiór­czo wspie­rać (zarów­no w ramach poli­ty­ki gospo­dar­czej, jak i w roli nabyw­cy infra­struk­tu­ry infor­ma­cyj­nej) prze­my­słu opro­gra­mo­wa­nia zamknię­te­go bądź otwar­te­go, a raczej w zależ­no­ści od kon­kret­nych warun­ków i jeden, i drugi.

(cyta­ty za Otwarte opro­gra­mo­wa­nie ? Wikipedia, wol­na ency­klo­pe­dia).

Tak więc moim zda­niem przy wybo­rze opro­gra­mo­wa­nia war­to się kie­ro­wać pla­nem i cyklem życia pro­duk­tu, kry­te­ria­mi eko­no­micz­ny­mi w fir­mie, a nie tym czy dane opro­gra­mo­wa­nie jest czy nie jest otwar­te. (w arty­ku­le celo­wo posłu­ży­łem się wyłącz­nie cyta­ta­mi z WIKI jako wol­nej encyklopedii).