DEFR

Login et recherche



Sponsors /ch/open

leanux.ch AG - /ch/open-Sponsor
SIK Checkliste für Beschaffung von Open Source Software

SIK Check­liste für Beschaf­fung von Open Source Software

von SIK Arbeits­gruppe OSS | 18.08.2015

Die vor­lie­gende Check­liste ist ein Hilfs­in­stru­ment für Beschaf­fungs­stel­len, wel­che die rechts­kon­forme Beschaf­fung von Open Source Soft­ware sicher­stel­len und Ange­bote von Open Source Dienst­leis­tern ermög­li­chen wol­len. Die Check­liste ent­hält Fra­gen mit ent­spre­chen­den Erläu­te­run­gen, die bei der Vor­be­rei­tung einer ICT-​Ausschreibung berück­sich­tigt wer­den können.

Down­loads

Ger­man PDF: “SIK Check­liste für Beschaf­fung von Open Source Software”

French PDF: “Liste de con­trôle de la CSI pour l’acquisition de logi­ciels open source”

English PDF: “SIK check­list for the pro­cu­re­ment of open source software”

1. Voranalyse/​Konzeption

Ist genü­gend Ver­ständ­nis über das Open Source Ent­wick­lungs­mo­dell vor­han­den?

Anders als bei pro­prie­tä­rer Soft­ware wer­den bei Open Source Soft­ware nicht Lizen­zen beschafft, son­dern Dienst­leis­tun­gen und/​oder Sub­skrip­tio­nen für bestimmte Open Source Lösun­gen. Dem­ent­spre­chend sind auch die Geschäfts­mo­delle von Open Source Her­stel­lern und Dienst­leis­tern aus­ge­legt, dass sie kon­krete Leis­tun­gen wie Sup­port (Ser­vice Level Agree­ments), War­tung, Gewährleistung/​Garantien, Anpas­sun­gen, Inte­gra­tion, Betrieb, Schu­lung etc. für die Open Source Lösun­gen anbie­ten. Die­sem Umstand sollte bereits bei der Vor­be­rei­tung der Aus­schrei­bung Rech­nung getra­gen werden.

Sind beste­hende Open Source Lösun­gen geprüft wor­den?

Der Ein­satz von Open Source Soft­ware ohne Leis­tun­gen einer Firma ist aus beschaf­fungs­recht­li­cher Sicht nicht rele­vant und kann somit ohne öffent­li­che Aus­schrei­bung statt­fin­den. In Ver­zeich­nis­sen wie dem OSS Direc­tory oder alter­na­ti­veTo kann recher­chiert wer­den, wel­che Open Source Lösun­gen für wel­chen Anwen­dungs­be­reich (CMS, DMS, App­li­ca­tion Ser­ver, Fach­ap­pli­ka­tion etc.) ver­füg­bar ist.

Wel­cher Funk­ti­ons­um­fang wird tat­säch­lich benö­tigt?

Es besteht eine Ten­denz zur Beschaf­fung von einem zu hohen Leis­tungs­um­fang, der in der Rea­li­tät nicht benö­tigt wird. Bei­spiels­weise könnte anstelle von einer bestimm­ten pro­prie­tä­ren Daten­bank auch MariaDB oder Post­greSQL ein­ge­setzt wer­den. Wird eine Software-​Lösung mit zu hohen Leis­tun­gen beschafft, wer­den Kos­ten von Funk­tio­na­li­tä­ten bezahlt, die gar nie benö­tigt werden.

2. Kri­te­rien die ver­hin­dern, dass Open Source aus­ge­schlos­sen wird

Sind die Beschaf­fungs­un­ter­la­gen funk­tio­nal ver­fasst ohne Vor­gabe von pro­prie­tä­ren Pro­duk­ten?

Die Vor­gabe von bestimm­ten pro­prie­tä­ren Pro­duk­ten (z.B. Micro­soft Sha­re­point), Platt­for­men (SAP), Internet-​Browsern oder Schnitt­stel­len von bestimm­ten Her­stel­lern kann dazu füh­ren, dass Anbie­ter von Open Source Lösun­gen von vorn­her­ein aus­ge­schlos­sen sind. Damit wer­den beste­hende Abhän­gig­kei­ten ver­stärkt, Mono­pol­stel­lun­gen geför­dert und letzt­lich Wett­be­werb und Inno­va­tion ein­ge­schränkt und damit Infor­ma­tik­kos­ten lang­fris­tig erhöht. Umge­kehrt kann es gute Gründe geben, eine Aus­schrei­bung auf eine bestimmte öffent­lich ver­füg­bare Open Source Lösung ein­zu­gren­zen. Gemäss Defi­ni­tion kön­nen belie­bige Her­stel­ler für sol­che Open Source Sys­teme ihre Dienst­leis­tun­gen anbie­ten was den Wett­be­werb nicht behin­dert, son­dern im Gegen­teil för­dert. Wich­tig ist, diese Ein­gren­zung auf eine vor­ge­ge­bene Open Source Lösung stich­hal­tig begrün­den zu können.

Besteht ein Hin­weis, dass auch Open Source Soft­ware ange­bo­ten wer­den kann?

Die AGBs von Bund und SIK behin­dern die Beschaf­fung von Open Source nicht. Damit dies auch allen Open Source Anbie­tern klar ist, ist ein Hin­weis in den Aus­schrei­bungs­un­ter­la­gen emp­foh­len, dass auch Open Source Lösun­gen ange­bo­ten wer­den können.

Sind Sub­un­ter­neh­mer und Bie­ter­ge­mein­schaf­ten zuge­las­sen?

Viele der guten Open Source Ent­wick­ler sind selb­stän­dig oder in klei­nen Fir­men tätig. Des­halb soll­ten Aus­schrei­bun­gen ermög­li­chen, dass sich Open Source Anbie­ter zusam­men­schlies­sen und als Sub­un­ter­neh­mer eines grös­se­ren Anbie­ters (der z.B. als Gene­ral­un­ter­neh­mer) oder als Kon­sor­tium gemein­sam anbie­ten. Die ein­heit­li­che Koor­di­na­tion kann bspw. über einen Sin­gle Point of Con­tact defi­niert wer­den, der bei einem der Anbie­ter liegt.

Sind Fir­men­grösse und Refe­ren­zen nicht unnö­tig hoch vor­ge­ge­ben?

Open Source Anbie­ter sind ten­den­zi­ell klei­ner als Her­stel­ler von pro­prie­tä­rer Soft­ware. Auch sind Open Source Lösun­gen aus Grün­den der Abhän­gig­kei­ten zu pro­prie­tä­ren Pro­duk­ten oft­mals noch wenig ver­brei­tet. Um Open Source Anbie­ter nicht von indi­rekt aus­zu­schlies­sen soll­ten des­halb bei den Eig­nungs­kri­te­rien nicht unnö­tig hohe Anfor­de­run­gen an Fir­men­grösse, Mit­ar­bei­ter­zahl, Refe­ren­zen, instal­lierte Ver­sio­nen etc. gestellt wer­den. Letzt­lich ist auch bei gros­sen Unter­neh­men immer nur ein klei­ner Kreis von Mit­ar­bei­ten­den für ein Pro­jekt zustän­dig. Zudem ist bei Gross­un­ter­neh­men die Mit­ar­bei­ter­fluk­tua­tion meist höher und die Iden­ti­fi­ka­tion mit der Arbeit und den Kun­den oft­mals nied­ri­ger als bei klei­ne­ren Fir­men. Diese Gründe spre­chen gene­rell für klei­nere Anbie­ter, wes­halb es Sinn macht, diese nicht auszuschliessen.

3. Kri­te­rien, wel­che die Eigen­schaf­ten von Open Source berücksichtigen

Wird die Lie­fe­rung der Soft­ware unter einer Open Source Lizenz in der tech­ni­schen Spe­zi­fi­ka­tion (TS) vor­ge­ge­ben bzw. wird Open Source als Zuschlags­kri­te­rium (ZK) bemes­sen?

Open Source Soft­ware gewährt durch ihre Lizenz­be­stim­mun­gen wesent­li­che Nut­zungs– und Ent­wick­lungs­mög­lich­kei­ten, die bei pro­prie­tä­rer Soft­ware aus­ge­schlos­sen sind. Einer­seits dür­fen Open Source Lösun­gen unein­ge­schränkt und kos­ten­los ver­wen­det und ver­viel­fäl­tigt wer­den. Der Ein­satz von Open Source Soft­ware ska­liert recht­lich gese­hen belie­big ohne finan­zi­elle Fol­gen, unab­hän­gig davon, wie viele Arbeits­plätze oder Ser­ver die Soft­ware nut­zen. Ande­rer­seits erlau­ben Open Source Lizen­zen den voll­stän­di­gen Zugang zum Quell­code und das Recht die­sen zu ver­än­dern. Damit erhält der Nut­zer die Mög­lich­keit sel­ber oder im Auf­trag an Dritte die Soft­ware zu audi­tie­ren, kor­ri­gie­ren, anzu­pas­sen und wei­ter­zu­ent­wi­ckeln. Aus die­sen Grün­den macht es Sinn und ist erlaubt, die posi­ti­ven Eigen­schaf­ten von Open Source Soft­ware als ZK zu bewer­ten oder Nut­zungs­ei­gen­schaf­ten unter einer Open Source Lizenz gar als TS vorzuschreiben.

Wer­den „Open Source Kom­pe­ten­zen“ des Anbie­ters als Eig­nungs­kri­te­rium vor­ge­ge­ben?

Wenn ein Leis­tungs­be­zü­ger bewusst eine Open Source Lösung beschaf­fen will oder bereits eine sol­che besitzt und Dienst­leis­tun­gen dazu sucht, kann es Sinn machen, dass „Open Source Kom­pe­ten­zen“ des Anbie­ters als Eig­nungs­kri­te­rium vor­ge­ge­ben – oder im Fall eines selek­ti­ven Ver­fah­rens bewer­tet – werden.

Besteht Zugang zum voll­stän­di­gen Quell­code der offe­rier­ten Software-​Lösung?

Es ist einer­seits aus Sicher­heits– und Daten­schutz­sicht wich­tig, dass die Anbie­ter den voll­stän­di­gen Quell­code für Audit-​Möglichkeiten dem Leis­tungs­be­zü­ger zur Ansicht zur Ver­fü­gung stel­len. Dadurch besteht die Mög­lich­keit, dass Software-​Entwickler der Quell­code nach mög­li­chen Back­doors zur NSA etc. unter­su­chen kön­nen. Ande­rer­seits macht es auch aus Software-​Qualitätsgründen Sinn, Zugang zum Quell­code sicher­zu­stel­len um bspw. die Code-​Qualität oder die Doku­men­ta­tion des Quell­codes prü­fen zu kön­nen. Bei Open Source Soft­ware ist der voll­stän­dige Zugang zum Quell­code per Defi­ni­tion gewähr­leis­tet, bei pro­prie­tä­rer Soft­ware nor­ma­ler­weise nicht oder nicht vollständig.

Wer­den in der Aus­schrei­bung die Kos­ten der IT-​Lösung über ihren gesam­ten Lebens­zy­klus bemes­sen? (Total Cost of Ownership – TCO)

Oft­mals ist Open Source Soft­ware teu­rer in der Ein­füh­rung als das Upgrade der bis­he­ri­gen pro­prie­tä­ren Soft­ware, da tech­ni­sche und per­so­nelle Ver­än­de­run­gen (Migra­tion, Anpas­sun­gen, Umschu­lun­gen etc.) nötig sind. Wird jedoch der gesamte Lebens­zy­klus einer IT-​Lösung betrach­tet, sind Betriebs– und War­tungs­kos­ten wesent­lich höher als Beschaf­fungs– und Ein­füh­rungs­kos­ten. Die Betriebs­dauer von IT-​Lösungen ist durch­schnitt­lich rund 3x höher ist als die Pro­jekt­dauer. Da bei Open Source Soft­ware keine wie­der­keh­ren­den Lizenz­kos­ten anfal­len, der Anbie­ter rela­tiv rasch gewech­selt wer­den kann und dank offe­nen Stan­dards kaum Exit-​Kosten ent­ste­hen, sind Open Source basierte Lösun­gen lang­fris­tig meis­tens güns­ti­ger. In der Aus­schrei­bung sollte des­halb immer die gesamte Lebens­dauer einer IT-​Lösung berück­sich­tigt werden.

Wird das Risiko eines Kon­kur­ses bei pro­prie­tä­ren Lösun­gen bemes­sen?

Geht der Her­stel­ler von pro­prie­tä­rer Soft­ware Kon­kurs, fal­len die Rechte am Quell­code in die Kon­kurs­masse. Die Nut­zer der pro­prie­tä­ren Soft­ware sind einer unge­wis­sen Zukunft aus­ge­setzt. Bei Open Source Soft­ware kann ein ande­rer Dienst­leis­ter mit der Wei­ter­ent­wick­lung des Sys­tems beauf­tragt wer­den, da der Leis­tungs­be­zü­ger umfas­sende Nut­zungs­rechte besitzt.

Wer­den auch Refe­ren­z­in­stal­la­tio­nen von Open Source Lösun­gen berück­sich­tigt, die nicht vom Anbie­ter sel­ber rea­li­siert wur­den?

Es kann als Zuschlags­kri­te­rium vor­ge­ge­ben wer­den aus­zu­wei­sen, wie viele Instan­zen der ange­bo­te­nen Open Source Lösun­gen bereits öffent­lich bekannt im Ein­satz ste­hen. Dies bemisst zwar nicht die Kom­pe­tenz des Anbie­ters, aber gibt den­noch einen Ver­brei­tungs­grad der ange­bo­te­nen Open Source Lösung an, denn diese könnte auch intern rea­li­siert wor­den sein.

Wird die Akti­vi­tät einer Open Source Com­mu­nity berück­sich­tigt?

Eine Open Source Lösung kann eine mehr oder weni­ger aktive Com­mu­nity von Ent­wick­lern und Dienst­leis­tern haben. Für die nach­hal­tige Wei­ter­ent­wick­lung eines Open Source Pro­jekts ist es des­halb ent­schei­dend, dass eine mög­lichst aktive und hete­ro­gene Com­mu­nity vor­han­den ist. Die Infor­ma­ti­ons­platt­form Open HUB (www​.open​hub​.net) gibt die Akti­vi­tät von rund 700000 Open Source Pro­jek­ten tages­ak­tu­ell und sehr fein­gra­nu­lar bekannt.

Wird die Ver­füg­bar­keit von Dienst­leis­tern einer Open Source Lösung geprüft?

Für die lang­fris­tige Wei­ter­ent­wick­lung und einen mög­li­chen Anbie­ter­wech­sel ist eine breite Dienstleister-​Community wich­tig. Es sollte des­halb als Zuschlags­kri­te­rium berück­sich­tigt wer­den, wie viele kom­mer­zi­elle Dienst­leis­ter für eine bestimmte Open Source Lösung vor­han­den sind.

Wei­tere Informationen

OSS Arbeits­gruppe der Schwei­ze­ri­schen Infor­ma­tik­kon­fe­renz SIK
Erich Hofer, Lei­ter Infor­ma­tik Bau-​, Ver­kehrs– und Ener­gie­di­rek­tion des Kan­tons Bern (BVE), 031 633 32 12, erich.hofer(at)bve.be.ch

Open Source För­der­ver­ein Swiss Open Sys­tems User Group /​ch/​open
Dr. Mat­thias Gün­ter, Prä­si­dent, 079 457 13 22, matthias.guenter(at)ch-open.ch, www​.ch​-open​.ch

For­schungs­stelle Digi­tale Nach­hal­tig­keit der Uni­ver­si­tät Bern
Dr. Mat­thias Stür­mer, Lei­ter der For­schungs­stelle, 031 631 38 09, matthias.stuermer(at)iwi.unibe.ch, www​.digi​tale​-nach​hal​tig​keit​.unibe​.ch

OSS Direc­tory
Ver­zeich­nis von Open Source Anbie­tern, Nut­zern, Pro­duk­ten und Refe­ren­zen: www​.oss​di​rec​tory​.ch


Télé­char­ger (PDF 62.2 KB)
Télé­char­ger (PDF 61.9 KB)
Télé­char­ger (PDF 60.8 KB)


Twitter Feed







Liens

Über unsNewsletterContactConditions d'utilisationCH Open Initiativen