2.1 Kann der öffentliche Sektor mit Open-Source-Software Einsparungen erzielen? (Manuel Rojas und Tobias Polzer)

Kurzfassung: Open Source Software (OSS) im öffentlichen Sektor wird nachgesagt, eine kostengünstige Alternative zu proprietären Lö­sun­gen darzustellen. Ein Vergleich von OSS und proprietären Soft­ware­projekten sollte möglichst quantitative und qualitative Aspekte be­rücksichtigen. Anliegen des Beitrags ist es anhand zweier Praxis­bei­spiele zu zeigen, dass die Bewertungsmethode Auswirkungen auf die Vor- oder Nachteilhaftigkeit hat.

Über die Autoren: Manuel Rojas ist Mitarbeiter im Controlling der Lomographischen AG in Wien, arbeitete mehrere Jahre im IT-Bereich und spezialisierte sich im Studium auf den Bereich Public Management. Seine Diplomarbeit an der Wirtschaftsuniversität Wien beschäftigte sich mit dem Thema „Freie/Open Software in der Öffentlichen Ver­waltung“.
Kontakt: [email protected]

Tobias Polzer ist Wissenschaftlicher Mitarbeiter am Institut für Public Management an der Wirtschaftsuniversität Wien. In seiner Dissertation beschäftigt er sich mit der Reform des österreichischen Haushalts­rechts. Weitere Interessensbereiche sind Performance Manage­ment und öffentliches Beschaffungswesen.
Kontakt: [email protected]

 

Einleitung

Open Source Software (OSS) im öffentlichen Sektor wird aus mehreren Gründen nachgesagt, eine kostengünstige Alternative zu proprietären Lösungen darzustellen. Im Unterschied zu proprietärer Software gibt es nämlich kaum direkte Beschaffungskosten, allenfalls bezahlt man für Dienstleistungen wie Service und Support. Auch entfallen periodisch notwendige Ausgaben für Softwareaktualisierungen bzw. kostenpflichtige Updates (Waring/ Mad­docks 2005: 414). Dementsprechend hofft z.B. die britische Regierung mit dem im Februar 2009 eingeführten „Open Source action plan“ Ein­sparungen von bis zu 600 Mio. Pfund pro Jahr zu erzielen (Thornton 2009: 15). Dies ist angesichts des in der Verwaltung herrschenden Kostendrucks ein nachvollziehbarer Schritt: Eine Studie der International Data Corporation (IDC) sieht für die westeuropäischen Länder einen Anstieg bei den Ausgaben für Hard- und Software sowie IT-Services von 41 Mrd. € 2008 auf über 50 Mrd. € im Jahr 2013 (Manhart 2010). Unter der Annahme, dass Software­kosten ca. 5% des IT-Budgets ausmachen (Georgiev et al. 2004: 83), wird das Ausmaß an Einsparpotenzial deutlich. In einer Studie des Fraunhofer Instituts für Arbeitswirtschaft und Organisation unter 115 Kommunen und öffentlichen Einrichtungen gaben dementsprechend 63% der Befragten an, dass die Einsparungen bei den Lizenzkosten zu Beginn ihres OSS-Projektes den wichtigsten Beweggrund darstellten. Die Einsparungen bei den Betriebskosten waren für weitere 42% ein wichtiges Motiv (Günther 2006: 32 f.).

 

Mitzuberücksichtigende Faktoren bei der Umstellung auf OSS

Bei einer Migration auf OSS treten kurzfristig, wie auch bei anderen Software-Migrationen, Installations-, Adaptions- und Schulungskosten auf (Schmitz 2001: 32; Waring/Maddocks 2005: 417). Zu diesen Kosten gehören auch Ausgaben für die Einführung neuer Dateiformate und Standards sowie notwendige Änderungen von Arbeitsprozessen (Varian/Shapiro 2003: 13). Ein Vergleich von OSS und proprietären Lösungen hat dementsprechend mög­lichst vielschichtig zu erfolgen. Anliegen dieses Beitrags ist es daher, auf die verschiedenen Berechnungsmethoden unterschiedlicher Modelle aufmerksam zu machen und aufzuzeigen, dass die Beantwortung der Frage „Kann der öffentliche Sektor mit OSS Einsparungen erzielen?“ keine einfache Angelegenheit ist.

 

Analyseinstrumente und Bewertungsmethoden

Hinter Akronymen wie TCO, TEI, WiBe und einigen weiteren verbergen sich Modelle für den wirtschaftlichen Vergleich von Investitionen. Diese sind jedoch unterschiedlich stark an den Softwarebereich und an die Gegebenheiten des öffentlichen Sektors angepasst. Je nach betrachtetem Zeithorizont und Detaillierungsgrad des verwendeten Modells können die Ergebnisse stark variieren.

 

Kostenbetrachtung: Das Total-Cost-of-Ownership-Modell

Das Total-Cost-of-Ownership-Konzept (TCO) ist ein Berechnungsmodell, das alle relevanten Lebenszykluskosten einer Investition betrachtet, um verschiedene Alternativen vergleichbar zu machen. Es sollen alle Kosten einbezogen werden, die aus Anschaffung und Betrieb einer IT-Investition während der gesamten Dauer resultieren (Wild/Herges 2000: 3 ff.). Typischerweise betrachtete Kostenblöcke sind z.B. der Anschaffungspreis, Schulungen, und notwendige Upgrades (Varian/Shapiro 2003: 12). Die TCO sehen vor, die Kosten in direkte (budgetierte) und indirekte (unbudgetierte) Kosten aufzu­teilen. Direkte Kosten entstehen aus der Bereitstellung einer Leistung an die Organisation und sind relativ einfach zu erfassen (z.B. Lohnabrechnungen oder Abschreibungen), die indirekten Kosten hingegen entstehen durch effizienzmindernde Vorgänge bei der Nutzung der IT-Infrastruktur (z.B. Aus­fall­­zeiten, Inanspruchnahme eines User-Supports), kurz, die unproduktiven Zei­ten am Arbeitsplatz während der Benutzung der IT. Diese Kosten sind, im Ge­gensatz zu den direkten, relativ schwer quantifizierbar und werden deshalb von Organisationen oft vernachlässigt, was zu einer Simplifizierung der Kos­ten­realität führt. Auch das TCO-Modell liefert keine konkreten Vorschläge, wie diese zu erheben sind (Wild/Herges 2000: 10 ff.). Neben dem ursprüng­li­chen Modell gibt es auch abgeleitete Varianten von IT-Analysten bzw. Con­sul­tingunternehmen, wie z.B. die Relative Costs of Operations Analysis (Reich­man/Staten 2008: 6 f.) oder die Real Cost of Ownership (Kirzner 1997: 16 ff.).

 

Kosten-Nutzenbetrachtung: Das Total-Economic-Impact-Modell

Da beim TCO-Modell nur einseitig der Wertverzehr (Investitionskosten) be­trachtet wird, und nicht der Wertzuwachs, hat dies zur Folge, dass es rein zu Kostensenkungen und -optimierungen beiträgt, während nicht gezielt auf eine Verbesserung der Leistung der IT-Infrastruktur hingearbeitet wird. Das Total-Economic-Impact-Modell (TEI) ist ein konzeptioneller Ansatz, um die fehlende Leistungsbetrachtung in ein Gesamtmodell zu integrieren. Es erfasst neben den Kosten der IT-Investition den Nutzen für die Organisation sowie die durch die Investition gewonnene Flexibilität im Sinne zukünftiger Möglich­­keiten. Zusätzlich fließen die Risiken der Investition (Wirkungen und Er­eig­nisse auf die anderen drei Faktoren, z.B. Schwierigkeiten bei der Imple­men­tie­rung oder Serverausfälle) in den TEI-Wert ein (Gliedman et al. 2008: 3 ff.).

Die Erfassung des Nutzens für die Organisation erfolgt mithilfe von Leis­tungskategorien, wobei diese zahlenmäßig operationalisiert werden müssen. Das Finden geeigneter Indikatoren und die entsprechende Operationalisierung können mitunter zu großen Schwierigkeiten führen (Rieder 2011: 477). Ein pragmatischer Ansatz, die Leistungen quantifizierbar zu machen, ist die Auswirkungen einer Reduktion der TCO auf die Aufgabenerfüllung der Investition hin zu untersuchen. Anschließend sollten nur die TCO reduziert oder vermieden werden, die die Aufgabenerfüllung nicht beeinflussen bzw. keine Wertzuflüsse bringen.

 

Wirtschaftlichkeitsbetrachtung für IT-Investitionen

Die Wirtschaftlichkeitsbetrachtung (WiBe) wurde von der ehemaligen deutschen Koordinierungs- und Beratungsstelle der Bundesregierung für Infor­ma­tionstechnik in der Bundesverwaltung (KBSt) eingeführt. Dabei handelt sich um ein Modell, das explizit auf IT-Anschaffungen abzielt. Manipulationsspielräume bei Annahmen über die Zukunft oder bei der Bildung von Indikatoren, die andere Modelle erlauben, sollen vor allem durch ein einheitliches, zentral geregeltes Verfahren beschränkt werden (Röthig 2005: 94 f.). Während zum einen die monetären Aspekte mithilfe einer dynamischen Kapitalwertmethode ermittelt werden, müssen nicht-monetäre Aspekte einer IT-Investition qualitativ bewertet werden. Hierfür dient eine Nutzwertanalyse, die die qualitativen Wirkungen nach ihrer strategischen Bedeutung gewichtet und so eine Entscheidung ermöglicht. Die Gesamtwirtschaftlichkeit einer IT-Lösung setzt sich aus vier sogenannten „Modulen“ (monetär quantifizierbarer Nutzen und Kosten, Dringlichkeit der Ablösung, qualitativ-strate­gische Bedeutung sowie externe Effekte) zusammen (BMI 2007: 16 ff.). Die Projektalternativen können dann als Portfolio dargestellt werden. Dabei wird auf einer Achse der Kosten/Nutzen-Aspekt und auf der zweiten Achse die qualitativen Aspekte dargestellt. Dies soll eine nachvollziehbare Bewertung von konkurrierenden IT-Projekten ermöglichen.

Durch die Bewertung des monetären und der drei nicht-monetären Aspekte liefert das WiBe-Modell eine belastbare Entscheidungsgrundlage für IT-Projekte. Bei positivem Kapitalwert ist ein Projekt prinzipiell durchführbar (bei mehreren, das mit dem höchsten Wert), bei negativem Kapitalwert kann ein Projekt aber auch durchführbar sein, wenn z.B. die qualitativ-strategi­schen Aspekte ein gewisses Ausmaß erreichen. Hier zeigt sich ein großer Vorteil dieser Bewertungsmethode, die eine verkürzte Sichtweise auf nur monetäre Aspekte verhindert.

 

Beispiele aus der Praxis: WIENUX und LiMux

WIENUX am Behördendesktop

In Wien wurden zwei Studien über den Einsatz von OSS an Arbeitsplätzen des Magistrats durchgeführt. Die erste Studie (STOSS 2004) beschäftigte sich neben der technischen Machbarkeit und Migrationsvarianten auch mit der wirtschaftlichen Beurteilung von drei Alternativszenarios. Der Zeithorizont betrug fünf Jahre, um einen späteren Systemwechsel mit abzubilden. In das Kalkulationsmodell flossen zweckmäßige Komponenten aus mehreren Modellen, darunter dem TCO-Modell und der WiBe ein. Zur Berechnung wurden nur jene Kosten einbezogen, die unmittelbar den Migrationsszenarien zugerechnet werden konnten – im Endeffekt die Unterschiede zwischen den Szenarien. Eine weitere Einschränkung nahm man bei indirekten Kosten vor. Aufgrund sehr schwer quantifizierbarer Messgrößen wurde der Fokus auf die direkten Kosten gelegt (Lutz et al. 2004: 23 ff.). Die errechneten Kosten der drei Migrationsszenarien über fünf Jahre, werden in Tabelle 1 veranschaulicht (Kosten in €).

Tabelle 1: Kostenkalkulation für verschiedene Migrationsszenarien in Wien laut Vorerhebungsstudie STOSS

Szenario

Ausgabenwirksame Kosten

Interne Kosten

Gesamt

Weiterführung Microsoft Windows und Office

2.450.000

1.750.000

4.200.000

Migrationsprojekt OpenOffice.org

1.000.000

5.500.000

6.500.000

Migrationsprojekt Linux

420.000

10.180.000

10.600.000

 

Quelle: Eigene Darstellung nach Lutz et al. 2004: 25 f.

Es zeigte sich, dass die Weiterführung von Microsoft Windows und Of­fice die sinnvollste Variante darstellte. Bei den ausgabenwirksamen Kostenpositionen flossen die Lizenzen und zu einem kleinen Teil auch die Schu­lungen ein – hier war die OSS-Migrationslösung mit Abstand die günstigste. Das Bild drehte sich aber, als man die internen Kosten betrachtete, die in dieser Kalkulation aus den höheren Personalkosten durch Schulungen, dem Projektmanagement und dem Support bestanden. Hier blieb die Weiterfüh­rung von MS Windows und Office als am vorteilhaftesten. Dies war vor allem auf das Fehlen von Ausgaben für Projektmanagement und Support und niedrigere Schulungskosten zurückzuführen.

LiMux für die Stadt München

In München wurden im Rahmen einer Vorstudie drei Migrationszielvarianten miteinander verglichen (UNILOG 2003: 18):

  • Microsoft Windows XP/MS Office XP (XP/XP)
  • MS Windows XP/OpenOffice.org (XP/OSS)
  • Linux/OpenOffice.org (LX/OSS, sowohl mit Terminal-Server [TS] als auch mit Virtualisierungslösung [VM])

Für die wirtschaftliche Beurteilung kam das WiBe-Modell zum Einsatz, der Betrachtungszeitraum wurde auf fünf Jahre festgelegt (UNILOG 2003: 16). Tabelle 2 zeigt die dabei errechneten Werte (in €).

Tabelle 2: Wirtschaftlichkeitsbetrachtung verschiedener Migrationsszenarien in München laut Unilog-Studie

Szenario

haushalts-
wirksam

nicht haus­haltswirksam

Gesamt­kosten

Kapitalwert

Position

XP/XP

16.099.343

18.082.813

34.182.157

-31.303.370

1

XP/OSS

15.573.516

24.172.115

39.745.631

-37.045.780

3

LX/OSS

19.395.667

26.373.360

45.769.027

-43.167.498

4

LX/OSS/VM

12.846.419

23.098.453

35.944.872

-33.762.122

2

LX/OSS/TS

25.014.287

24.994.144

50.008.431

-46.560.401

5

 

Quelle: Eigene Darstellung nach UNILOG 2003: 17 f.

 

Aus monetärer Betrachtungsweise lag die rein proprietäre MS-Lösung vorne. Dies wurde vor allem auf niedrigere Kosten bei der Hardwareanpassung, Migration, Schulung und Einarbeitung zurückgeführt, wenngleich die Lizenzkosten mit 7,3 Mio. € zu Buche schlugen. Dabei spielen bei dieser Sum­me die Lizenzen, die man bei der Migration sparen würde, nicht so eine große Rolle wie die laufenden Betriebskosten, die durch Lizenzwartung entstehen (z.B. der Abschluss eines Enterprise-Agreements für fünf Jahre). Die Differenz zur nächstbesten Variante LX/OSS/VM betrug bei den Gesamtkosten 1,76 und beim Kapitalwert 2,46 Mio. €. Interessanterweise wies aber vor allem diese OSS-Variante die niedrigsten haushaltswirksamen Kosten aller Alternativen auf. Daraus lässt sich schließen, dass die OSS-Lösung zu einer internen Mehrbelastung (z.B. bei budgetierten Personalressourcen) der vorhanden Kapazitäten, aber zu weniger haushaltswirksamen Neuausgaben führt. Dies zeigt sich auch bei näherer Betrachtung der Aufwendungen für Schu­lungen. Diese liegen bei den OSS-Varianten im Bereich von 17 bis 26 Mio. €, was zum Teil mehr als 50% der Gesamtkosten ausmacht. Da das WiBe-Kon­zept eingesetzt wurde, kam aber nicht nur eine monetäre Beurteilung zum Einsatz, sondern auch eine qualitativ-strategische Betrachtung der Varianten anhand einer Nutzwertanalyse. Die Kriterien, die betrachtet wurden, drehten sich u.a. um die Auswirkungen auf die IT-Sicherheit, auf die Mitarbeiter, auf externe Adressaten und auf die Einhaltung von Gesetzen und Vorschriften (UNILOG 2003: 20 ff.).

Tabelle 3: Qualitativ-strategische Betrachtung verschiedener Migrationsszenarien in München laut Unilog-Studie

Szenario

Punkte (max.: 10.000)

Position

XP/XP

5.293

4

XP/OSS

5.073

5

LX/OSS

6.218

1

LX/OSS/VM

5.960

2

LX/OSS/TS

5.780

3

 

Quelle: Eigene Darstellung nach UNILOG 2003: 23

 

Tabelle 3 zeigt, dass die Variante LX/OSS in der strategischen Betrachtung die höchste Punktzahl erreicht, während die in der monetären Betrachtung favorisierte XP/XP-Variante nur auf Position vier kommt. Auch wenn OSS nicht in jedem Punkt vorteilhaft ist, zeigt sich hierdurch doch, dass im direkten Vergleich mit proprietärer Software alle OSS-Varianten besser abgeschnitten haben. Das Dilemma der divergierenden Ergebnisse aus der monetären und qualitativ-strategischen Betrachtung konnte in der Studie nur durch eine Verknüpfung beider Aspekte gelöst werden. Es wurde festgelegt, dass beide Aspekte mit je 50% gewichtet werden sollten. Anschließend wurde für jede Alternative der Quotient beider Werte gebildet (Kosten in € pro qualitativ-strategischem Punkt). Aufgrund dieser Betrachtung wurde die Variante LX/OSS/VM zur insgesamt (strategisch und monetär) vorteilhaftesten Variante, gefolgt von XP/XP.

 

Fazit

Kostspielige Abhängigkeiten

Die prinzipielle Frage, ob OSS günstiger als proprietäre Software ist, kann insofern bejaht werden, als die Anschaffungskosten bei OSS meist niedriger als bei proprietärer Software sind. Die Schwierigkeit besteht aber darin, die­sen Vorteil auf eine bestehende IT-Infrastruktur zu übertragen. Da Lizenz­kosten im Grunde nur einen kleinen Teil der Gesamtkosten einer Migration aus­machen, treten Einsparungen erst mittel- bis langfristig ein. Migra­tions­kosten sind jedoch kein OSS-spezifisches Problem, treten diese ja auch bei jeder anderen Umstellung im Softwarebereich mehr oder minder stark auf. Durch die bisher eher geringe Verbreitung von OSS im Client-Bereich ist dies aber ein wirklicher Nachteil. Durch Pfadabhängigkeiten und hohe Inve­sti­tionen in eine Technologie, können die Migrationskosten daher sehr hoch ausfallen, will man einen Technologiewechsel vollziehen. Könnte man mit dem Aufbau einer völlig neuen IT-Infrastruktur beginnen, würde die ur­sprüng­liche Argumentation des Kostenvorteils aber greifen. Gerade im Hin­blick auf die zahl­reichen nicht-monetären Vorteile, die OSS mit sich bringt, scheint ein Be­wertungsmodell, das zusätzlich qualitativ-strategische Faktoren einbezieht, bes­ser für einen Alternativenvergleich geeignet zu sein als ein rein kos­ten­basiertes Verfahren.

Unzulänglichkeiten bestehender Modelle

Eine Kritik, die alle Berechnungsmodelle gleichermaßen trifft, ist die relativ einfache Manipulierbarkeit des Ergebnisses: Dadurch, dass viele Kostenposi­tionen geschätzt werden müssen bzw. einfach weggelassen oder hinzugefügt werden, kann man die Berechnungen in eine gewisse Richtung lenken. Weiters kann die Art der Gewichtung der qualitativen und quantitativen Kriterien das Ergebnis beeinflussen. Zusätzlich zeigt sich in der Praxis, dass Betrachtungszeiträume gewählt werden, die mit fünf Jahren eigentlich zu kurz bemessen sind; so werden etwa die Exit Costs, die bei einer Umstellung von proprietärer Software auf OSS und umgekehrt entstehen, mitunter verzerrt dargestellt. Wenn man das langfristige Einsparungspotenzial von OSS einrechnen will, bräuchte man Berechnungen mit einem bis zu zehnjährigen Betrachtungszeitraum. Bei den Berechnungen in Wien und München zeigte sich, dass OSS zwar kurzfristig niedrigere ausgabenwirksame Kosten als proprietäre Varianten, dafür aber wesentlich höhere interne Kosten verursacht. Eine Investition in OSS erfordert deshalb langfristiges Denken, das auch wegen kurzer Legislaturperioden in der Politik nicht immer vorhanden ist. Man sollte sich bewusst sein, dass die Bewertungsmethoden für politische Zwecke instrumentalisiert werden können und deshalb die Ergebnisse aus einer gewissen kritischen Distanz betrachten.

Kann man mit OSS überhaupt einsparen?

Ob mit OSS Einsparungen erzielt werden können, ist sehr vom individuellen Einzelfall, von bestehenden Abhängigkeiten und vom Betrachtungszeitraum abhängig. Der falsche Weg ist aber sicherlich, OSS als Budgetsanierungsmaßnahme zu sehen. Man muss die Idee verwerfen, dass eine Migration auf OSS schnell zu hohen Einspa­run­gen führt. Es gibt sehr viele gute Gründe, auf OSS zu wechseln, aber das fi­nan­zielle Argument ist bei den derzeitigen Rahmenbedingungen in der Ver­waltung kein ausschlaggebendes. Eine langfristige Migrationsplanung unter Betrachtung der Exit Costs (etwa sind diese beim Auslaufen der proprietären Produktunterstützung am geringsten) kann hier Abhilfe schaffen. Es hat sich zudem gezeigt, dass einheitliche Richtlinien und Standards bei Arbeitspro­zessen und bei der Datenspeicherung sowie konsolidierte Datenbestände die Datenmigration stark vereinfachen. Eine fragmentierte und heterogene IT-Infrastruktur jedoch verzögert nicht nur den Projektablauf, sondern erhöht auch dementsprechend die Kosten. Setzt man daher schon vor der Migration auf plattformunabhängige Lösungen und offene Standards, erleichtert dies den Umstieg enorm, senkt somit den Migrationsaufwand und führt schneller zu den erhofften Einsparungen.

 

Quellen

BMI (Bundesministerium des Innern) (2007): WiBe 4.1. Empfehlung zur Durchführung von Wirtschaftlichkeitsbetrachtungen in der Bundesverwaltung, insbesondere beim Einsatz der IT; http://www.cio.bund.de/SharedDocs/Publika­tionen/DE/ IT-Methoden/wibe_fachkonzept_download.pdf?__blob=publicationFile, 10.09.2011.

Georgiev, E.; Haber, G.; Reifensteiner, J.; Sallmann, R. (2004): Open Source Soft­ware – Einsatz in der öffentlichen Verwaltung. Wien: Österreichischer Städte­bund.

Gliedman, C.; Erickson, J.; Hughes, L.; Leaver, S. C. (2008): The Total Economic Im­pact Methodology: A Foundation For Sound Technology Investments. Forrester Reserarch.

Günther, J. (2006): Open Source Software – Strukturwandel oder Strohfeuer?, in: Spath, D. (Hrsg.): Open Source Software – Strukturwandel oder Strohfeuer? Eine empirische Studie zu Trends und Entwicklungen zum Einsatz von Open Source Software in der öffentlichen Verwaltung und IT-Unternehmen in Deutschland. Stuttgart: Fraunhofer Institut für Arbeitswirtschaft und Organisation.

Kirzner, R. (1997): Real cost of ownership of network computer devices. A multiclient study. META Group Consulting.

Lutz, B.; Potakowskyj, J.; Richter, K.; Starnberger, K. (2004): Studie OSS. Open Source Software am Arbeitsplatz im Magistrat Wien; http://www.wien.gv.at/ ma14/pdf/oss-studie-deutsch-langfassung.pdf, 10.09.2011.

Manhart, K. (2010): IDC-Prognose: Regierungen pumpen Milliarden in IT; http://www.cio.de/dynamicit/bestpractice/2224294/index.html, 10.09.2011.

Reichman, A.; Staten, J. (2008): TCO is overrated; http://www.hds.com/assets/pdf/ forrester-tco-is-overrated-storage-economics.pdf, 10.09.2011.

Rieder, S. (2011): Performance Indicators, in: Blanke, B.; Nullmeier, F.; Reichard, C.; Wewer, G. (Hrsg.): Handbuch zur Verwaltungsreform. 4. Aufl., Wiesbaden: VS, S. 477–483.

Röthig, P. (2005): Wirtschaftlichkeitsbetrachtung („WiBe“) von IT-Lösungen. In: Jahrbuch Verwaltungsmodernisierung 2005/2006, hrsg. von Wegweiser GmbH. Berlin, S. 94–95.

Schmitz, P.-E. (2001): Study into the use of Open Source Software in the Public Sector. Part 1: OSS Fact Sheet. European Commission, DG Enterprise.

Thornton, J. (2009): Open sesame, in: Public Finance (20.–26. Nov.), S. 15.

Unilog Integrata Unternehmensberatung GmbH (2003): Client Studie der Landeshauptstadt München. Kurzfassung des Abschlussberichts inklusive Nachtrag; http://www.muenchen.info/pia/clientstudie_kurz.pdf, 10.09.2011.

Varian, H. R.; Shapiro, C. (2003): Linux Adoption in the Public Sector: An Economic Analysis. University of California at Berkeley Working Paper.

Waring, T.; Maddocks, P. (2005): Open Source Software implementation in the UK public sector: Evidence from the field and implications for the future, in: International Journal of Information Management 2: 5, 411–428.

Wild, M.; Herges, S. (2000): Total Cost of Ownership (TCO) – Ein Überblick.
Gießen: Arbeitspapiere WI; http://geb.uni-giessen.de/geb/volltexte/2004/1577/ pdf/Apap_WI_2000_01.pdf, 10.09.2011.

Dieser Beitrag wurde unter 2. Anwendbarkeit, Alle Texte, Anwendungsgebiete, Implementierung, Potenziale, Sicherheit, Standards, Vorteile, Wirtschaftlichkeit abgelegt und mit , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , verschlagwortet. Setzen Sie ein Lesezeichen auf den Permalink.

Die Kommentarfunktion ist geschlossen.