Man könnte sich noch nach Alternativen für diese Programme umsehen oder Druck auf die Hersteller ausüben, damit diese die benötigten Anpassungen vornehmen, aber ich glaub, das wird so schnell nichts mehr.
Tja, nicht jeder wechselt erfolgreich von heute auf morgen auf OpenSource. Gehört dazu, kann man nix machen (außer natürlich den Nicht-Umsteigegrund zu beseitigen)
Das Problem ist das sich viel zu viele kommerzielle Applikationen auf die M$ Office Suite stuetzen. Alternativen gibt es wenige, da es sich meist um Branchen- oder Nieschensoftware handelt.
Ich habe schon mehrfach versucht solche Hersteller aufzufordern Ihre Anwendungen plattformneutral anzubieten, jedoch ohne Erfolg.
Wenn allerdings der Druck von allen Seiten groesser wird, sind auch solche Softwarehersteller gezwungen sich an die veraenderten Bedingungen anzupassen.
Ich kann also nur jeden der so etwas feststellt auffordern sich zu Wort zu melden.
Das naechste Problem ist die Akzeptanz bei den Anwendern selber. Viele haben nunmal mit dem Kauf Ihres PCs ein M$ Office erworben oder es raubkopiert, wurden evtl. sogar in der Schule oder auf der Arbeit auf die Bedienung geschult und tun sich schwer mit Veraenderungen.
Eine Migration ohne Anwenderschulungen ist aus meiner Sicht zum scheitern verurteilt.
> Ich habe schon mehrfach versucht solche Hersteller aufzufordern Ihre Anwendungen plattformneutral anzubieten, jedoch ohne Erfolg.
Weil der Code meist erst mit gigantischem Aufwand plattformunabhängig gemacht werden müsste, bei zugekauften Libraries das Selbe Problem besteht und es sich für den Hersteller nicht rechnet. Der Kunde will den zusätzlichen Aufwand für Portierung und Support dann ja nicht auf der Rechnung sehen.
Zudem wird sowas in der Lehre vernachlässigt, eine gigantische Anzahl von Entwicklern hat die notwendigen Kenntnisse einfach nicht.
Die Hersteller machen sich leider zu wenig Gedanken und die Kunden wollen meist auch nur ihre Funktionalität sehen. Da werden dann wird schnell auf dem Komponentenmarkt teures Spielzeug eingekauft. Oder um entwicklungskosten zu sparen irgendwelche libs von "Standard"-Andwendungen wie MSO oder IE verwurstet.
Welchen mist man sich eingekauft hat merkt der Kunde erst wenn es ernst wird. Da hängt man wegen einer Anwendung an einem alten IE fest oder man braucht plötzlich ein neues MSO weil bei der Fachanwendung in der neuen Version bestimmte dinge nicht gehen. Kommerzielle Softwareentwicklung ist eben meist nur sich fürs zusammenbasteln irgendwelcher Schrottkomponenten bezahlen zu lassen. Will man das anders sind die Hersteller oft nicht in der Lage, weil die studentischen Hilfsprogrammierer überhaupt nicht die kenntnisse haben es anders zu machen. Die Anwendung wächst mit der Zeit mit ihren Aufgaben, diese zu ersetzen würde dann eine komplette Neuentwicklung bedeuten.
Ich frag mich aber warum jede Stadt ihren eigenen Mist einkaufen muss und wenn migriert wird nie das Projekt einer StadtX auf die eigene übertragen sondern muss wieder alles neu geschaffen werden. Da braucht es doch einfach nur EINE Plattform für die Prozesse, die in einer Stadt vorkommen und die wird dann in Teilen angepasst.
Das holländische Modell ist gut, man muss sich nicht dran halten, aber wenn man sich nicht dran hält, muss man das ausdrücklich rechtfertigen.
Holland hat ganz gewaltigen Druck aufgebaut. Da müssen nun auch andere Länder mithelfen und den Druck für Interoperabilität bei Dokumentformaten erhöhen.
Abhängigkeiten sind ein Problem für die strategische Unabhängigkeit eines Landes, und müssen daher erkannt und durch konzertierte Massnahmen beseitigt werden. Sie gefährden die nationale Sicherheit.
Es ist kein Problem Abhängigkeiten zu haben, aber es ist ein Problem, nichts dagegen zu tun.
Ist das denn tatsächlich ein Problem der Dokumentenformate?
So wie Ich den Kram kenne bauen die Anwendungen doch eher über COM oder ActiveX aufeinander auf. Eine echte Automatisierung bekommt man doch sonst auch gar nicht so einfach hin, und das gleiche Problem kann man mit freier Software auch bekommen - z.B. wenn man OpenOffice UNO nutzt, dann kann man auch nicht morgen hingehen und OpenOffice durch KOffice ersetzen.
Ja, es ist sehr wichtig die Dokumente in offenen standards zu haben. Das ist eine starke Migrationshürde.
Zur Plattformunabhängigkeit von Fachanwendungen gab es übrigens einen schönen Führer vom CIO. http://www.cio.bund.de/DE/IT-Methoden/Plattformunabhaengigkeit/plattformunabhaengigkeit_node.html
Plattformabhängigkeit ist ein kritisches Problem für die eigene Infrastruktur und muss ausgeräumt werden.
Von Der Erleuchtete am Do, 25. Februar 2010 um 17:26 #
Falsch! OpenSource vernichtet Arbeitsplätze, da man die Manpower auf die Community auslagert. Die besteht zu 90% aus Hobbyprogrammierer, ohne IT-Relevante Ausbildung. Das darunter der Code zu leiden hat dürfte wohl jedem klar sein.
Schlechter Code => Schlechte Software => Firma geht Pleite => Arbeitslose.
Von Der Erleuchtete am Do, 25. Februar 2010 um 18:10 #
Du behauptest also, dass wenn die Firma OpenSource benutzt und damit ständig mit Datenverlust oder anderen Bugs zu kämpfen hat nicht Firmenschädigend ist?
Von FieserKiller am Do, 25. Februar 2010 um 19:21 #
Es gibt 2 Möglichkeiten: a) Firma kauft Software und hat mit Datenverlust und anderen Bugs zu kämpfen b) Firma nutzt freie software und hat mit datenverlust und bugs zu kämpfen
Version a) Man kontaktiert den Hersteller und beschwert sich, er verweist dann auf die Lizenz (Die, die man sich nie durchliest und bestätigt, du weisst schon) und in der Steht dass die Firma für keine datenverluste haftet. Er ist aber ein guter Hersteller, nimmt die Beschwerde ernst und erstellt ein paar tickets mit bugbeschreibung. Irgendwann werden diese dann gelöst (Je nach service level agreement) und alles ist in butter. Oder es brennt und eilt, dann bietet der hersteller an ein paar consultants für den günstigen Tagessatz von 1200€ pro mitarbeiter vorbeizuschicken, die schauen sich das ganze dann an und versuchen der sache fix auf den grund zu gehen
Version b) Man kontaktiert das Projekt und füllt bugreports aus, für datenverluste haftet wie bei Version a) übrigens auch niemand. Ist es ein gutes, lebendiges projekt, werden die bugs bearbeitet und gefixt. Wenns brennt oder das Projekt tot ist, dann verpflichtet die Firma halt einen der Entwickler oder jemanden inhouse aus der Entwicklerabteilung für Geld den bug zu fixen, zb für 1200€ am Tag, wahrscheinlich eher günstiger oder auf erfolgsbasis. Sind die entwickler ncht zu erreichen und man hat selbst keine kapazitäten im haus, kontaktiert man eine entsprechende örtliche linux supportbude und lässt sich von ihnen jemanden rüberschicken der sich der sache annimmt, für geld versteht sich. Ist die Software mission critical, dann hat man natürlich von vorn herein einen Supportvertrag für die software abgeschlossen, und hat immer einen ansprechpartner. Oder man stellt direkt ein paar leute ein die das freie Programm hausintern pflegen und weiterentwickeln und das know how direkt in der firma halten und in zukunft bei weiteren freien Programmen bugfixing und weiterentwicklung betreiben.
Du siehst, so unterschiedlich ist das ganze nciht, die freie lösung ist halt tendenziell günstiger falls das programm keine probleme macht, aber falls es probleme macht muss man es fixen lassen, entweder von den entwicklern im rahmen des normalen bugtrackings oder man bezahlt leute die es mit priorität tun. Hinzu kommen halt die vorteile der freien lösungen: Man kann das programm nach belieben modifizieren und an die eigenen prozesse adaptieren, man ist nicht von der Preis- oder Produktpolitik des herstellers abhängig und kann jederzeit forken, die kosten für die Weiterentwicklung verteilen sich auf viele schultern. Aus diesem grund ziehe ich freie Software der proprietären immer vor, wenn beide zur auswahl stehen. parkuhr
Stellt sich aber die Frage was man hat Software von der Stange oder angepasste Fachanwendung. Bei Werksverträgen haftet man dann schon, egal ob Variante a) oder b) . Pack ich als Servicedienstleister fremde Software dazu kann mir auch egal sein ob a) oder b) die Margen sind bei a) sowieso zu vernachlässigen wenn überhaupt vorhanden. Zumal man erst mal tief in die Tasche greifen darf um für entsprechende Firmen die Software zu Vertreiben oder gar Erweiterungen programmieren zu dürfen. Während man bei c) es aber jeder kann und darf, dann muss man mit Qualität überzeugen.
Das Problem sind weniger die OOo bzw. MSO, as Problem sind die eingekauften Fachanwendungen welche eine teure ClosedSource Infrastruktur voraussetzen.
Von TrollHacker am Do, 25. Februar 2010 um 17:51 #
also alle größeren OpenSource Projekte werden in der Regel durch Firmen unterstützt bzw. sind dort federführend (oder stellen die Prgrammierer an wie Novell SuSE oder Redhat, aber auch IBM und ehemals SUN). Und wenn es Hobbyprogrammierer sind, arbeiten diese hauptberuflich im IT Feld und sind einschlägig vorbelastet. Oder welches Opensourceprojekt mit Relevanz ist ausschließlich in der Hand von Hobbyprogrammierern ohne Programmierkenntnissen? Ansonsten sind die schlimmsten "Programmierverbrechen in PHP und eben in Access/VB oder ähnlichem zu finden, da bei letzterem schnell mal eine "Anwendung" zusammegeklickt werden kann, die mit aus dem Netz zusammenkopiertem Code "wächst".
nur weil IBM drauf steht ist noch lange keine Qualität drin. Das PHP Bashing ist auch völlig fehl am Platz. Man kann gute Programme schreiben oder auch schlechte. Egal ob C#, Ruby Java oder eine andere Sprache. Am Ende ist es auch besser ein Programm mit schlechtem Code zu haben als gar keine Lösung. Ein Hobbyprogrammierer brauch auch jedes Highlight einer Sprache kennen.
Entscheidender ist doch was in den Firmen geschaffen wird, und da ist nicht BigBlue gemeint. IBM ist wohl der größte einzelanbieter. Die Masse der Codezeilen von kleinen IT-Firmen ist aber weitaus größer. IBM & Co sind an den dicken Projekten dran, mit den kleinen Fachanwendungen haben die überhaupt nichts am Hut. Wie toll der Code der Profis ist bekommt man auch immer mal mit bei gewissen Problemen bei der Telekom wenn bei T-Systems mal wieder gepatzt wurde.
> Das PHP Bashing ist auch völlig fehl am Platz. Man kann gute > Programme schreiben oder auch schlechte. Egal ob C#, Ruby Java > oder eine andere Sprache.
Dieses Gebet ist grober Unfug. Wenn das Werkzeug scheiße ist, kommt nunmal nix bei rum.
Von Der Erleuchtete am Do, 25. Februar 2010 um 22:28 #
Wunderbar. Du sagst also, dass alle studierten Informatiker aufmal eine Bäckerlehre machen sollen. Toll! Denk den Gedanken mal weiter: Wenn alle Informatiker nur noch Bäcker werden können, wird auch keiner mehr Informatik studieren oder eine Ausbildung darin machen. Wenn es keine Infomartiker mehr gibt, dann programmieren nur noch Hobbyprogrammierer und Wannabes. Wenn nur noch Hobbyprogrammierer und Wannabes programmieren, wird der Quellcode immer schlechter.
Von Hutschnurhochgehenlasser am Sa, 27. Februar 2010 um 01:00 #
Programmierer (z.B. in Form des Organisationsprogrammierers) ist ein Ausbildungsberuf mit IHK-Abschluß, Informatiker gibt es sowohl als Studiengang mit Diplom als auch als Ausbildungsberuf mit staatlicher Abschlußprüfung. Allerdings arbeiten meist nur die nicht sonderlich erfolgreichen Diplominformatiker als Programmierer, ähnlich wie nicht erfolgreiche Maschinenbauingenieure der Fachrichtung Fahrzeiugtechni als KFZ-Mechanier oder Diplomingenieure der Nachrichtentechnik als Elektroinstallature. Natürlich liest es sich imer toll wenn da ein Dipl.Inf. oder Dipl.Ing. vor dem Namen auf der Visitenkarte steht aber wenn man genau nachdenkt weiss man daß da jemand an seinem erlernten Beruf vorbei arbeitet und sicherlich nicht so konzentriert und motiviert ans Werk geht wie derjenige, der die korrekte Ausbildung dazu hat. Und genau das sind ja sooft Ursache von Datenverlusten und Systemabstürzen proprietärer (!) Software da dort im Gegensatz zu OpenSource Projekten eben sehr sehr oft unmotiviert gearbeitet wird und entsprechend oft Schluderei zu finden ist wenn man mal hinter die Kulissen guckt! Den Informatiker sollte man eher an das setzen was er kann: Das erfassen und abstrahieren von Problemstellungen inklusive der Entwicklung von Lösungsschemata die DANN von GELERNTEN Programmieren umgesetzt werden oder zusammen mit Kollegen der Hardwareentwiclklung (Dipl.Ing. NT oder ET) in Hardware geplant und dann von Hardwarefertigern (z.B. Systemelektronikern oder Kommunikationselektronikern mit IHK-Abschluß) als Ergebnis umgesetzt werden. Nur, um sowas dann auch in einer Verwaltung umzusetzen muss man sich eben Fachleute die objektiv erstmal die Problemstellung analysieren heranholen und keine Lobbyisten die als Marketingexperten auf Biegen und Brechen IHR Produkt verkaufen wollen auch wenns gar nicht zum Problem passt (siehe z.B. die netten Toll-Collect Pannen mit den OnBUs)......in NL wurde sowas mal wieder erst realisiert als es zu spät war und die Verstrickungen sich eben nicht mehr wirklich lösen ließen. Lobbyisten sei dank halt mal wieder ;).....
Eines sollten diese Leute in den Entscheiderstellen endlich mal kapieren: Das Beste Programm ist das, daß das Problem vernünftig lösen hilft und nicht immer das Programm, daß die Kassen der Entscheider und der Lieblingsfoirmen füllt.
Tja, das Problem kenn ich. Wir habe hier auch versucht OpenOffice einzuführen, sind aber letzendlich an Abhängigkeiten gescheitert.
So kommt unter Anderem SAP deutlich besser mit MS-Office zurecht. Daher werden wir demnächst alles auf MS-Office 2010 umstellen. Und es wird dann hier auch keine Ausnahmen geben. Daher muß ich mein OpenOffice auch deinstallieren.
... anders kann ich es mir nicht erklären, warum diverse Behörden und Kommunen nicht das Geld in die Hand nehmen und sich zusammentun, um
a) Notwendigkeiten von Spezialanwendungen zu sondieren b) Arbeitsabläufe behördenübergreifend zu standardisieren c) freie Anwendungen für diese Abläufe zu entwickeln
Freie Software lebt vom Mitmachen, und das Geld des Steuerzahlers sollte nicht ohne Not für Software ausgegeben werden, von der er selbst nichts hat (sprich: proprietäre Lösungen). Bedauerlicherweise sehen viele Entscheider Freie Software als Basar für kostenlose Anwendungen.
Also wir stellten alles auf Linux Desktop um und com rdesktop - Terminal Server konnten alle weiterarbeiten. Dann fingen wir an die Software zu analisieren. Programmierten via Php-Apache die Software und loeschten die Excelabhaengigen Tabellen. So braucht man den Browser und fuer die Exoten den rdesktop! Active X via rdesktop usw. Alles laeuft geschmiert! Und es wird jeden Tag weniger! Eines Tages vielleicht koennen wir dann den Windows Terminal Server formatieren!
Man könnte sich noch nach Alternativen für diese Programme umsehen oder Druck auf die Hersteller ausüben, damit diese die benötigten Anpassungen vornehmen, aber ich glaub, das wird so schnell nichts mehr.
Tja, nicht jeder wechselt erfolgreich von heute auf morgen auf OpenSource. Gehört dazu, kann man nix machen (außer natürlich den Nicht-Umsteigegrund zu beseitigen)
Grueße
Ignatz
Das Problem ist das sich viel zu viele kommerzielle Applikationen auf die M$ Office Suite stuetzen. Alternativen gibt es wenige, da es sich meist um Branchen- oder Nieschensoftware handelt.
Ich habe schon mehrfach versucht solche Hersteller aufzufordern Ihre Anwendungen plattformneutral anzubieten, jedoch ohne Erfolg.
Wenn allerdings der Druck von allen Seiten groesser wird, sind auch solche Softwarehersteller gezwungen sich an die veraenderten Bedingungen anzupassen.
Ich kann also nur jeden der so etwas feststellt auffordern sich zu Wort zu melden.
Das naechste Problem ist die Akzeptanz bei den Anwendern selber. Viele haben nunmal mit dem Kauf Ihres PCs ein M$ Office erworben oder es raubkopiert, wurden evtl. sogar in der Schule oder auf der Arbeit auf die Bedienung geschult und tun sich schwer mit Veraenderungen.
Eine Migration ohne Anwenderschulungen ist aus meiner Sicht zum scheitern verurteilt.
Viele Gruesse
Marcus Moeller
> Ich habe schon mehrfach versucht solche Hersteller aufzufordern Ihre Anwendungen plattformneutral anzubieten, jedoch ohne Erfolg.
Weil der Code meist erst mit gigantischem Aufwand plattformunabhängig gemacht werden müsste, bei zugekauften Libraries das Selbe Problem besteht und es sich für den Hersteller nicht rechnet. Der Kunde will den zusätzlichen Aufwand für Portierung und Support dann ja nicht auf der Rechnung sehen.
Zudem wird sowas in der Lehre vernachlässigt, eine gigantische Anzahl von Entwicklern hat die notwendigen Kenntnisse einfach nicht.
Die Hersteller machen sich leider zu wenig Gedanken und die Kunden wollen meist auch nur ihre Funktionalität sehen. Da werden dann wird schnell auf dem Komponentenmarkt teures Spielzeug eingekauft. Oder um entwicklungskosten zu sparen irgendwelche libs von "Standard"-Andwendungen wie MSO oder IE verwurstet.
Welchen mist man sich eingekauft hat merkt der Kunde erst wenn es ernst wird. Da hängt man wegen einer Anwendung an einem alten IE fest oder man braucht plötzlich ein neues MSO weil bei der Fachanwendung in der neuen Version bestimmte dinge nicht gehen. Kommerzielle Softwareentwicklung ist eben meist nur sich fürs zusammenbasteln irgendwelcher Schrottkomponenten bezahlen zu lassen. Will man das anders sind die Hersteller oft nicht in der Lage, weil die studentischen Hilfsprogrammierer überhaupt nicht die kenntnisse haben es anders zu machen. Die Anwendung wächst mit der Zeit mit ihren Aufgaben, diese zu ersetzen würde dann eine komplette Neuentwicklung bedeuten.
Ich frag mich aber warum jede Stadt ihren eigenen Mist einkaufen muss und wenn migriert wird nie das Projekt einer StadtX auf die eigene übertragen sondern muss wieder alles neu geschaffen werden. Da braucht es doch einfach nur EINE Plattform für die Prozesse, die in einer Stadt vorkommen und die wird dann in Teilen angepasst.
Das holländische Modell ist gut, man muss sich nicht dran halten, aber wenn man sich nicht dran hält, muss man das ausdrücklich rechtfertigen.
Holland hat ganz gewaltigen Druck aufgebaut. Da müssen nun auch andere Länder mithelfen und den Druck für Interoperabilität bei Dokumentformaten erhöhen.
Abhängigkeiten sind ein Problem für die strategische Unabhängigkeit eines Landes, und müssen daher erkannt und durch konzertierte Massnahmen beseitigt werden. Sie gefährden die nationale Sicherheit.
Es ist kein Problem Abhängigkeiten zu haben, aber es ist ein Problem, nichts dagegen zu tun.
Ist das denn tatsächlich ein Problem der Dokumentenformate?
So wie Ich den Kram kenne bauen die Anwendungen doch eher über COM oder ActiveX aufeinander auf. Eine echte Automatisierung bekommt man doch sonst auch gar nicht so einfach hin, und das gleiche Problem kann man mit freier Software auch bekommen - z.B. wenn man OpenOffice UNO nutzt, dann kann man auch nicht morgen hingehen und OpenOffice durch KOffice ersetzen.
Ja, es ist sehr wichtig die Dokumente in offenen standards zu haben. Das ist eine starke Migrationshürde.
Zur Plattformunabhängigkeit von Fachanwendungen gab es übrigens einen schönen Führer vom CIO.
http://www.cio.bund.de/DE/IT-Methoden/Plattformunabhaengigkeit/plattformunabhaengigkeit_node.html
Plattformabhängigkeit ist ein kritisches Problem für die eigene Infrastruktur und muss ausgeräumt werden.
Ich kann da nur zu stimmen. Man mag sich garnicht ausdenken, wie viele Arbeitsplätze durch OpenSource gefährdet wird.
es sind nur die Arbeitsplätze der reinen VBA Programmierer gefährdet, die nichts anderes können und nie was anderes lernen werden
Falsch! OpenSource vernichtet Arbeitsplätze, da man die Manpower auf die Community auslagert. Die besteht zu 90% aus Hobbyprogrammierer, ohne IT-Relevante Ausbildung.
Das darunter der Code zu leiden hat dürfte wohl jedem klar sein.
Schlechter Code => Schlechte Software => Firma geht Pleite => Arbeitslose.
Haha
Du scheinst kein Programmierer zu sein! Ich kenn das genau anders rum...
Was ich schon Code gesehen hab, ich würde mich schämen den Quellcode zu veröffentlichen
Und das ist dann meistens der Code, auf dem die Ganze IT aufbaut
Was soll eigentlich dieses gebashe mit Opensource und Firma Pleite?
Also jede Firma die wegen Opensource pleite geht, geht auch ohne pleite...
Aber wie heißt es so schön:
Wenn der Wind der Veränderung weht bauen die einen Windräder und die anderen Mauern.
Du behauptest also, dass wenn die Firma OpenSource benutzt und damit ständig mit Datenverlust oder anderen Bugs zu kämpfen hat nicht Firmenschädigend ist?
Gegenfrage: Was hat das eine mit dem anderen zu tun? Ich sehe da keinen Zusammenhang.
Es gibt 2 Möglichkeiten:
a) Firma kauft Software und hat mit Datenverlust und anderen Bugs zu kämpfen
b) Firma nutzt freie software und hat mit datenverlust und bugs zu kämpfen
Version a)
Man kontaktiert den Hersteller und beschwert sich, er verweist dann auf die Lizenz (Die, die man sich nie durchliest und bestätigt, du weisst schon) und in der Steht dass die Firma für keine datenverluste haftet. Er ist aber ein guter Hersteller, nimmt die Beschwerde ernst und erstellt ein paar tickets mit bugbeschreibung. Irgendwann werden diese dann gelöst (Je nach service level agreement) und alles ist in butter. Oder es brennt und eilt, dann bietet der hersteller an ein paar consultants für den günstigen Tagessatz von 1200€ pro mitarbeiter vorbeizuschicken, die schauen sich das ganze dann an und versuchen der sache fix auf den grund zu gehen
Version b)
Man kontaktiert das Projekt und füllt bugreports aus, für datenverluste haftet wie bei Version a) übrigens auch niemand. Ist es ein gutes, lebendiges projekt, werden die bugs bearbeitet und gefixt. Wenns brennt oder das Projekt tot ist, dann verpflichtet die Firma halt einen der Entwickler oder jemanden inhouse aus der Entwicklerabteilung für Geld den bug zu fixen, zb für 1200€ am Tag, wahrscheinlich eher günstiger oder auf erfolgsbasis. Sind die entwickler ncht zu erreichen und man hat selbst keine kapazitäten im haus, kontaktiert man eine entsprechende örtliche linux supportbude und lässt sich von ihnen jemanden rüberschicken der sich der sache annimmt, für geld versteht sich. Ist die Software mission critical, dann hat man natürlich von vorn herein einen Supportvertrag für die software abgeschlossen, und hat immer einen ansprechpartner. Oder man stellt direkt ein paar leute ein die das freie Programm hausintern pflegen und weiterentwickeln und das know how direkt in der firma halten und in zukunft bei weiteren freien Programmen bugfixing und weiterentwicklung betreiben.
Du siehst, so unterschiedlich ist das ganze nciht, die freie lösung ist halt tendenziell günstiger falls das programm keine probleme macht, aber falls es probleme macht muss man es fixen lassen, entweder von den entwicklern im rahmen des normalen bugtrackings oder man bezahlt leute die es mit priorität tun. Hinzu kommen halt die vorteile der freien lösungen: Man kann das programm nach belieben modifizieren und an die eigenen prozesse adaptieren, man ist nicht von der Preis- oder Produktpolitik des herstellers abhängig und kann jederzeit forken, die kosten für die Weiterentwicklung verteilen sich auf viele schultern.
Aus diesem grund ziehe ich freie Software der proprietären immer vor, wenn beide zur auswahl stehen. parkuhr
Stellt sich aber die Frage was man hat Software von der Stange oder angepasste Fachanwendung. Bei Werksverträgen haftet man dann schon, egal ob Variante a) oder b) . Pack ich als Servicedienstleister fremde Software dazu kann mir auch egal sein ob a) oder b) die Margen sind bei a) sowieso zu vernachlässigen wenn überhaupt vorhanden. Zumal man erst mal tief in die Tasche greifen darf um für entsprechende Firmen die Software zu Vertreiben oder gar Erweiterungen programmieren zu dürfen. Während man bei c) es aber jeder kann und darf, dann muss man mit Qualität überzeugen.
Das Problem sind weniger die OOo bzw. MSO, as Problem sind die eingekauften Fachanwendungen welche eine teure ClosedSource Infrastruktur voraussetzen.
also alle größeren OpenSource Projekte werden in der Regel durch Firmen unterstützt bzw. sind dort federführend (oder stellen die Prgrammierer an wie Novell SuSE oder Redhat, aber auch IBM und ehemals SUN). Und wenn es Hobbyprogrammierer sind, arbeiten diese hauptberuflich im IT Feld und sind einschlägig vorbelastet. Oder welches Opensourceprojekt mit Relevanz ist ausschließlich in der Hand von Hobbyprogrammierern ohne Programmierkenntnissen? Ansonsten sind die schlimmsten "Programmierverbrechen in PHP und eben in Access/VB oder ähnlichem zu finden, da bei letzterem schnell mal eine "Anwendung" zusammegeklickt werden kann, die mit aus dem Netz zusammenkopiertem Code "wächst".
nur weil IBM drauf steht ist noch lange keine Qualität drin. Das PHP Bashing ist auch völlig fehl am Platz. Man kann gute Programme schreiben oder auch schlechte. Egal ob C#, Ruby Java oder eine andere Sprache. Am Ende ist es auch besser ein Programm mit schlechtem Code zu haben als gar keine Lösung. Ein Hobbyprogrammierer brauch auch jedes Highlight einer Sprache kennen.
Entscheidender ist doch was in den Firmen geschaffen wird, und da ist nicht BigBlue gemeint. IBM ist wohl der größte einzelanbieter. Die Masse der Codezeilen von kleinen IT-Firmen ist aber weitaus größer. IBM & Co sind an den dicken Projekten dran, mit den kleinen Fachanwendungen haben die überhaupt nichts am Hut. Wie toll der Code der Profis ist bekommt man auch immer mal mit bei gewissen Problemen bei der Telekom wenn bei T-Systems mal wieder gepatzt wurde.
> Das PHP Bashing ist auch völlig fehl am Platz. Man kann gute
> Programme schreiben oder auch schlechte. Egal ob C#, Ruby Java
> oder eine andere Sprache.
Dieses Gebet ist grober Unfug. Wenn das Werkzeug scheiße ist, kommt nunmal nix bei rum.
Dummes Gerede und sehr engstirnige Sichtweise.
Arbeit bedeuten nicht automatisch Wohlstand.
Wir könnten ja als Beispiel jede Software immer neu schreiben, wozu kopieren?
Dann hätten wir alle Arbeit, aber ginge es uns dann besser?
Nein!!
Kostenlose Software schafft Wohlstand weil nicht da Rad jedes Mal neu erfunden muss.
Der Arbeitslose kann stattdessen Becker werden.
Mehr Brötchen bedeuten niedrigere Preise.
Wunderbar. Du sagst also, dass alle studierten Informatiker aufmal eine Bäckerlehre machen sollen. Toll! Denk den Gedanken mal weiter:
Wenn alle Informatiker nur noch Bäcker werden können, wird auch keiner mehr Informatik studieren oder eine Ausbildung darin machen. Wenn es keine Infomartiker mehr gibt, dann programmieren nur noch Hobbyprogrammierer und Wannabes.
Wenn nur noch Hobbyprogrammierer und Wannabes programmieren, wird der Quellcode immer schlechter.
Wir wollen gar nicht wissen, was für Bäcker und andere Pfeifen für Microsoft entwickeln, du Unterbelichteter.
Wenn einem die Argumente Ausgehen wird man direkt mal Persönlich.
Typisch Fanboygehabe.
Bis mir die Argumente ausgehen, hast du immer noch keins gefunden.
Programmierer (z.B. in Form des Organisationsprogrammierers) ist ein Ausbildungsberuf mit IHK-Abschluß, Informatiker gibt es sowohl als Studiengang mit Diplom als auch als Ausbildungsberuf mit staatlicher Abschlußprüfung. Allerdings arbeiten meist nur die nicht sonderlich erfolgreichen Diplominformatiker als Programmierer, ähnlich wie nicht erfolgreiche Maschinenbauingenieure der Fachrichtung Fahrzeiugtechni als KFZ-Mechanier oder Diplomingenieure der Nachrichtentechnik als Elektroinstallature. Natürlich liest es sich imer toll wenn da ein Dipl.Inf. oder Dipl.Ing. vor dem Namen auf der Visitenkarte steht aber wenn man genau nachdenkt weiss man daß da jemand an seinem erlernten Beruf vorbei arbeitet und sicherlich nicht so konzentriert und motiviert ans Werk geht wie derjenige, der die korrekte Ausbildung dazu hat. Und genau das sind ja sooft Ursache von Datenverlusten und Systemabstürzen proprietärer (!) Software da dort im Gegensatz zu OpenSource Projekten eben sehr sehr oft unmotiviert gearbeitet wird und entsprechend oft Schluderei zu finden ist wenn man mal hinter die Kulissen guckt! Den Informatiker sollte man eher an das setzen was er kann: Das erfassen und abstrahieren von Problemstellungen inklusive der Entwicklung von Lösungsschemata die DANN von GELERNTEN Programmieren umgesetzt werden oder zusammen mit Kollegen der Hardwareentwiclklung (Dipl.Ing. NT oder ET) in Hardware geplant und dann von Hardwarefertigern (z.B. Systemelektronikern oder Kommunikationselektronikern mit IHK-Abschluß) als Ergebnis umgesetzt werden.
Nur, um sowas dann auch in einer Verwaltung umzusetzen muss man sich eben Fachleute die objektiv erstmal die Problemstellung analysieren heranholen und keine Lobbyisten die als Marketingexperten auf Biegen und Brechen IHR Produkt verkaufen wollen auch wenns gar nicht zum Problem passt (siehe z.B. die netten Toll-Collect Pannen mit den OnBUs)......in NL wurde sowas mal wieder erst realisiert als es zu spät war und die Verstrickungen sich eben nicht mehr wirklich lösen ließen.
Lobbyisten sei dank halt mal wieder ;).....
Eines sollten diese Leute in den Entscheiderstellen endlich mal kapieren: Das Beste Programm ist das, daß das Problem vernünftig lösen hilft und nicht immer das Programm, daß die Kassen der Entscheider und der Lieblingsfoirmen füllt.
OpenSource heißt zunächst mal Quell offen, nicht umsonst.
Tja, das Problem kenn ich. Wir habe hier auch versucht OpenOffice einzuführen, sind aber letzendlich an Abhängigkeiten gescheitert.
So kommt unter Anderem SAP deutlich besser mit MS-Office zurecht. Daher werden wir demnächst alles auf MS-Office 2010 umstellen. Und es wird dann hier auch keine Ausnahmen geben. Daher muß ich mein OpenOffice auch deinstallieren.
Tja, und weil MS-Office besser mit SAP macht usw usf bleibt ihr in einer tollen Abhängigkeit, die allen beteiligten nutzt, nur euch nicht
... anders kann ich es mir nicht erklären, warum diverse Behörden und Kommunen nicht das Geld in die Hand nehmen und sich zusammentun, um
a) Notwendigkeiten von Spezialanwendungen zu sondieren
b) Arbeitsabläufe behördenübergreifend zu standardisieren
c) freie Anwendungen für diese Abläufe zu entwickeln
Freie Software lebt vom Mitmachen, und das Geld des Steuerzahlers sollte nicht ohne Not für Software ausgegeben werden, von der er selbst nichts hat (sprich: proprietäre Lösungen). Bedauerlicherweise sehen viele Entscheider Freie Software als Basar für kostenlose Anwendungen.
lg
Erik
Also wir stellten alles auf Linux Desktop um und com rdesktop - Terminal Server konnten alle weiterarbeiten. Dann fingen wir an die Software zu analisieren. Programmierten via Php-Apache die Software und loeschten die Excelabhaengigen Tabellen. So braucht man den Browser und fuer die Exoten den rdesktop! Active X via rdesktop usw. Alles laeuft geschmiert! Und es wird jeden Tag weniger! Eines Tages vielleicht koennen wir dann den Windows Terminal Server formatieren!