Abo
  1. Foren
  2. Kommentare
  3. OpenSource
  4. Alle Kommentare zum Artikel
  5. › Open Source: Die Community…

Nur wenn Entwickler und Nutzer dieselben sind

  1. Thema

Neues Thema Ansicht wechseln


  1. Nur wenn Entwickler und Nutzer dieselben sind

    Autor: schap23 30.12.17 - 12:41

    OpenSource funktioniert dann, wenn die Nutzer der Software gleichzeitig auch Entwickler sind, die Fehler selbstständig beheben und fehlende Features ergänzen. Deshalb funktioniert das ziemlich gut bei Entwicklungswerkzeugen, Libraries etc.. Es funktioniert aber nicht, wenn eine Menge Leute nur kostenlose Software suchen, die Entwickler aber keinen Bezug zu ihren Nutzern haben.

    Wenn man das Scheitern von Limux beurteilen will, muß man doch auch mal fragen, was dieses Projekt der Community gegeben hat. Wenn die Voraussetzung nur war, Lizenzgebühren einzusparen, dann liegt da ein Gedankenfehler vor. In so einem Fall müßten Entwickler vor Ort mit den Nutzer kommunizieren und die eingesetzte Software fortentwickeln. Wenn alle nur Schmarotzern, ist der OpenSource-Gedanke am Ende.

  2. Re: Nur wenn Entwickler und Nutzer dieselben sind

    Autor: Dadie 30.12.17 - 14:03

    schap23 schrieb:
    --------------------------------------------------------------------------------
    > [..]
    > Wenn man das Scheitern von Limux beurteilen will, muß man doch auch mal
    > fragen, was dieses Projekt der Community gegeben hat. Wenn die
    > Voraussetzung nur war, Lizenzgebühren einzusparen, dann liegt da ein
    > Gedankenfehler vor. In so einem Fall müßten Entwickler vor Ort mit den
    > Nutzer kommunizieren und die eingesetzte Software fortentwickeln. Wenn alle
    > nur Schmarotzern, ist der OpenSource-Gedanke am Ende.

    AFAIK ist aber genau das passiert. Es gab auf einem C3 dazu diverse Talks. Die sind wirklich durch die unterschiedlichsten Abteilungen gegangen und haben mit den Nutzern gesprochen, geklärt wie der rechtliche Rahmen aussieht und haben konstant nach Verbesserungen gefragt. Es gab sogar diverse Hotlines und regelmäßige Befragungen um Probleme möglichst schnell aus dem Weg zu räumen.

    Eines der vielen Probleme war jedoch, dass es vor Limux keine zentrale Verwaltung gab geschweigende eine einheitliche IT oder gar ein IT Konzept. Jede Abteilung hatte ihren eigenen designierten "Administrator" und ihren eigenen Wildwuchs.

    Weswegen ein Großteil des Limux Projekts gar nicht war die Clients mit Linux und OSS auszustatten, sondern ein ordentliches IT-Konzept zu erarbeiten und umzusetzen. Und bei diesem IT-Konzept hat man eben auch auf Dinge wie Datenschutz und Sicherheit geachtet. Ein Umstand der später zu vielen Problemen führt, etwa weil Mitarbeiter sich beschwerten, dass sie nicht einfach einen USB-Stick in ihren Computer packen können oder nicht selber Software nachinstallieren können.

    Natürlich gab es Schulungen und Fortbildung, den Mitarbeitern wurde erklärt wie, was, wieso und weswegen, aber die haben halt im Zweifel wenig Verständnis dafür, wenn ihr System aus "dummen" Gründen wie Sicherheit oder Datenschutz plötzlich nicht mehr so bedient werden kann wie vorher.

    Da Limux im Prinzip Baustellen an allen Enden hatte und die IT irgendwie laufen musste wurden häufig nur die dringlichsten Sachen sofort gefixt und man akzeptierte an vielen Stellen Unannehmlichkeiten für die Nutzer weil es schlicht zu viel auf einmal war.

    Hinzu kamen die ganzen speziellen Macros und MS Office Dokumente die alle von MS Office nach OpenOffice portiert werden mussten. Eine Portierung die übrigens abgeschlossen ist. Und nun mit dem Wechsel zu Microsoft und MS Office müssen dieselben portierten Macros und Dokumente erneut portiert werden, da sie sich großteils natürlich verändert haben im Vergleich zu den alten Macros und MS Office Dokumenten.

    Zusätzlich waren diverse Abteilungen von Programmen abhängig die nur auf Microsoft Windows liefen weswegen zusätzlich Windows PCs bzw. VMs bereit gestellt werden mussten.

    Würde man wirklich DEN Grund nennen wollen wäre er wohl eher, dass das Projekt zu ambitioniert war, zu viel direkt perfekt machen wollten, zu viel auf einmal ändern wollte und nicht bedachte, dass Menschen Veränderungen hassen und insbesondere diffuse Dinge wie Datenschutz oder Sicherheit immer (wenn möglich) der eigenen Bequemlichkeit unterordnen.

  3. Re: Nur wenn Entwickler und Nutzer dieselben sind

    Autor: Anonymer Nutzer 30.12.17 - 15:28

    schap23 schrieb:
    --------------------------------------------------------------------------------
    > OpenSource funktioniert dann, wenn die Nutzer der Software gleichzeitig
    > auch Entwickler sind, die Fehler selbstständig beheben und fehlende
    > Features ergänzen. Deshalb funktioniert das ziemlich gut bei
    > Entwicklungswerkzeugen, Libraries etc.. Es funktioniert aber nicht, wenn
    > eine Menge Leute nur kostenlose Software suchen, die Entwickler aber keinen
    > Bezug zu ihren Nutzern haben.
    >
    > Wenn man das Scheitern von Limux beurteilen will, muß man doch auch mal
    > fragen, was dieses Projekt der Community gegeben hat. Wenn die
    > Voraussetzung nur war, Lizenzgebühren einzusparen, dann liegt da ein
    > Gedankenfehler vor. In so einem Fall müßten Entwickler vor Ort mit den
    > Nutzer kommunizieren und die eingesetzte Software fortentwickeln. Wenn alle
    > nur Schmarotzern, ist der OpenSource-Gedanke am Ende.

    Das kann so nicht funktionieren.
    Ich benutze selbst R (allerdings nach Möglichkeit ohne Bibliotheken um eine Langzeitzuverlässigkeit in einem Skripten zu haben).
    Kenne ich den R source code? Nein. Habe ich Interesse daran? Eigentlich nicht. Habe ich Zeit mich in den einzuarbeiten? Definitiv nicht.

    Das ganze kann man ewig fortführen...
    Es ist schon gute 5-6 Jahre her dass ich mir mal NWChem angeschaut habe - "quantumn chenistry". Das will man eigentlich als Nutzer benutzen und nicht entwickeln - und dann ist da noch viel in Fortran geschrieben...

    Entwickler und Nuzter werden nie die gleichen sein.
    Man kann sich um Bugreports von Nutzern bemühen, wobei dann immer die Frage ist wie die Kommunikation abläuft und wie umfangreich das ist. (Erwarten dass Nutzer Entwicklungsheader installieren und Debug Traces einsenden ist von dem Otto-Normalnutzer etwas viel verlangt.)

  4. Re: Nur wenn Entwickler und Nutzer dieselben sind

    Autor: deutscher_michel 30.12.17 - 16:12

    Das mit den Makros ist aber keine Problem von OpenOffice oder LibreOffice sondern die Monopolstellung von Microsoft mit ihren Properitären Formanten, die nicht mal zu den eigenen Vorgängerversionen kompatibel sind.
    Über die Jahre hat man sich so in eine Abhängigkeit begeben aus der man nun nicht mehr raus kommt (ist zumindest bei uns so). Wir würden nichts lieber tun als die Abhängigkeit zu Microsoft beenden, aber das ist mit dermaßen hohen Aufwänden verbunden, dass es günstiger ist jedes Jahr Millionen an Microsoft zu zahlen..

  5. Re: Nur wenn Entwickler und Nutzer dieselben sind

    Autor: Potrimpo 31.12.17 - 17:28

    Ich finde Deine Aussagen durchaus interessant, muss allerdings auch noch nachhaken.

    Vorab: Ich bin mit ca. 40 Mitarbeitern (MA) - nicht IT, sondern Verwaltungsangestellte - befreundet bzw. bekannt. Ein Großteil aus dem KVR (Kreisverwaltungsreferat), teilweise aber auch aus den Bürgerbüros.

    Du schreibst:

    >wirklich durch die unterschiedlichsten Abteilungen gegangen und haben mit den Nutzern gesprochen

    Von den 40 MA, und auch deren Bekannten, ist nicht mit einem einzigen gesprochen worden, lediglich mit einigen (wenigen) Vorgesetzten.

    > Ein Umstand der später zu vielen Problemen führt, etwa weil Mitarbeiter sich beschwerten, dass sie nicht einfach einen USB-Stick in ihren Computer packen können oder nicht selber Software nachinstallieren können.

    Von den mir bekannten MA -und auch deren Bekannten - hat nicht ein einziger diesen Wunsch geäußert. Kolportiert wurden derartige Wünsche aus dem Bürgermeister-Büro, nicht aus den Bürger-Büros.

    >Eine Portierung die übrigens abgeschlossen ist.

    Lt. Aussagen der betroffenen MA nicht wirklich vollständig, insbesondere aber nicht mit vollständiger Funktionalität. U.a. geht es wohl um Formulare, die früher direkte Konnektivität zur DB hatten, jetzt aber händisch einmal ins Formular, einmal in die die DB einzugeben sind.

    Zudem hat es - das muss nicht mit LiMux zusammenhängen - seit Einführung von LiMux 2003 massiv Probleme in den Antwortzeiten gegeben, teilweise bis zu Minuten für Bildwechsel.

    Hier fühlten sich die MA regelrecht verhohnepipelt, als in der Öffentlichkeit und vom Projekt mitgeteilt wurde, dass alles super läuft.

    PS: Es folgen noch Ergänzungen - ist aber heut an Silvester nicht so einfach.



    1 mal bearbeitet, zuletzt am 31.12.17 17:32 durch Potrimpo.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. OMICRON electronics GmbH, Klaus (Österreich)
  2. UmweltBank AG, Nürnberg
  3. Hochschule für Technik Stuttgart University of Applied Sciences, Stuttgart
  4. Endress+Hauser Conducta GmbH+Co. KG, Gerlingen (bei Stuttgart)

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 149,99€ (Release noch nicht bekannt)
  2. 2,99€
  3. 4,99€
  4. (-25%) 44,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Google Maps: Karten brauchen Menschen statt Maschinen
Google Maps
Karten brauchen Menschen statt Maschinen

Wenn Karten nicht mehr von Menschen, sondern allein von Maschinen erstellt werden, erfinden diese U-Bahn-Linien, Hochhäuser im Nationalpark und unmögliche Routen. Ein kurze Liste zu den Grenzen der Automatisierung.
Von Sebastian Grüner

  1. Kartendienst Google bringt AR-Navigation und Reiseinformationen in Maps
  2. Maps Duckduckgo mit Kartendienst von Apple
  3. Google Maps zeigt Bikesharing in Berlin, Hamburg, Wien und Zürich

Mobile-Games-Auslese: Verdrehte Räume und verrückte Zombies für unterwegs
Mobile-Games-Auslese
Verdrehte Räume und verrückte Zombies für unterwegs

Ein zauberhaftes Denksportspiel wie Rooms, ansteckende Zombies in Infectonator 3 Apocalypse und Sky - Children of the Light, das neue Werk der Journey-Entwickler: Für die Urlaubszeit hat Golem.de besonders schöne und vielfälige Mobile Games gefunden!
Eine Rezension von Rainer Sigl

  1. Dr. Mario World im Test Spielspaß für Privatpatienten
  2. Mobile-Games-Auslese Ein Wunderjunge und dreimal kostenloser Mobilspaß
  3. Mobile-Games-Auslese Magischer Dieb trifft mogelnden Doktor

Ryzen 5 3400G und Ryzen 3 3200G im Test: Picasso passt
Ryzen 5 3400G und Ryzen 3 3200G im Test
Picasso passt

Vier Zen-CPU-Kerne plus integrierte Vega-Grafikeinheit: Der Ryzen 5 3400G und der Ryzen 3 3200G sind zwar im Prinzip nur höher getaktete Chips, in ihrem Segment aber weiterhin konkurrenzlos. Das schnellere Modell hat jedoch trotz verlötetem Extra für Übertakter ein Preisproblem.
Ein Test von Marc Sauter

  1. Agesa 1003abb Viele ältere Platinen erhalten aktuelles UEFI für Ryzen 3000
  2. Ryzen 3000 Agesa 1003abb behebt RDRAND- und PCIe-Gen4-Bug
  3. Ryzen 5 3600(X) im Test Sechser-Pasch von AMD

  1. Urheberrecht: Youtuber sollen bei Snippets kein Geld mehr verlieren
    Urheberrecht
    Youtuber sollen bei Snippets kein Geld mehr verlieren

    Bisher konnten Urheber die Einnahmen von Youtubern komplett an sich ziehen, auch wenn diese nur ganz kurze Teile der eigenen Werke übernahmen. Das soll künftig auf Youtube nicht mehr möglich sein.

  2. Einrichtungskonzern: Ikea startet eigenen Geschäftsbereich für Smart Home
    Einrichtungskonzern
    Ikea startet eigenen Geschäftsbereich für Smart Home

    Der Einrichtungskonzern Ikea will mit einem eigenen Geschäftsbereich seine Smart-Home-Produkte voranbringen. Das Unternehmen will damit mehr bieten als nur gewöhnliche Möbel.

  3. Zoncolan: Facebook testet 100 Millionen Zeilen Code in 30 Minuten
    Zoncolan
    Facebook testet 100 Millionen Zeilen Code in 30 Minuten

    Das Entwicklerteam von Facebook hat ein eigenes Werkzeug zur statischen Code-Analyse erstellt und stellt nun erstmals Details dazu vor. Das Projekt habe Tausende Sicherheitslücken verhindert.


  1. 14:34

  2. 13:28

  3. 12:27

  4. 11:33

  5. 09:01

  6. 14:28

  7. 13:20

  8. 12:29