Um etwas Licht in den nebulösen Titel zu bringen, hier der "Fall".
(habe das ganze noch nicht voll durchdacht erfasst, also ggf. etwas unsortiert das ganze. U.a. desshalb starte ich den Thread ja auch)
Es geht um die sog. Blower Door Messungen (die macht ein Bekannter von mir seit einigen Jahren). Stand der Dinge ist momentan: Es gibt verschiedene Hard- und Software (nebst einem Namensstreit um Blower-Door).
Die Sache ist zumeist wie folgt aufgebaut:
-Ventilator mit Druckdifferenzmessdose
-"Black Box" Hardware als Schnittstelle zum Messcomputer
-Messcomputer (Windows mit Software vom Hersteller)
-Excel Tabelle zu Auswertung/Dokumentation der Messergebnisse (die liest eine ASCII Datei ein, die vom Messprogramm erzeugt wird)
Schritt 1:
Es gibt wohl durchaus Anfragen zumindest für den letzten Schritt nicht auf Win Programme angewiesen zu sein. Dazu könnte man sicher das Textfile und die Excell Tabelle untersuchen und das ganze als so ändern, dass am Ende eine .ods Datei hat. Meine Idee wäre ein Perl Scriot, das die ASCII Datei in ods umwandet (wäre dann auch gleich OS- unabhängig)
(da stellen sich natürlich rechtliche Fragen, was Urheberrechte auf die orig. Excel Tabelle angeht)
Schritt 2:
Die DIN zu dem Messverfahren impliziert eine Nachvollzeihbarkeit des ganzen Verfahrens, was ja streng genommen nur möglich ist wenn auch der code von der Messdose bis zum Output des Messprogramms open source seien müsste.
"Wunschziel":
eine möglichst modulare Sammlung Software, mit aller derzeit und zukünftig verfügbaren Hardware verwendbar ist. Und das ganze auch noch Plattformunabhängig.
Fragen/Probleme/Stolpersteine/Ideen: (unsortiert)
-wie überzeugt man die Nutzer und Hersteller von dem Nutzen und dem Bedarf diesen Weg zu beschreiten, jenseits der juristischen "Notwendigkeit"?
-gibt es vergleichbare Fälle (aus anderen Branchen)?
-wo findet man Tips zur Vorgehensweise (Ist die FSFE da ein Hilfe/ interessiert)?
-Sucht man sich einen Fachverband zu Finanzierung (FLiB?
-Wie argumentiert man bei den Herstellern, die eigene Softwareentwicklung "aufzugeben"/ umzuwandeln, bzw. "Wieso sollte ich Geld für SW Entwickler ausgeben und dann die SW "verschenken"?
-einen Juristen in dem Umfeld habe ich schon kennen gelernt, der zumindest die Vorteile ud die "Notwendigkeit" in Bezug auf die DIN begriffen hat und auch nachvollziehbar darstellen kann.
-ein Hersteller hat schon mal angeboten Geld zu spenden, um den Namensrechtsstreit zu beenden. Da wäre ja die Idee das Namensrecht auch das Messverfahren an sich zu übertragen (quasi der eine gibt sein Namensrecht auf, der andere spendet geld, um die Sache ins Rollen zu bringen). Gibts für soetwas erfolgreiche Beispiele?
-als ersten Schritt dachte ich zunächst an das Perl script für den"letzten" Ausfbereitungschritt.
Soweit erstmal. Ideen, Kritik, Anmerkungen etc. sehr willkommen..
Messsoftware von proprietär zu GPL. Argumente/Vorgehen?
- Natureshadow
- Beiträge: 2157
- Registriert: 11.08.2007 22:45:28
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Radevormwald
-
Kontaktdaten:
Re: Messsoftware von proprietär zu GPL. Argumente/Vorgehen?
Hallo,
einmal kurz grundlegend:
Open Source != verschenken!
-nik
einmal kurz grundlegend:
Open Source != verschenken!
-nik
Linux Professional Institute Certification Level 2
Warum bist du immer so gehässig? | FAQ (aka "Mein Sound ist kaputt!")
Meine DF.de-Stalker: Cae und TRex - I <3 you!
Warum bist du immer so gehässig? | FAQ (aka "Mein Sound ist kaputt!")
Meine DF.de-Stalker: Cae und TRex - I <3 you!
Re: Messsoftware von proprietär zu GPL. Argumente/Vorgehen?
Ich denke an der Überzeugung wird es scheitern. Die Leute setzen lieber proprietäre, nicht nachvollziehbare, evtl. verseuchte Software mit einem Knebelvertrag ein als nachvollziehbar strukturiert zu arbeiten.
Wenn ich es richtig verstanden habe besteht die Berechnung aus einem Excel-Sheet. Die Frage ist erst einmal wer die Rechte daran hat und ob man die bekommen kann. Wenn die Berechnung wirklich trivial mit Excel-Funktionen durchgeführt wird auf Basis einer CSV- oder Sonstwas-Datei würde ich unter Linux das ganze grafische Zeug erst mal weglassen. Warum den Wahnsinn von Excel wiederholen?
Es ist viel einfacher z.B. mit Perl (gibt es auch für Windows / Achtung verschiedene Versionen) die Daten kurz zu verarbeiten, bisschen Hash-Funktionen, Mathematik oder keine Ahnung was man sonst so braucht anzuwenden und am Ende eine z.B. CSV-Datei rausfallen zu lassen, die dann egal ob Excel, Calc oder sonstwie grafisch dargestellt wird.
Ach ja. Die Nachvollziehbarkeit ist mit der neuen Lösung bestimmt besser gegeben als mit Excel. Leider können die Leute, die Nachvollziehbarkeit bewerten selbst heute nicht mehr programmieren und sehen in bunten Bildern eine Nachvollziehbarkeit. Aber wer Lust hat kann ja mal als Steigerung der Nachvollziehbarkeit nach "Programmverifikation" im Internet suchen, um die Korrektheit der Anwendung zu beweisen. Ich denke MS kann diese für sein Produkt Excel nicht beweisen. Die Korrektheit eines kleinen Perl-Scriptes kann hingegen für alle Ein- und Ausgabewerte evtl. noch bewiesen werden. Wobei natürlich auch die Korrektheit von Perl schwer nachzuweisen wäre.
Ich bin enttäuscht, wie man in so einem Umfeld so stümperhaft arbeiten kann. Mit Wissenschaft hat das aber wohl nichts zu tun.
Wenn ich es richtig verstanden habe besteht die Berechnung aus einem Excel-Sheet. Die Frage ist erst einmal wer die Rechte daran hat und ob man die bekommen kann. Wenn die Berechnung wirklich trivial mit Excel-Funktionen durchgeführt wird auf Basis einer CSV- oder Sonstwas-Datei würde ich unter Linux das ganze grafische Zeug erst mal weglassen. Warum den Wahnsinn von Excel wiederholen?
Es ist viel einfacher z.B. mit Perl (gibt es auch für Windows / Achtung verschiedene Versionen) die Daten kurz zu verarbeiten, bisschen Hash-Funktionen, Mathematik oder keine Ahnung was man sonst so braucht anzuwenden und am Ende eine z.B. CSV-Datei rausfallen zu lassen, die dann egal ob Excel, Calc oder sonstwie grafisch dargestellt wird.
Ach ja. Die Nachvollziehbarkeit ist mit der neuen Lösung bestimmt besser gegeben als mit Excel. Leider können die Leute, die Nachvollziehbarkeit bewerten selbst heute nicht mehr programmieren und sehen in bunten Bildern eine Nachvollziehbarkeit. Aber wer Lust hat kann ja mal als Steigerung der Nachvollziehbarkeit nach "Programmverifikation" im Internet suchen, um die Korrektheit der Anwendung zu beweisen. Ich denke MS kann diese für sein Produkt Excel nicht beweisen. Die Korrektheit eines kleinen Perl-Scriptes kann hingegen für alle Ein- und Ausgabewerte evtl. noch bewiesen werden. Wobei natürlich auch die Korrektheit von Perl schwer nachzuweisen wäre.
Ich bin enttäuscht, wie man in so einem Umfeld so stümperhaft arbeiten kann. Mit Wissenschaft hat das aber wohl nichts zu tun.
Re: Messsoftware von proprietär zu GPL. Argumente/Vorgehen?
Ich bzw. (bzw. mein Arbeitgeber ist) teils in einer ähnlichen Situation:
Wir betreiben Messgeräte eines Drittanbieters die Daten ausspucken welche erstmal durch ein Windows-Programm müssen bevor wir sie mit unserer auf Linux laufenden Software verarbeiten können. Wir haben dabei weder die Kapazitäten einen Ersatz für die Drittanbietersoftware zu schreiben, noch eigene Messgeräte zu entwickeln.
Ich bin bei uns der einzige dem wirklich FLOSS am Herzen liegt. Dem Rest reicht kostenlos und unixoid.
Meiner Erfahrung nach lassen sich in so einer Umgebung Systeme nur migrieren wenn das FLOSS-System greifbare Vorteile bei der Arbeitsbewältigung bringt (schneller, besser konfigurierbar, kostengünstiger, etc.). Mit ideologischen Überlegungen, und seien sie noch so klein, kommt man hier kein Stück weiter. Alles was du also mit dem L in FLOSS begründen würdest brauchst du gar nicht anführen.
Bei uns ist es so dass wir auf weitere Dritthersteller ähnlicher Messgeräte zurückgreifen können, die auch nativ auf Linux lauffähige Software anbieten, teils sogar mit Quellcode unter NDA was uns erlaubt die Software bei Bedarf anzupassen. Das Problem ist, dass je nach Anwendungsfall die Geräte des Anbieters mit der Windows-only-Software die besten Messergebnisse liefern. Wir machen es daher so dass wir wo möglich auf Hersteller mit Linux-Clients setzen und den Windows-Anbieter nur nutzen wenn nötig. Bei Geräteausschreibungen für Projekte schreien wir explizit eine Linux-Software in die Anforderungen und ein Gerätehersteller muss schon ziemlich überzeugende Argumente die Qualität seiner Hardware betreffend haben damit wir davon abrücken.
Was dein Szenario angeht sehe ich das Hauptproblem in der Black-Box-Hardware. Wenn du wirklich eine offene Kette von vorne bis hinten haben willst musst du hier ansetzen:
- Gibt es alternative Hersteller die Linux-Software anbieten? Falls ja, was kostet die Umstellung? Rechnet sich das für euch unabhängig von Freiheitsgedanken?
- Ist die Hardware wirklich eine Black Box oder habt ihr Spezifikationen die genau beschreiben was darin passiert? Falls Letzteres, habt ihr die Ressourcen Schritt für Schritt nachzuvollziehen was in der Kiste passiert (z.B. durch Nachbau oder Simulation des Originalgeräts)? Wenn ihr die Ressourcen nicht habt ist die Frage nach der Black Box ohnehin rein akademisch, denn auch eine offene Kiste könntet ihr nie überprüfen.
- Falls nicht die Kiste selbst, könnt ihr die Windows-Software austauschen (durch eigene oder fremde Software).
Die Excel-Tabelle sehe ich als juristischer Laie nicht als Problem. Erstens liest sie sowieso ASCII-Daten ein die beliebig lesbar sind und zweitens gehören die Daten für gewöhnlich euch wenn ihr nicht mit jemand anderem (z.B. dem Gerätehersteller) abweichende Verträge habt.
Wir betreiben Messgeräte eines Drittanbieters die Daten ausspucken welche erstmal durch ein Windows-Programm müssen bevor wir sie mit unserer auf Linux laufenden Software verarbeiten können. Wir haben dabei weder die Kapazitäten einen Ersatz für die Drittanbietersoftware zu schreiben, noch eigene Messgeräte zu entwickeln.
Ich bin bei uns der einzige dem wirklich FLOSS am Herzen liegt. Dem Rest reicht kostenlos und unixoid.
Meiner Erfahrung nach lassen sich in so einer Umgebung Systeme nur migrieren wenn das FLOSS-System greifbare Vorteile bei der Arbeitsbewältigung bringt (schneller, besser konfigurierbar, kostengünstiger, etc.). Mit ideologischen Überlegungen, und seien sie noch so klein, kommt man hier kein Stück weiter. Alles was du also mit dem L in FLOSS begründen würdest brauchst du gar nicht anführen.
Bei uns ist es so dass wir auf weitere Dritthersteller ähnlicher Messgeräte zurückgreifen können, die auch nativ auf Linux lauffähige Software anbieten, teils sogar mit Quellcode unter NDA was uns erlaubt die Software bei Bedarf anzupassen. Das Problem ist, dass je nach Anwendungsfall die Geräte des Anbieters mit der Windows-only-Software die besten Messergebnisse liefern. Wir machen es daher so dass wir wo möglich auf Hersteller mit Linux-Clients setzen und den Windows-Anbieter nur nutzen wenn nötig. Bei Geräteausschreibungen für Projekte schreien wir explizit eine Linux-Software in die Anforderungen und ein Gerätehersteller muss schon ziemlich überzeugende Argumente die Qualität seiner Hardware betreffend haben damit wir davon abrücken.
Was dein Szenario angeht sehe ich das Hauptproblem in der Black-Box-Hardware. Wenn du wirklich eine offene Kette von vorne bis hinten haben willst musst du hier ansetzen:
- Gibt es alternative Hersteller die Linux-Software anbieten? Falls ja, was kostet die Umstellung? Rechnet sich das für euch unabhängig von Freiheitsgedanken?
- Ist die Hardware wirklich eine Black Box oder habt ihr Spezifikationen die genau beschreiben was darin passiert? Falls Letzteres, habt ihr die Ressourcen Schritt für Schritt nachzuvollziehen was in der Kiste passiert (z.B. durch Nachbau oder Simulation des Originalgeräts)? Wenn ihr die Ressourcen nicht habt ist die Frage nach der Black Box ohnehin rein akademisch, denn auch eine offene Kiste könntet ihr nie überprüfen.
- Falls nicht die Kiste selbst, könnt ihr die Windows-Software austauschen (durch eigene oder fremde Software).
Die Excel-Tabelle sehe ich als juristischer Laie nicht als Problem. Erstens liest sie sowieso ASCII-Daten ein die beliebig lesbar sind und zweitens gehören die Daten für gewöhnlich euch wenn ihr nicht mit jemand anderem (z.B. dem Gerätehersteller) abweichende Verträge habt.
Re: Messsoftware von proprietär zu GPL. Argumente/Vorgehen?
Der Vortrag [0] beim Linuxtag ging auf Argumente fuer Freie Software (Entwicklung) aus Unternehmenssicht ein. Du kannst Herrn Loxen ja mal anschreiben.mclien hat geschrieben: -wie überzeugt man die Nutzer und Hersteller von dem Nutzen und dem Bedarf diesen Weg zu beschreiten, jenseits der juristischen "Notwendigkeit"?
-gibt es vergleichbare Fälle (aus anderen Branchen)?
[...]
-Wie argumentiert man bei den Herstellern, die eigene Softwareentwicklung "aufzugeben"/ umzuwandeln, bzw. "Wieso sollte ich Geld für SW Entwickler ausgeben und dann die SW "verschenken"?
[0] http://www.linuxtag.org/2012/de/program ... talkid=516
Einen funktionierenden Prototyp vorlegen zu koennen ist immer gut.mclien hat geschrieben: -als ersten Schritt dachte ich zunächst an das Perl script für den"letzten" Ausfbereitungschritt.
Grundsaetzlich glaube ich, dass es ganz wichtig ist, die konkreten Ziele und Befuerchtungen aller Parteien herauszufinden. Geht es also um Geld, um Abhaengigkeit, um Vertrauen, um Support, um Knowhow, usw.? Hierfuer aber nicht nur raten! Solange diese Ausgangsbasis unklar ist, wird so ein Projekt kaum Erfolg haben, glaube ich.
Use ed once in a while!