Ganz vorneweg, ich finde es nicht gut - gerade die Unverbindlichkeit was man seiner Hardware mitfügen muss um sie als 'open' für andere zu verschenken, machte es einfach was für die Gemeinschaft zu entwickeln. Jetzt soll da ein offizieller Standard, was sich 'open Hardware' nennen darf und was nicht herausgebracht werden. Der nennt sich DIN-Spec-3105. Da 'ne Selbstdarstellung und ein Bericht vom der heise Redaktion: https://www.din.de/resource/blob/721286/717bef668327b830d60d1530884b0385/broschuere-din-spec-3105-data.pdf https://www.heise.de/news/DIN-SPEC-3105-Normungsvorschlag-fuer-Open-Source-Hardware-4868528.html -- Mich stört: 1) Dassw ird im Ganzen zur reinen Produktionsvorbereitung für Dritthersteller. Ziel der Doku soll nicht mehr sein, zu erklären, was die Hardware tut und was sich der Open-Hardware Autor dabei gedacht hat, sondern die Kopie ohne grossen eigene Aufwand beim beliebigen Dritthersteller. 2) Die Überbetonung der community Bewertung als 'Richterurteil' zwischen gut und böse. Ja, die Community soll Vorschläge machen und Erfahrungen in der Nutzung als Feedback zurück geben. Aber eine Bewertung als 'Gutes oder Schlechtes Produkt' finde ich in der, auch von Neugier, Spiel- und Experimentier-lust getriebenen Open Hardware Gemeinschaft eher unangebracht. Manchmal baut man eben Sachen mit veralteten Vorgaben, um sie selbst kennenzulernen und möglichst breite Erfahrungen damit zu sammeln. Die Community dagegen ist eher genervt vom x. AVR-Taschenrechner oder y. RasPi-Fensterkippsteuerung. Da ist keine Bewertung die beste Bewertung. Ich ziehe da einen Vergleich zu den 'Kopfnoten', die auch weitgehend als 'pädagogischer Unfug' abgeschafft wurden.
:
Verschoben durch Moderator
Primatentrainer schrieb: > Jetzt soll da ein offizieller Standard, was sich 'open Hardware' nennen > darf und was nicht herausgebracht werden. Der nennt sich DIN-Spec-3105. Muss es für alles eine Norm geben? Ich warte noch auf die Norm, die einem Vorschreibt, wie man z.B.: Nudeln zu kochen hat. SCNR tr0ll
Primatentrainer schrieb: > Mich stört: > 1) Dassw ird im Ganzen zur reinen Produktionsvorbereitung für > Dritthersteller. Ziel der Doku soll nicht mehr sein, zu erklären, was > die Hardware tut und was sich der Open-Hardware Autor dabei gedacht hat, > sondern die Kopie ohne grossen eigene Aufwand beim beliebigen > Dritthersteller. Find ich einen durchaus beachtenswerten Punkt bei Hardware, die leicht vervielfältigt werden soll. Den Punkt, was das Ding dann eigentlich macht/machen soll, würd ich aber auch irgendwo niedergeschrieben haben wollen. Heise schreibt übrigens: > "Teil 1: Anforderungen an die technische Dokumentation" definiert grundlegende > Begriffe und klare Anforderungen an die technische Dokumentation. Klingt doch erstmal super? Das mit der Community-basierten Bewertung ist auch mMn noch nicht die Wucht, gerade bei Produkten, die nur im großen Stil eingesetzt werden.
:
Bearbeitet durch User
Ach Leute, ein paar Typen wollten unbedingt auch mal einen Standard machen. Das macht sich gut im Lebenslauf. Das Ding kommt auf den Haufen von tausenden, wenn nicht zehntausenden von Standards die kein Schwein interessiert. Vielleicht findet sich in einem Konzern ein Management-Depp der spezifiziert, dass nur DIN Open-Hardware in eigenen Produkten verwendet werden darf. Gratulation, ins eigenen Knie geschossen. Lasst sie doch.
Troll T. schrieb: > Ich warte noch auf die Norm, die einem Vorschreibt, wie man z.B.: Nudeln > zu kochen hat. Das ist doch schon lange in etlichen Normen festgehalten, die die verschiedensten Aspekte berücksichtigen: Konstruktion von Nudelkochern, deren Anforderungen und Prüfung, Unterscheidung zwischen elektrischem und gasbetriebenem Nudelkochen, Herstellung der Nudeln selbst, Hygieneanforderungen, Sensorische Prüfverfahren, Vorbereitung von Untersuchungsproben, usw.. Ich habe beim DIN auf Anhieb rund 70 Normen gefunden, von denen rund 30-40 zu berücksichtigen sind.
Hannes J. schrieb: > Ach Leute, ein paar Typen wollten unbedingt auch mal einen Standard > machen. Das macht sich gut im Lebenslauf. Bei einem meiner Kunden mit sehr vielen Konzernbeamten sah ich mal einen Satz Powerpointfolien, auf denen die wichtige Bedeutung des Querdenkens beschrieben wurde. Um dessen Potential nutzen zu können, wurden dann auch gleich die entsprechenden Unternehmensprozesse definiert und in einem Zehn-Punkte-Plan zusammengefasst. Der eigentliche frische Gedanke stand dabei nicht etwa an Punkt 1 der Liste, sondern erst an Punkt 8. Vorher waren noch die entsprechenden Genehmigungen einzuholen, wozu auch eine detaillierte Begründung gehörte, warum eine ebenso innotive Lösung nicht mit den etablierten Prozessen zu erzielen sei.
> Der Tod von ....
Kawatsch ...
Die Norm kann Dir total am Allerwertesten vorbei gehen, wenn Du einfach
lustig was baust und das anderen zur Verfügung stellst.
Was im Netz als Open Hardware rumgeistert ist oft nicht mehr als ein
hingerotzter Haufen Müll mit bescheidener Doku um den sich niemand mehr
kümmert.
Da muss man erstmal viele Stunden drin versenken um rauszufinden was es
tun sollte, was ich tun muss um das überhaupt zum laufen zu bekommen und
dann das das vollkommen unbenutzbar ist, weil das langweilig wurde als
es zu 80% fertig war um man dieses Chaos hätte aufräumen und
dokumentieren müssen.
Wenn nun aber irgendweine Internetgröße z.B. einen OH Server baut, ist
das ein wenig was anderes und da muss es irgendeine Norm geben damit
sich alle einig sind wie sowas aussehen soll.
Die Norm soll OH vorrantreiben indem es einen Qualitätsstandard dazu
gibt, statt dem heillosen durcheinander das wir bisher haben.
Man kann aber weiterhin absoluten jeden unausgegorenen Müll ins Netz
stellen. Da hat keiner was gegen.
Meiner Meinung nach ein guter Ansatz. So kann man bei OSH Projekten sofort sehen was sie an Daten bereitstellen, ohne alles durchzuarbeiten. Wer das nicht will, lässt den Verweis auf die Norm halt. Auch praktisch sehe ich, dass man auf die Norm verweisen könnte wenn man ein Kundenprojekt bearbeitet und abstimmen will welche Daten später übergeben werden.
D. C. schrieb: > Meiner Meinung nach ein guter Ansatz. Das sehe ich genauso. Allerdings frage ich ich mich auch, ob nicht noch andere Absichten dahinter stecken, insbesondere von etablierten Unternehmen, die durch OSH ihre Geschäftsmodelle bedroht sehen. Derzeit kann man sich ja auf rein freiwilliger Basis an die DIN SPEC 3105 halten. Irgendwann könnte in irgendeine EU-Verordnung o.ä. eine kleine Passage aufgenommen werden, die zunächst niemandem auffällt. Und plötzlich ist die Einhaltung der DIN SPEC 3105 für jeden verpflichtend, der auch nur das allerkleinste Schaltplanfitzelchen veröffentlichen will.
Nur der Vollstaendigkeit halber: https://gitlab.com/OSEGermany/OHS/ Dann kann man sich die Registrierung beim Beuth Verlag sparen.
Tobias B. schrieb: > Nur der Vollstaendigkeit halber: > > https://gitlab.com/OSEGermany/OHS/ > > Dann kann man sich die Registrierung beim Beuth Verlag sparen. Danke! Da der Link auf das pdf wenn man nicht durch git will. Allerdings können sich auf git auch neue Versionen befinden: https://osegermany.gitlab.io/OHS/DIN_SPEC_3105-2.pdf Beim kurzem überfliegen sticht ins Auge: -Alles in Englisch (und das für ne DIN) -Wer konform ist nach der Spec darf ein Logo verwenden das ausschaut wie das Corona Symbol -es wird eine permante URL und Kontakdaten des Veröffentlichers verlangt -sehr wenig Text, entweder ist beim PDF was fehlerhaft oder es wird alles mit viel Interpretionsspielraum 'definiert' -es wird ein Review-prozessverpflichtend aufgestellt -neben den Formalien werden keine technische Anforderungen (beispielsweise anforderungen an Schaltplan, Stückliste, ERC etc. gemacht). Daneben ist ein Knackpunkt der Begriff "Technology-specific Documentation criteria'. Ich verstehe darunter (PCB-) Herstellerspezifische Angaben. Die sollen wohl komplett vom Open Hardware Konstrukteur bereitgestellt werden. Und da beginnen die Probleme, da man Open Hardware in der Regel für einen Hersteller und mit einer Toolchain macht, bspw. Gerber aus Altium. Vor- und nachher spricht man intensiv mit dem Hersteller um auch etwas zu entwerfen was dieser fehlerfrei fertigen kann und trotzdem preiswert bleibt (Layer-Anzahl, Design rules für Keepouts,...). Nur weiss der Konstrukteur i.d.R. nicht, welchen Hersteller nun der Kunde auswählt und ob der mit den Daten für den Prototypenhersteller was anfangen kann. Mit diesem Standard gerät nun der Open Hardware Konstrukteur in die Pflicht, diese nachzuliefern sobald er das Logo verwendet. Damit zwingt man dem Konstrukteur aus seiner Sicht unnötige Arbeit auf, die auch der PCB-Hersteller leisten könnte oder wie bei Open Source Software angedacht beim Konstrukteur als bezahlte Anpassung in Auftrag gibt. Das Standards geeignet sind auch Open Source Projekte tiefgehend zu demotivieren hat sich kürzlich beim wiringpi projhect für den RasPi gezeigt: http://wiringpi.com/wiringpi-deprecated/ Zitat: "An individual by the name of DanielK who bleated at me for not releasing the sources for the Pi v4 version in a timely manner. I’d put up a .deb file designed for the correct dynamic linking, but Daniel pointed out Not to be a complete ass or anything, but technically the LGPL license REQUIRES you to make the sources available when it’s released. Great. Thanks, Dan. As I had limited capacity available at the time, I just felt that that was that. If I’m going to get emails like that for a little project then it’s not worth it anymore." Im Forum wurde das schon mal andiskutiert: Beitrag "Re: Echtzeit WiringPi"
Fpgakuechle K. schrieb: > Beim kurzem überfliegen sticht ins Auge: > > -Alles in Englisch (und das für ne DIN) Dann kann die ganze Welt drüber lachen. Ist doch gut. > -Wer konform ist nach der Spec darf ein Logo verwenden das ausschaut wie > das Corona Symbol Bei dem Logo haben sie sich das Open-Hardware Symbol der Community angeeignet. Guter Trick. > -sehr wenig Text, entweder ist beim PDF was fehlerhaft oder es wird > alles mit viel Interpretionsspielraum 'definiert' Nein, das stimmt schon. Das sind nur ein paar Seiten heiße Luft. Gesehen, gelacht, gelöscht. > Das Standards geeignet sind auch Open Source Projekte tiefgehend zu > demotivieren hat sich kürzlich beim wiringpi projhect für den RasPi > gezeigt: Ähm nein. Ein Standard und eine Lizenz sind was anderes. Ohne den Fall jetzt verfolgt zu haben, wenn ein Entwickler nicht in der Lage ist die Lizenzbedingungen einzuhalten unter denen er den Code lizenziert bekommen hat, wenn er also illegal handelt, dann soll er es in der Tat lassen statt die Drama-Queen zu geben.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.