Ich persönlich finde es sehr wichtig, sich selbst an Open Source Projekten zu beteiligen. Mit ist es wichtig etwas zurück zu geben. Auch wenn es nicht viel ist.
[gr] Finde ich eine schöne Einstellung - und so wichtig ist es auch gar nicht, ob das viel oder wenig ist, viel wichtiger ist IMHO, dass es halbwegs regelmäßig passiert. Denn dann addieren sich auch Kleinigkeiten im Lauf der Zeit auf 😊
Absolute Zustimmung. Bei größeren Firmen ist aber das Problem, dass du keine Möglichkeit hast zu spenden oder Quellcode beizusteuern, weil es schlechtweg keine Prozesse gibt bzw. Verboten ist und die es Entscheiden, wollen es schlichtweg nicht verstehen. Die einzige Möglichkeit ist Privat was beizusteuern… Daher die Lösung, alles in APGL veröffentlichen!
Sehr interessantes Video! Kann sein, dass es das schon gibt. Aber ich fände es ganz cool in einem Video evtl. mal einen Überblick über das Thema "OpenSource" zu geben. Also was es bedeutet und einen generellen Überblick darüber zu geben. Bei den im Video genannten Lizenzen beispielsweise verstehe ich größtenteils nicht genau was es damit auf sich hat. Auch die Fragen, wie gehe ich damit um, wenn ich OpenSource Frameworks oder Software unter bestimmten Lizenzen verwende bzw. in meiner eigenen Software integriere. Ich kann mir gut vorstellen, dass es einige andere da Draußen gibt, die OpenSource Persee auch erst mal nur als "kostenlose" Software kennen.
[gr] Vielen Dank für das Lob 😊 Prinzipiell haben wir in die Richtung schon einmal ein bisschen was gemacht: - Was ist Open-Source: ua-cam.com/video/KVdZakKQpno/v-deo.html - Lizenzen: GPL, MIT & Co.: ua-cam.com/video/65yaerkySWQ/v-deo.html - Warum Open-Source entwickeln: ua-cam.com/video/6V0fLIQAdbU/v-deo.html Aber, was wir noch nicht haben, ist, das alles mal in einem großen Überblick in einem Video zusammengefasst. Und das ist eine gute Idee, das würde gut in unser "X in 100 Minuten"-Format passen … ist auf die Liste aufgenommen 😊
Ich habe verstanden, dass ich dieses Paket gar nicht brauche, wenn ich alle Log-Nachrichten auf die Konsole ausgebe. Vor kurzem habe ich noch irgendwo gelesen, "das macht man nicht". Danke für Deinen Vortrag.
Super Video, vielen Dank! Ich arbeite in einer Entwicklungs-Fachstelle einer Bank. Wir setzen sehr viel Open-Source ein. Das zurückgeben ist aber oft schwierig. Wenn ein Entwickler Code veröffentlichen möchte, muss Er einen relativ aufwändigen und komplizierten Prozess anstossen. Zuerst müssen die Legal & Compliance Themen geklärt werden was meist eine individuelle Beurteilung eines oder mehreren Juristen bedarf. Danach muss der Entwickler den Code nach den Vorgaben prüfen und ggf. anpassen und wir als Fachstelle müssen diesen dann gegenchecken sowie bestätigen. Dieser Aufwand kann von vielen Teams gar nicht getragen werden und so findet das zurückgeben selten statt. Wir arbeiten hart dafür, dass sich dies ändert aber haben naturgemäss einigen Gegenwind. Mit zurückgeben verdient man vordergründig kein Geld und so müssen wir genau diese Argumente, welche Du erwähnt hast, gegenüber dem Business immer wieder aufzeigen. Aber da sind wir nun nach einigen Jahren auf jeden Fall einen grossen Schritt vorwärts gekommen aber sind aus meiner Sicht immer noch weit hinter einer befriedigenden Situation diesbezüglich.
Ich bin vor kurzem erst auf deinen Kanal gestoßen und bin wirklich sehr angetan. Im deutschsprachigen Raum habe ich bisher nichts vergleichbares gesehen. Danke dafür! Dein Wunsch zu weniger Komplexität und mehr hin zu "einfachen" Code teile ich leider nur bedingt. Prinzipiell wünscht sich das jeder Entwickler aber der Preis dafür ist in der Regel eine weitere Abstraktionsschicht. Das kann entweder eine Programmiersprache sein, ein Framework oder ähnliches. Aber dadurch verliert man auch viel an Kontrolle und wenn ein Problem auftritt, innerhalb dieser Schicht, dann ist man gezwungen sich in diese Komplexität einzuarbeiten. Also meines Erachtens verlagert sich das Problem nur bzw. Komplexität wird einem nur zum Teil abgenommen. Generell bin ich kein Freund mehr davon, für jedes kleine Problem direkt einen Framework, Library einzusetzen bzw. eine Dependency . Denn der Name ist wirklich Programm, eine weitere Abhängigkeit um die man sich kümmern muss.
[gr] Das stimmt - es ist nicht zielführend, für jede Kleinigkeit eine extra Dependency einzuführen, denn das geht zwar initial sehr einfach, zieht aber Maintenance nach sich, und das unterschätzt man gerne … und gerade kleine und einfache Sachen lassen sich dann doch auch relativ schnell selbst implementieren (wobei es da natürlich nicht mit dem reinen Code getan ist, so etwas will ja auch getestet, dokumentiert, … werden). Dass man die Komplexität nur verlagert, da bin ich ebenfalls bei Dir - der Punkt dabei ist aber, dass man die Komplexität weiter nach oben zieht, und sie deshalb besser zentralisieren kann. Ich habe lieber zehn einfache Komponenten und eine übergeordnete, die die komplexe Orchestration übernimmt, als zehn komplexe Komponenten, und eine einfache übergeordnete 😉 PS: Vielen, vielen Dank für das tolle Feedback und Dein Lob zu unserem Kanal, das freut mich sehr 😊
Hab den Channel gerade erst entdeckt und die ersten Videos gesehen, großartig! Qualitativ enorm hochwertiger Content, da können viele der richtig großen Channels einpacken. Großes Kompliment!
Die Aussage über den Einfluss der "Community" und von "Glaubensätzen" ist absolut richtig. Das hat mich an Java immer abgeschreckt. Das hat z.T. religiösen Charakter. Ds wird besonders schwierig, wenn man das auf Programmierer loslässt die aus komplett anderen Kulturkreisen kommen und auch wegen ihrer mangelhaften Ausbildung mit dem hohen Komplexitätsgrad überfordert sind und dann nicht mit der Sprache / Bibliothek programmieren sonder gegen sie. Allzu oft werden irgendwelche Dinge stumpf übernommen, weil man das halt so macht. Ich sehe das Problem mit der mangelnden Qualität und Sicherheit aber etwas anders. Das ist nicht auf Open Source beschränkt (da wird es aber transparent). Bei Closed Source sind die Mängel noch viel gravierender. Der Hauptgrund ist das a) blanke Gier herrscht und die wenigsten überhaupt bereit sind für Qualität und Sicherheit ausreichende Mittel aufzubringen b) auch eine schlechte unsichere Software allemal besser ist als es gar nicht oder von Hand zu machen und daher den SW EntwicklerInnen mehr oder minder alles aus der Hand gerissen wird. Features = GEIL, Warten = TEUER, QM = Pseudo Veranstaltung (konsistent Lügen ist billig). Und das prägt die Einstellung von vielen SW EntwicklerInnen. Wer schnell viele Features raushaut ist beim Auftraggeber beliebt. Und es macht allemal mehr Spaß komplizierte Konstrukte umzusetzen als sich mit schnödem QM zu beschäftigen. Zumal kreative Menschen auch ständig nach neuen Herausforderungen suchen. Interessant wäre ja mal die Idee das bestimmte Algorithmen und deren Umsetzung eigentlich Eigentum der Menschheit sein sollten, d.h. diese professionell und ordentliche bezahlt durch Institutionen definiert, entwickelt und publiziert werden, anstatt von Firm, Konsortien und Enthusiasten. Sowas gibt es z.T. schon (z.B. der AES Code) und es ist jedes Mal extrem erfolgreich.
Danke für das Video, Ich tu mir aber schwer damit die Komplexität von Log4J einfach mit dem Java-Umfeld abzutun. Ich glaube nicht dass diese Art von Komplexität ein Java-Problem ist, es ist ein Entwickler-Problem. Das Log4J Team hat selbst entschieden wie es sein Framework bauen will, keine Ausreden. Ich gebe Ihnen Recht was die Schuldfrage angeht. Fehler kann man nicht verhindern, aber man sollte daraus lernen. Und genau da sehe ich das Log4J-Team in der Verantwortung.
[gr] Es ist natürlich richtig, dass jede:r Entwickler:in selbst entscheidet, welche und vor allem wie viele Features man aufnimmt oder eben nicht - aber man trifft diese Entscheidung eben auch immer vor dem Hintergrund einer bestimmten Kultur und im Rahmen eines bestimmten Ökosystems. Und weil Java an sich schon viel umfangreicher und komplexer ist als zum Beispiel Node.js, erzieht Java auch viel eher dazu, umfangreiche und komplexe Lösungen zu entwickeln als Node.js, wo eher nach Einfachheit gestrebt wird (was auch nicht nur Vorteile hat, tbh). Natürlich ist am Ende immer noch die/der Entwickler:in die endgültig entscheidende Instanz, aber man wird eben über Jahre auch geprägt beziehungsweise auf bestimmte Muster erzogen, und sich davon zu lösen, ist nicht so einfach …
@@thenativeweb Lustig, da haben wir wohl eindeutig jeder seinen eigenen Bias. Ich hab lange viel Java gemacht auch c# unc c++. In letzter Zeit gabs auch einige Projekte mit node.js und Typescript. Meine These: Sprachen wie Java oder c# sind einfach besser geeignet um für große, komplexe Projekte zu realisieren. Vermutlich liegt das an der Sprache selber und dem ganzen Tooling drumherum. Wenn man nicht darauf achtet ist wachsende Komplexität lange kein Problem. Da gibt es das Antipattern vom "cleveren" Entwickler, der übermäßig Komplexen Code noch total im Griff hat, aber nicht "klug" genug ihn einfacher zu machen. Aber man muss es nicht komplex machen nur weil man es kann. Komplexität kommt aus der Problemdomäne und vom Entwickler ;-)
Ich finde das Thema mit der LOG4J Lücke wurde, im Vergleich zu anderen Schwachstellen, Medial sehr stark aufgebauscht. Zumindest hat es das Thema Security stärker in den Fokus des Managements geschoben, sodass wir als DevOps es leichter haben, da Maßnahmen durchzudrücken. Wir haben mal die Dependencies von einem größeren Projekt durch unseren Dependency Track Server durchgejagt und siehe da, selbst ohne Log4j hat man immer noch eine Risk-Score von 9,8 von 10. Vor Log4Shell wäre dies vielleicht mit einem Achselzucken abgetan, Hauptsache man bekommt seine Features durch den nächsten Sprint durch, aber nun hat man da eher einen Fuß in der Tür. Solche Dependency Analysen sollten öfter durchgeführt werden, zumal eine Abhängigkeit mit der Zeit auch schlechter wird und auch nur während, wenn überhaupt, der Compile-Zeit überprüft wird aber nicht im laufenden Betrieb, denn aus dem Auge, ist aus dem Sinne
Ich finde, dass es ganz selbstverständlich sein sollte, an Open Source etwas zurückzugeben. Möglichkeiten dafür gibt es genügend. Das fängt mit vernünftig geschriebenen Bugreports an. Unternehmen, die sich an Open-Source-Projekten beteiligen, können davon unglaublich profitieren. Das ist die beste Werbung, um fähige Entwickler anzulocken, und eine Möglichkeit internes Know-How durch den Austausch mit ganz unterschiedlichen Projekten aufzubauen.
Bei uns im DAX-Konzern wird extrem viel Open Source genutzt, aber nichts dafür gemacht. Wir haben sogar als strategisches Ziel primär auf Open Source zu setzen. Privat veröffentliche ich keine Software mehr als Open Source, früher schon. Wenn eine Firma meine IT-Leistung nutzen möchte, dann nur gegen entsprechende Bezahlung. Open Source ist so ein IT-Ding. Andere Branchen würden nie auf die Idee kommen ihre Arbeitsleistung kostenlos zu verschenken. Bezüglich Komplexität gebe ich dir bei Java recht. Dazu kommen noch die ganzen Notationen zur Codegenerierung etc. Aber Bibliotheken gibt es in allen Sprachen und wirklich nach Schwachstellen überprüfen tut die keiner. Ich bin mir bei Open Source nicht sicher, ob da nicht auch der ein oder andere Dienst gewisse Features einbringt, die er dann hinterher als Zeroday missbrauchen kann.
[gr] Ja, manchmal frage ich mich, ob wir uns als Branche mit Open-Source und freier Software nicht am Ende einen Bärendienst erwiesen haben … Natürlich hat FOSS jede Menge Vorteile, von denen ich auch definitiv nicht mehr weg wollen würde, aber es geht halt in 99,9% der Fälle nicht wie ursprünglich gedacht um freie Software ("free as in speech"), sondern um kostenlose Software ("free as in beer"). Und das ist ein Problem. Und das haben Lizenzen wie MIT & Co. zu verschulden, weil die "free as in beer" fördern, aber eben nicht "free as in speech", weil sie letztlich sagen "mir egal, was Du damit machst".
Separation of Concerns ist für mich die Grundlage im Umgang mit Komplexität. Gerade in großen Projekten sollte man darüber immer wieder reden. Die Frage ist, wen man da mitnehmen kann. Das betrifft jetzt nicht nur die eigene Anwendung. Sind denn Frameworks, die nach einem Baukastenprinzip aus wohldefinierten Bestandteilen funktionieren, am Markt erfolgreicher? Oder werden möglichst integrierte Frameworks von Entwicklern als einfacher wahrgenommen? Ich habe den Eindruck, dass das Wort "einfach" gefährlich ist, weil viele Menschen darunter sehr unterschiedliches verstehen. Retrospektiv wird Dir in dem Beispiel jeder zustimmen. Nur wir müssen das irgendwie vorher vermitteln. Ich persönlich mag den Ausdruck "You only pay what you eat". Nur habe ich den Eindruck, dass ich damit nur bei denen auf Gegenliebe stoße, die das Problem schon verstanden haben.
Es gibt viele Aspekte deiner Argumentation, denen ich voll zustimme. Es gibt schon ein großes Missverhältnis der Zahlungsbereitschaft bei Hard und Software, die ich immer wieder überraschend finde - aber leider auch zwischen kommerzieller Software und Opensource Software. Und ja jeder der was auch immer nutzt sollte sich überlegen, was das wen kostet und wie man solidarisch sein kann - gerade dann wenn Open Source Software im Enterprisesegment verwendet wird. Ich halte es allerdings für einen Trugschluss bei 18:07 aus unsolidarischem Verhalten oder einer Nehmermentalität Fehler wie bei Log4j als immer wieder gegeben zu sehen. Das Quellcode jedem offen steht ist doch genau ein gegenteiliges Argument, dass ein solcher fehler viel früher hätte auffallen müssen. Vielleicht wären die Tests ja umfangreicher gewesen, wenn mehr Geld zurückfließen würde, aber hier wurde schlichtweg die Komplexität unterschätzt. Das hätte unter jeder beliebigen Lizenz und jedem Vergütungssystem genauso passieren können. Und passiert mit sicherheit auch immer wieder. in der Schlussfolgerung Öizenzen zu fordern, die dann auch in einer Form mit vergütet wrden finde ich vollkommen richtig. Hier korreleiern aber Ursache und Wirkung nicht.
[gr] Vielen Dank für Deinen ausführlichen Kommentar 😊 Und ja, Du hast Recht - das kommt vielleicht nicht ganz raus, wie ich das gemeint hatte. Was ich sagen wollte, war: Ich finde es problematisch, dass Unternehmen zwar eine Erwartungshaltung haben, dass Open-Source gefälligst gepflegt werden soll, aber im Umkehrschluss nicht bereit sind, etwas dafür zu geben, dass sie weiterentwickelt wird. Natürlich würden solche Fehler auch auftreten, wenn es eine andere Lizenz wäre oder auch dann, wenn dafür bezahlt würde - aber wenn man dafür etwas zahlen würde, wäre auf der anderen Seite auch ein Anspruch vorhanden, mit dem man begründen könnte, warum man jetzt ganz dringend auf einmal diesen Fix braucht 😉 Das kam vielleicht nicht richtig raus.
Log4j ist das perfekte Beispiel, warum Feature Creep entgegengesteuert werden muss. Das Problem ist, dass solche Projekte oft zum Selbstzweck werden. Kein Programmierer sagt sich, "So, jetzt ist es fertig. Das brauche ich die nächsten 10 Jahre nicht mehr anzufassen", auch wenn das möglicherweise besser wäre. Aber dann wird das Projekt als "tot" eingestuft und darum von anderen Anwendern nicht benutzt (ironischerweise).
Danke für das gute informative Video, ich finde ebenso das man für eine getane Arbeit auch entlohnt werden sollte. Nur als einzelner (bsp.: großes Unternehmen) gegen mehrere steht man ziemlich verloren da. Prinzip geben nehmen, leider hat sich in der Gesellschaft eine andere Mentalität entwickelt ( die den Glauben hat das kostenloses bzw. Freies nicht gewürdigt werden braucht)
[gr] Ja, dass man als Einzelner nur bedingt etwas ausrichten kann, stimmt leider (und das, was Du über die Mentalität der Gesellschaft im Großen und Ganzen schreibst, leider auch). Andererseits: Auch wenn man nicht in der Position ist, zu entscheiden, ob und wofür Budget bereitgestellt wird, kann man zumindest versuchen, der Sache Gehör zu verschaffen und dafür zu werben … jedes Umdenken startet ja mal irgendwo im Kleinen. Ob man damit Erfolg hat, ist natürlich eine andere Frage, aber das wäre zumindest das, was auch jede*r Einzelne leisten kann.
Ich komme aus einem Umfeld wo mehrere Hundert Systeme betreut werden. Jedes ist dabei anders und nicht wirklich transparent installiert und dokumentiert. Zudem gibt es kein Verständnis dass Systeme gepflegt werden müssen. Teilweise konnten uns die externen Produktentwickler keine Auskunft geben. Einige extern erreichbare Systeme mussten daher zunächst abgeschaltet werden. Gut bei allem ist die offene Kommunikation. Teilweise gibt es jetzt Anwender die verstehen dass ein gewisser Teamfokus auf Sicherheit und Pflege notwendig ist. Auch meine Forderung besser zu dokumentieren wird jetzt stärker akzeptiert. Dokumentieren ist schließlich besser als vermuten. Danke für deine gute Erläuterungen zu den technischen Aspekten und zu Open Source. Werde mir selber ein paar Gedanken machen!
[gr] Danke für Deinen Kommentar und das Teilen Deiner Insights 😊
2 роки тому+2
sehr interessant. meiner erfahrung: was man bei open source einsparrt gibt man für komerzielle software aus (zb: oracle database). es gäbe vielleicht die möglichkeit über npm und maven statistiken geld zu verteilen, aber das müsste erst eingezahlt werden.
[gr] Das fände ich tatsächlich auch ein schönes System, zumal npm, Maven & Co. da ja irgendwie an der Quelle sitzen. Und es wäre so schön einfach: Man (Einzelperson oder Unternehmen) hinterlegt die Kreditkarte, bestimmt den monatlichen Betrag, den man bereit ist, auszugeben, und dann werden einfach die Downloads gezählt, und am Ende des Monats wird der Betrag anteilig an die einzelnen Projekte ausgezahlt.
Moinmoin, mich stört nur das Geben eben immer stark mit monetären Transfers in Verbindung gebracht wird. Ich verstehen das Geben und nehmen eher im Sinne eines 'wir machen was zusammen, wir machen was besser, Du nimmst meinen Code, ich nehme Deinen und wenn ich ein irgendwas an Deiner Software besser mache, dann formuliere ich Dir einen Merge Request. Das monetäre Ding, also die existenzielle Absicherung derjenigen, die Dinge verfügbar machen, ist IMHO ein soziales Problem, das wir in vielen Bereichen haben. Pflege, ehrenamtliches soziales und zivilgesellschaftliches Engagement, Politik - überall werden Leitungen erbracht ohne honoriert zu werden, weil sich in der Regel keine Person identifizieren lässt, die eine konkrete Motivation hat dafür zu löhnen, bzw. Objekt des Engagements ist (Pflege). Sondern es geht in der Regel um Dinge die allenfalls einen Gruppennutzen haben, wo dann wieder jemand die bauernschlaue Argumentation nutzt, sowieso nichts bewirken zu können. Die Tragik der Allmende, oder so geisterte mal als Titel durch die Welt. Die Frage ist aber, warum wir überhaupt die Abstraktion 'Geld' als soziales Interface brauchen, wo doch die Problemlösung und das Verstehen der Welt das ist was uns weiterbringt. Allerdings muss man auch eine Motivation zur Problemlösung entwickeln, und das ist natürlich nicht ganz trivial wenn man wie wir in einer materiell übersättigten, und von künstlichen Sinnesreizen zugemüllten Welt lebt. Aber das mit der GPL finde ich an dieser Stelle auch angebracht, den der Grundgedanke der Zivilisation ist das Kant'sche Wirkungsquantum.
Erstens mal, sehr gutes Video. Ich teile praktisch alles außer den Aufruf zu AGPL. Für mich ist der Grund für solche schwachsinnigen Features wie jetzt bei Log4j schon auch in der GitHub-Kultur verhaftet (und ich bin eigentlich ein großer Fan davon). Jeder Idiot kann einen Issue / Pull Request aufmachen, selbst wenn die Idee noch so dämlich ist. Und sobald jemand funktionierenden Code für sein Feature beisteuert, ist die Hemmschwelle sehr niedrig, den Code auch reinzumergen, weil es respektlos wäre, den Code abzulehnen. Auf einmal ist dann ne mords Lücke in der Software drinnen, weil 2-3 Leute auf der Welt mal nen schlechten Tag hatten und diesen Merge nicht gestoppt haben. Klar, das passiert auch den besten, aber wenn die Maintainer vielleicht ihr Projekt in Vollzeit betreiben könnten anstatt als Hobby und weniger finanziellen Druck gehabt hätten, wäre es vielleicht nicht dazu gekommen, abgesehen vom bereits thematisierten, sehr fahrlässigen Umgang mit Komplexität in Java.
[gr] Ja, das ist wohl wahr - man bekommt quasi ein schlechtes Gewissen "aufgezwungen" … den Effekt kenne ich leider auch, und da gehört schon einiges dazu, dann zu sagen, "danke, aber nein danke" und einen PR abzulehnen.
Unternehmen, die nach einiger Zeit des finanziellen Undanks zu dem Schluss kommen, dass sie ihre teuer entwickelte Software unter einer zu freizügigen Lizenz zur Verfügung stellen, können diesen Umstand nachträglich nicht mehr ungestraft korrigieren. Bleibt die Lizenz so wie sie ist, wird das Unternehmen mit weiterhin zu geringen Einnahmen bestraft. Wird zu einer restriktiveren Lizenz gewechselt, wird das Unternehmen von der Open-Source-Gemeinschaft mit einer gepfefferten Abreibung und evtl. auch einem Fork der Software unter der alten freizügigen Lizenz bestraft. Die Anzahl der Unternehmen, die wegen den sich schnell aufbauenden Besitzansprüchen der Open-Source-Gemeinschaft von einer Veröffentlichung der eigenen Software unter einer freien Lizenz abgeschreckt werden, könnte hoch sein.
Danke für das Video und die Aufklärung. Ich schaue mittlerweile täglich Videos von euch. Ich weiß nicht, ob es so ein Video bereits gibt, allerdings würde mich die gängigsten Pattern/Muster in der Backend-Entwicklung / Frontend-Entwicklung interessieren. Vielleicht so etwas wie eine Gegenüberstellung, was auf der Client- und Serverseite gängig ist. Das Backend entwickelt sich in der Hinsicht meine Wissens nach nur sehr langsam fort (was ja nicht schlecht sein muss). Gerade als Frontend-Entwickler habe ich da oft Verständnisprobleme, da ich mich im Moment in das Backend einarbeite. Ich hatte dazu schon mal ein Video von euch gesehen, zu den Architekturmuster, allerdings würde ich mir dieses in mehr Umfang wünschen, wo man vielleicht Beispiele zu den Mustern hat. Hast du vielleicht einen hilfreichen Tipp, wie ich im Backend besser zurecht komme (Verständnisebene, was dort überhaupt passiert)
[gr] Sorry für die späte Antwort … so richtig in die Richtung, was Du suchst, haben wir glaube ich noch nichts. Meine erste Antwort wäre "mach einfach mehr Backend", dann kommt der Rest schon von alleine. Viele Patterns ergeben sich ja daraus, wie man gewisse Dinge baut, einfach weil sich das etabliert hat. Ich würde sogar sagen, dass die Kernkonzepte gar nicht so großartig anders sind als im Frontend (also so Sachen wie die SOLID-Prinzipien, Kopplung und Kohäsion, Interfaces, … gelten hier wie dort). Dazu haben wir auch einiges: - SOLID: ua-cam.com/video/3to0t7YQMnU/v-deo.html - Kopplung: ua-cam.com/video/kWP432pXP-U/v-deo.html - Interfaces: ua-cam.com/video/5dIff-WXRvM/v-deo.html Und vielleicht ist eine gute Idee, tiefer in Backend-Technologien einzusteigen, zum Beispiel Node.js: - In 100 Minuten: ua-cam.com/video/5s7eFzI_fNo/v-deo.html - Unser großer Kurs: ua-cam.com/play/PL6QrD7_cU23kaZ05MvixcoJ5vctRD1qgC.html Ansonsten klingt das so, als könnte Dir so eine Art "Roadmap" helfen. Also: Was soll ich alles lernen und in welcher Reihenfolge. Ginge das in die richtige Richtung?
@@thenativeweb Ja, eine Roadmap ist immer sehr hilfreich. Ich beschäftige mich bereits mit Node.js, da ich als Webentwickler natürlich mit JavaScript/TypeScript vertraut bin. Ich habe mir z.B. auch das aktuellste Buch aus dem Rheinwerk-Verlag zu Node.js gekauft (aktuell zu Node.js Version 16) und mir fällt auf, dass es selbst dort kein Kapitel zu der Architektur im Backend bzw. Patterns gibt bzw. den Best Practice. Dort wird auch "einfach gemacht". Ich kenne es aus der Java-Entwicklung ein wenig, dass man viel in diesen "Schichten" denkt. Für so etwas fehlt mir das Verständnis, platt ausgedrückt.
@@dCoder92 [gr] Hm, verstehe … also was wir planen, was vielleicht ein bisschen helfen könnte, ist, dass wir in diesem Jahr ein Projekt entwickeln, was wir auf UA-cam über einige Videos hinweg zeigen und erklären, Frontend wie Backend (beziehungsweise das wird eine Kollaboration mit einem anderen UA-camr, und wir machen das Backend). Ansonsten glaube ich, dass es wahrscheinlich am sinnvollsten wäre, das mal an einem konkreten Beispiel gemeinsam durchzugehen, weil es eben doch recht schwierig ist, diese Frage(n) pauschal zu beantworten. Gerade die von Dir angesprochenen Schichten sind in meinen Augen ein sehr überbewertetes Konstrukt (nicht unwichtig, aber bei weitem nicht so relevant, wie Dir gerne glauben gemacht wird). Falls Du daran Interesse hast, melde Dich gerne mal unter hello [at] thenativeweb [dot] io bei uns, und dann können wir mal schauen, wie wir so etwas angehen könnten.
@@thenativeweb Das ist ein sehr nettes Angebot, danke. Ich bin allerdings im Moment durch einen Stellenwechsel ziemlich ausgelastet (Frontend-Entwicklung). Die ganze Backend-Entwicklung ist für mich im Moment noch "Zukunftsmusik". Aus persönlichem Interesse beschäftige ich mich damit, habe auch bereits eine eigene REST-API unter Node.js / Express.js entwickelt. Dabei habe ich die ganzen Entscheidungen oft einfach nicht hinterfragt (Ordnerstruktur, Zuständigkeiten, "Schichten" usw.) Im Moment höre ich sehr oft die Begriffe "Microservices / Micro Frontends" beruflich. Da ich meiner Meinung nach wenig Erfahrung im Backend habe, wollte ich mich dort mal etwas weiterbilden, um diese ganzen Begriffe besser einzuordnen. Langfristig möchte ich gerne als "Full Stack-Entwickler" tätig sein und natürlich ist das Wissen von der Serverseite als hauptberuflicher "Frontendler" sehr hilfreich. Dabei sind mir halt nur die angesprochenen Punkte aufgefallen, dass sehr wenig über die Architektur gesprochen wird bzw. über Muster/Pattern. Ich verfolge natürlich weiterhin euren UA-cam-Kanal und Beispiele in diese Richtung. Wenn ich mich tiefer in diesen Bereich eingearbeitet habe, dann werde ich mich sicherlich mit konkreten Fragen noch einmal melden, so ein Angebot lehnt man natürlich nicht ab.
Ich schreibe auch freie Software und manchmal nervt es mich schon, kein $$$ davon zu kriegen (auch wenn ich durchaus oft eingesetzte Komponenten entwickelt bzw. mitentwickelt habe). Jedoch ist Log4j nicht da drauf zurückzuführen. Log4j hat so funktioniert, wie es sollte. Mit mehr Geld gäbe es evtl. noch mehr Sicherheitslücken dieser Art. Das ist einfach dem Feature creep geschuldet. Da ist auch kommerzielle Software nicht immun dagegen. Leider tendieren wir dazu immer mehr Komponenten einzusetzen die man unmöglich überschauen kann. Die Softwarekomplexität ist schlichtweg zu hoch. Das ist erstmal vollkommen unabhängig von der Finanzierung. Log4j hatte keinen "Bug" - solche Features finden eben genug Programmierer toll. Heutzutage ist es ja toll, dass Code von irgendwo kommt, irgendwie zusammengesetzt wird und dann irgendwas tut (oder auch nicht). Aber gut… ist selten so eine Lücke #1 ist immer noch das C Geraffel mit den Memory Problemen. Grade OpenSource Lücken sind relativ selten - so dass sie ein richtiges Medienereignis sind. Über irgendwelche Lücken über die Ransomware in Exchange und co. verteilt wird regt sich ja schon keiner mehr auf - ist zu normal. Wenn das was zeigt, dann nur, wie hoch die Qualität der Open Source ist :). Da sind die Sicherheitslücken absichtlich drin.
Gute Darstellung der Thematik! Allerdings wird der Zusammenhang zwischen dem materialistisch-moralischen Aspekt (kommerziell genutzte Open Source Software angemessen zu vergüten) und dem technischen Aspekt (Anzahl und Schwere von Softwarefehlern zu verringern) nicht klar. Die Aussage klingt eher wie "wer bisher nur genommen hat, sollte jetzt nicht jammern". Sicher berechtigt - aber würde ein fairer Umgang miteinander die Softwarequalität verbessern? Ich würde gerne beipflichten, verstehe die Kausalität aber nicht, insbesondere im konkreten Fall Log4j.
[gr] Danke für Deinen Kommentar 😊 Ja, der Bogen ist eventuell nicht so ganz herausgekommen im Video … natürlich ändert ein fairerer Umgang die Qualität nicht direkt, beeinflusst aber indirekt, wie viel Zeit, Aufwand und auch Motivation man in etwas steckt, von dem vor allem andere profitieren. Insofern ist das eher ein indirekter Ansatz.
OpenSource muss staatlich gefördert werden. Man kann da mit sehr wenig Geld, sehr viel sinnvolles tun. Das Ministerium für Digitalisierung soll einen GitHub Clone bauen und wer dort etwas veröffentlicht bekommt auf Basis der Votes die sein Projekt hat einen entsprechenden Anteil aus dem Fördertopf.
Interessante Idee, aber die Entscheider in Ministerien (Beamte, Politiker) interessieren sich nur sehr begrenzt für Vorschläge von außerhalb. Viel lieber werden einschlägig bekannte Beratungsfirmen engagiert und Treffen mit Lobbyisten vereinbart.
Gehe ich eigentlich irgendwelche Risiken ein, wenn ich eine andere Lizenz als MIT verwendet. Bin ich dann als Open Source Entwickler zu irgendwas verpflichtet? Bei der MIT bin ich davon ausgegangen das ich keinerlei Verpflichtungen habe. Sollte ich, aus welchen Gründen auch immer, kein Interesse mehr an dem Projekt haben, dann kann ich bei einer MIT Lizenz garantiert jederzeit aus dem Projekt aussteigen. Ist das bei anderen Lizenzen auch gegeben?
[gr] Einfache Frage, schwierige Antwort … 😉 Also zumindest nach deutschem Recht (und das kann in der Schweiz, in Österreich oder einem anderen Land schon wieder anders aussehen) ist es so, dass Open-Source als Schenkung gilt, und dass Du für etwas, was Du jemandem schenkst, nicht haftest - solange Du nicht grob fahrlässig oder vorsätzlich handelst. Das heißt, *eigentlich* müsstest Du *immer* aus der Verpflichtung raus sein, solange die Lizenz nicht explizit etwas anders vorschreibt (aber das hast Du durch die Wahl der Lizenz ja selbst in der Hand). Mir persönlich ist keine aus dem Stegreif bekannt, bei der den Entwickler*innen Pflichten auferlegt würden (macht IMHO auch keinen Sinn, da es ja bei der Lizenz um das Einräumen von Rechten und Pflichten für die Nutzer*innen geht). Im Zweifelsfall würde ich hierzu aber eine Anwältin oder einen Anwalt konsultieren - das Thema ist deutlich komplexer als man als juristischer Laie meint, und im dümmsten Fall ändert sich das ja auch immer mal wieder, wie die Rechtsprechung gerade so aussieht …
[gr] Oh ja - es ist so viel schwieriger, Einfachheit zu erreichen als Komplexität … "Simplicity is the ultimate sophistication." (Leonardo da Vinci, IIRC)
Die Firma wofür ich arbeite unterstützt opensource. Wir sparen dadurch auch irgendwie steuern ein, weil die Arbeitszeit ja eine Betriebsausgabe ist. Wie das aber genau geht weiß ich aber auch nicht.
Meiner Meinung nach verwechselst Du Komplexität und Kompliziertheit. Komplexität ist eine unveränderliche, abstrakte Größe eines Systems. Sie wird durch seine abstrakte Beziehungen definiert und ist vom Problem abhängig, das durch das System modelliert wird. Kompliziertheit ist eine Größe eines spezifischen Lösungswegs für das Problem. Kompliziertheit ist zudem eine individuell wahrgenommene Größe. Deshalb müsstest Du sagen, dass Entwickler gut mit Komplexität und schlecht mit Kompliziertheit umgehen können. So kann ein und das selbe Problem auf zwei Arten gelöst werden, ohne dass sich die Komplexität des Problems ändert. In einem Fall wird es kompliziert gelöst, im anderen Fall nicht. Java ist in vielen Fällen zu kompliziert für niederkomplexe Probleme und zu kompliziert für viele Entwickler. Nicht zu komplex.
[gr] Danke für Dein Feedback 😊 Allerdings sehe ich das mit Kompliziertheit / Komplexität genau umgekehrt: Die Kompliziertheit (was für ein Wort …) ist ein Maß für den Schwierigkeitsgrad einer Aufgabe beziehungsweise einer Lösung. Die Komplexität ist ein Maß für deren Umfang. Beispiel: Es soll eine abs-Funktion geschrieben werden. Eine einfache Lösung, die sich dadurch auszeichnet, dass sie kurz ist, einfach zu verstehende Sprachmittel anwendet, und auch von wenig erfahrenen Entwickler:innen verstanden werden kann, wäre das hier: const abs = function (number) { if (number >= 0) { return number; } return number * -1; }; Das gleiche kann man aber auch sehr kompliziert lösen, indem man statt eines einfachen if das Strategy-Pattern implementiert, das in Abhängigkeit von dem Ergebnis eines AlgebraicSignDiscriminators eine entsprechende Berechnung ausführt und das Ergebnis zurück liefert. Völlig unabhängig davon, dass diese Lösung zugleich auch umfangreicher wäre, wäre sie erst einmal viel schwieriger nachvollziehbar und erfordert für das Verständnis deutlich mehr Erfahrung. Nun ist es aber nicht immer so, dass eine kompliziertere (schwierigere) Lösung zugleich auch länger sein muss. Gerade, wenn man versucht, Code möglichst kompakt zu schreiben, so wenige Bytes wie möglich zu verwenden, wird er häufig zwar kürzer, aber trotzdem schlechter verständlich. Die Kompliziertheit gibt also den Schwierigkeitsgrad an. Das passt auch der Erklärung im Wörterbuch, zum Beispiel in Wiktionary (siehe de.wiktionary.org/wiki/kompliziert): "Subjektiv erscheint etwas als kompliziert, wenn man nicht über das Wissen, das Können, die Intelligenz oder die Bereitschaft verfügt, es zu verstehen oder zu beherrschen." Als Bedeutungen werden angegeben: umständlich, undurchschaubar, schwierig, verzwickt, verstrickt Komplexität ist aber etwas anderes: Komplexität entsteht durch die schiere Größe einer Lösung und die dieser Lösung innewohnenden Abhängigkeiten: Wenn man an einer Stelle etwas ändert, ändern sich (ungewollt) zig andere Stellen mit. Man verliert den Überblick. Das liegt aber nicht an den Fähigkeiten oder der Intelligenz, sondern an der fehlenden Möglichkeit des menschlichen Gehirns, mehr als ein paar Sachen zugleich zu verarbeiten. Da es in größeren Lösungen häufig mehr Abhängigkeiten gibt und sie vielschichtiger sind, sind die in der Regel auch komplexer. Auch das passt zum Wörterbucheintrag (siehe auch hier Wictionary, zB de.wiktionary.org/wiki/komplex), was als Bedeutungen hat: verflochten, zusammenhängend, umfassend, vielschichtig Java fördert nun Kompliziertheit nur bedingt, denn auch in Java kann ich zB oben genannte einfache abs-Funktion schreiben (auch wenn die Syntax etwas anders aussieht, aber sinngemäß). Um das machen zu können, brauche ich aber wahnsinnig viele Sprachmittel: Eine Klasse. Eine Methode. Zugriffsmodifizierer. Eventuell das Schlüsselwort static. Void. Imports. Und, und, und. Das siehst Du sehr schön, wenn Du mal ein Hallo-Welt-Programm in Java mit einem in zB Python vergleichst. 10 Zeilen gegenüber 1 Zeile. 20 Sprachkonstrukte gegenüber 1 Sprachkonstrukt. public class HelloWorld { public static void main (String[] args) { System.out.println("Hello world!"); } } ist nicht nur komplizierter als print "Hello world!" es ist auch deutlich komplexer. Und dann die Ausführung. Das JDK, javac, java, der Classpath, … um 10 Buchstaben auf den Bildschirm zu bringen?! Vergleich das mal mit: python helloworld.py Und das zeigt, finde ich, ziemlich gut, warum Java Komplexität fördert: Weil alles in Java von Vornherein auf Komplexität ausgelegt ist. Man schreibt keinen "einfachen" Code. Nein, man baut in nJava allzu bereitwillig eine AbstractProxyFactoryImpl, und erklärt, das sei "normal", weil Enterprise-Entwicklung eben anspruchsvoll sei. Und das färbt ab, auf die Art, wie man dann selbst entwickelt. Man züchtet sich auf dem Weg ein künstlich komplexes, umfangreiches, unübersichtliches und völlig überfrachtetes Ökosystem heran, statt das Nächstliegende zu tun, statt eine => einfache
Ich schreibe auch Open Source Software und meine Standard-Lizenz ist MIT. GPL oder AGPL nutze ich nicht und habe es auch nicht vor zu nutzen. In der Regel deckt die Software meine eigenen Probleme und Belange ab und nach mir die Sinnflut. Sollte es mal doch passieren das jemand tatsächlich meine Software nutzt und Features vermisst, soll entweder diese selbst implementieren oder bekommt von mir entsprechend ein Angebot. Die Software ist vielleicht kostenlos aber meine Arbeit, nicht.
Gerne :) Ich hoffe es kommt nicht allzu negativ rüber. Aber das ist letztendlich auch das, was ich von anderen Entwicklern die Open Source Programme schreiben, gelernt habe ^^ Dennoch träumen nicht wenige vom gewissen finanzellem Reichtum :D Ich auch.
"Ich bin zwar kein Java Entwickler, aber... " 😁 Zu log4j: Die Appender Idee ist über 20 Jahre alt. 12 Faktor war damals noch nicht mal ne Idee. Zudem muss keiner diese heute nicht mehr sinnvollen Appender nutzen. Außerdem ist log4j schon lange nicht mehr der Logging Standard. All das weiß aber ein vernünftiger Java Entwickler 😋
In diesem Sinne wollte ich meine 2 Cent dazu geben. Danke, schon passiert! Glückwunsch für die knackigen Videos, kurz und auf den Punkt gebracht. Ich blicke jetzt auf 40 Jahre IT Erfahrung zurück und könnte über diese hier angerissen Themen, stundenlang referieren. Deshalb nur angerissen: Java Loggign Standard ist java util logging. Log4j in seiner ersten Version kam früher auf die Welt. Open Source ist nicht nicht gleich Open Source, ist gibt erhebliche Qualitätsunterschiede. Viele Java Apache Projekte sind alt, werden nicht selten in der Freizeit entwickelt und sind von schlechter Qualität. Das kritisierte Feature von log4j V2 wurde in der Entwicklerrunde diskutiert und fand trotz bekannter Sicherheitsmängel den Weg in die Codebasis, was einfach darin liegt, WER das in letzter Instanz entscheidet. Die GPL hat gravierende Schwächen, von Richard Stallman gut gemeint, aber wenig praxistauglich. Als C++ Entwickler verwende ich Java gerne. Ich empfinde die Sprache weniger komplex. Kann jedoch gut nachvollziehen, dass das ein NodeJS Entwickler anders beurteilt.
Ich sehe die von dir angesprochene „Gegenleistungs-Idee“ für Open Source nicht so zielführend. Wenn ich Source veröffentliche, geht es mir darum, dass das auch verwendet wird da sind GPL Lizenzen einfach ein Show-Stoper.
Ich benutze Open source, mein wille Opensource zu unterstützen ist Open Source zu benutzen um andere Open Source software zu erstellen, genug geld um das zu fördern hab ich leider nicht :(
Warum Open-Source kaputt ist. Warum dieser reißerische Titel? Also dass die Entwickler von Log4J hier Bockmist gebaut haben steht doch außer jeder Frage, und ob dieser Fehler nicht passiert wäre, wenn viel Geld geflossen wäre stelle ich mal in Frage! Ist Open-Source wirklich immer kostenlos? Also hier passt so einiges in diesem Video nicht, auch wenn ich die Gedankengänge verstehe und größtenteils sogar teile. Für kostenlose Software auch mal etwas spenden!! Auf jeden Fall!! Das mehr Geld bessere Qualität bedeutet? Auf keinen Fall, da gibts genügend Beispiele. Das ein Bug in Open-Source das Ende von Open-Source bedeutet? Hallo?
Ich persönlich finde es sehr wichtig, sich selbst an Open Source Projekten zu beteiligen. Mit ist es wichtig etwas zurück zu geben. Auch wenn es nicht viel ist.
[gr] Finde ich eine schöne Einstellung - und so wichtig ist es auch gar nicht, ob das viel oder wenig ist, viel wichtiger ist IMHO, dass es halbwegs regelmäßig passiert. Denn dann addieren sich auch Kleinigkeiten im Lauf der Zeit auf 😊
Alleine Bugs in Anwendungen zu melden hilft schon, denke ich
[gr] Auf jeden Fall 😊
Absolute Zustimmung. Bei größeren Firmen ist aber das Problem, dass du keine Möglichkeit hast zu spenden oder Quellcode beizusteuern, weil es schlechtweg keine Prozesse gibt bzw. Verboten ist und die es Entscheiden, wollen es schlichtweg nicht verstehen.
Die einzige Möglichkeit ist Privat was beizusteuern…
Daher die Lösung, alles in APGL veröffentlichen!
[gr] Danke schön 😊
Sehr interessantes Video!
Kann sein, dass es das schon gibt. Aber ich fände es ganz cool in einem Video evtl. mal einen Überblick über das Thema "OpenSource" zu geben. Also was es bedeutet und einen generellen Überblick darüber zu geben. Bei den im Video genannten Lizenzen beispielsweise verstehe ich größtenteils nicht genau was es damit auf sich hat. Auch die Fragen, wie gehe ich damit um, wenn ich OpenSource Frameworks oder Software unter bestimmten Lizenzen verwende bzw. in meiner eigenen Software integriere. Ich kann mir gut vorstellen, dass es einige andere da Draußen gibt, die OpenSource Persee auch erst mal nur als "kostenlose" Software kennen.
[gr] Vielen Dank für das Lob 😊
Prinzipiell haben wir in die Richtung schon einmal ein bisschen was gemacht:
- Was ist Open-Source: ua-cam.com/video/KVdZakKQpno/v-deo.html
- Lizenzen: GPL, MIT & Co.: ua-cam.com/video/65yaerkySWQ/v-deo.html
- Warum Open-Source entwickeln: ua-cam.com/video/6V0fLIQAdbU/v-deo.html
Aber, was wir noch nicht haben, ist, das alles mal in einem großen Überblick in einem Video zusammengefasst. Und das ist eine gute Idee, das würde gut in unser "X in 100 Minuten"-Format passen … ist auf die Liste aufgenommen 😊
Ich habe verstanden, dass ich dieses Paket gar nicht brauche, wenn ich alle Log-Nachrichten auf die Konsole ausgebe. Vor kurzem habe ich noch irgendwo gelesen, "das macht man nicht". Danke für Deinen Vortrag.
Super Video, vielen Dank! Ich arbeite in einer Entwicklungs-Fachstelle einer Bank. Wir setzen sehr viel Open-Source ein. Das zurückgeben ist aber oft schwierig. Wenn ein Entwickler Code veröffentlichen möchte, muss Er einen relativ aufwändigen und komplizierten Prozess anstossen. Zuerst müssen die Legal & Compliance Themen geklärt werden was meist eine individuelle Beurteilung eines oder mehreren Juristen bedarf. Danach muss der Entwickler den Code nach den Vorgaben prüfen und ggf. anpassen und wir als Fachstelle müssen diesen dann gegenchecken sowie bestätigen. Dieser Aufwand kann von vielen Teams gar nicht getragen werden und so findet das zurückgeben selten statt. Wir arbeiten hart dafür, dass sich dies ändert aber haben naturgemäss einigen Gegenwind. Mit zurückgeben verdient man vordergründig kein Geld und so müssen wir genau diese Argumente, welche Du erwähnt hast, gegenüber dem Business immer wieder aufzeigen. Aber da sind wir nun nach einigen Jahren auf jeden Fall einen grossen Schritt vorwärts gekommen aber sind aus meiner Sicht immer noch weit hinter einer befriedigenden Situation diesbezüglich.
Ich bin vor kurzem erst auf deinen Kanal gestoßen und bin wirklich sehr angetan. Im deutschsprachigen Raum habe ich bisher nichts vergleichbares gesehen. Danke dafür! Dein Wunsch zu weniger Komplexität und mehr hin zu "einfachen" Code teile ich leider nur bedingt. Prinzipiell wünscht sich das jeder Entwickler aber der Preis dafür ist in der Regel eine weitere Abstraktionsschicht. Das kann entweder eine Programmiersprache sein, ein Framework oder ähnliches. Aber dadurch verliert man auch viel an Kontrolle und wenn ein Problem auftritt, innerhalb dieser Schicht, dann ist man gezwungen sich in diese Komplexität einzuarbeiten. Also meines Erachtens verlagert sich das Problem nur bzw. Komplexität wird einem nur zum Teil abgenommen. Generell bin ich kein Freund mehr davon, für jedes kleine Problem direkt einen Framework, Library einzusetzen bzw. eine Dependency . Denn der Name ist wirklich Programm, eine weitere Abhängigkeit um die man sich kümmern muss.
[gr] Das stimmt - es ist nicht zielführend, für jede Kleinigkeit eine extra Dependency einzuführen, denn das geht zwar initial sehr einfach, zieht aber Maintenance nach sich, und das unterschätzt man gerne … und gerade kleine und einfache Sachen lassen sich dann doch auch relativ schnell selbst implementieren (wobei es da natürlich nicht mit dem reinen Code getan ist, so etwas will ja auch getestet, dokumentiert, … werden).
Dass man die Komplexität nur verlagert, da bin ich ebenfalls bei Dir - der Punkt dabei ist aber, dass man die Komplexität weiter nach oben zieht, und sie deshalb besser zentralisieren kann. Ich habe lieber zehn einfache Komponenten und eine übergeordnete, die die komplexe Orchestration übernimmt, als zehn komplexe Komponenten, und eine einfache übergeordnete 😉
PS: Vielen, vielen Dank für das tolle Feedback und Dein Lob zu unserem Kanal, das freut mich sehr 😊
Respekt! Sehr schöne Erläuterungen!
[gr] Danke schön 😊
Hab den Channel gerade erst entdeckt und die ersten Videos gesehen, großartig!
Qualitativ enorm hochwertiger Content, da können viele der richtig großen Channels einpacken.
Großes Kompliment!
[gr] Vielen, vielen Dank - und ja, wir gehören noch nicht zu den "richtig großen Channels", aber was nicht ist, kann ja noch werden 😊
Die Aussage über den Einfluss der "Community" und von "Glaubensätzen" ist absolut richtig. Das hat mich an Java immer abgeschreckt. Das hat z.T. religiösen Charakter. Ds wird besonders schwierig, wenn man das auf Programmierer loslässt die aus komplett anderen Kulturkreisen kommen und auch wegen ihrer mangelhaften Ausbildung mit dem hohen Komplexitätsgrad überfordert sind und dann nicht mit der Sprache / Bibliothek programmieren sonder gegen sie. Allzu oft werden irgendwelche Dinge stumpf übernommen, weil man das halt so macht. Ich sehe das Problem mit der mangelnden Qualität und Sicherheit aber etwas anders. Das ist nicht auf Open Source beschränkt (da wird es aber transparent). Bei Closed Source sind die Mängel noch viel gravierender. Der Hauptgrund ist das a) blanke Gier herrscht und die wenigsten überhaupt bereit sind für Qualität und Sicherheit ausreichende Mittel aufzubringen b) auch eine schlechte unsichere Software allemal besser ist als es gar nicht oder von Hand zu machen und daher den SW EntwicklerInnen mehr oder minder alles aus der Hand gerissen wird. Features = GEIL, Warten = TEUER, QM = Pseudo Veranstaltung (konsistent Lügen ist billig). Und das prägt die Einstellung von vielen SW EntwicklerInnen. Wer schnell viele Features raushaut ist beim Auftraggeber beliebt. Und es macht allemal mehr Spaß komplizierte Konstrukte umzusetzen als sich mit schnödem QM zu beschäftigen. Zumal kreative Menschen auch ständig nach neuen Herausforderungen suchen. Interessant wäre ja mal die Idee das bestimmte Algorithmen und deren Umsetzung eigentlich Eigentum der Menschheit sein sollten, d.h. diese professionell und ordentliche bezahlt durch Institutionen definiert, entwickelt und publiziert werden, anstatt von Firm, Konsortien und Enthusiasten. Sowas gibt es z.T. schon (z.B. der AES Code) und es ist jedes Mal extrem erfolgreich.
[gr] Danke für Deinen ausführlichen Kommentar. Vor allem Deine Zusammenfassung ist gut, wenn auch traurig (aber trotzdem wahr).
Danke für das Video,
Ich tu mir aber schwer damit die Komplexität von Log4J einfach mit dem Java-Umfeld abzutun.
Ich glaube nicht dass diese Art von Komplexität ein Java-Problem ist, es ist ein Entwickler-Problem.
Das Log4J Team hat selbst entschieden wie es sein Framework bauen will, keine Ausreden.
Ich gebe Ihnen Recht was die Schuldfrage angeht.
Fehler kann man nicht verhindern, aber man sollte daraus lernen.
Und genau da sehe ich das Log4J-Team in der Verantwortung.
[gr] Es ist natürlich richtig, dass jede:r Entwickler:in selbst entscheidet, welche und vor allem wie viele Features man aufnimmt oder eben nicht - aber man trifft diese Entscheidung eben auch immer vor dem Hintergrund einer bestimmten Kultur und im Rahmen eines bestimmten Ökosystems.
Und weil Java an sich schon viel umfangreicher und komplexer ist als zum Beispiel Node.js, erzieht Java auch viel eher dazu, umfangreiche und komplexe Lösungen zu entwickeln als Node.js, wo eher nach Einfachheit gestrebt wird (was auch nicht nur Vorteile hat, tbh).
Natürlich ist am Ende immer noch die/der Entwickler:in die endgültig entscheidende Instanz, aber man wird eben über Jahre auch geprägt beziehungsweise auf bestimmte Muster erzogen, und sich davon zu lösen, ist nicht so einfach …
@@thenativeweb Lustig, da haben wir wohl eindeutig jeder seinen eigenen Bias.
Ich hab lange viel Java gemacht auch c# unc c++. In letzter Zeit gabs auch einige Projekte mit node.js und Typescript.
Meine These: Sprachen wie Java oder c# sind einfach besser geeignet um für große, komplexe Projekte zu realisieren.
Vermutlich liegt das an der Sprache selber und dem ganzen Tooling drumherum.
Wenn man nicht darauf achtet ist wachsende Komplexität lange kein Problem.
Da gibt es das Antipattern vom "cleveren" Entwickler, der übermäßig Komplexen Code noch total im Griff hat, aber nicht "klug" genug ihn einfacher zu machen.
Aber man muss es nicht komplex machen nur weil man es kann.
Komplexität kommt aus der Problemdomäne und vom Entwickler ;-)
Ich finde das Thema mit der LOG4J Lücke wurde, im Vergleich zu anderen Schwachstellen, Medial sehr stark aufgebauscht. Zumindest hat es das Thema Security stärker in den Fokus des Managements geschoben, sodass wir als DevOps es leichter haben, da Maßnahmen durchzudrücken. Wir haben mal die Dependencies von einem größeren Projekt durch unseren Dependency Track Server durchgejagt und siehe da, selbst ohne Log4j hat man immer noch eine Risk-Score von 9,8 von 10. Vor Log4Shell wäre dies vielleicht mit einem Achselzucken abgetan, Hauptsache man bekommt seine Features durch den nächsten Sprint durch, aber nun hat man da eher einen Fuß in der Tür.
Solche Dependency Analysen sollten öfter durchgeführt werden, zumal eine Abhängigkeit mit der Zeit auch schlechter wird und auch nur während, wenn überhaupt, der Compile-Zeit überprüft wird aber nicht im laufenden Betrieb, denn aus dem Auge, ist aus dem Sinne
Ich finde, dass es ganz selbstverständlich sein sollte, an Open Source etwas zurückzugeben. Möglichkeiten dafür gibt es genügend. Das fängt mit vernünftig geschriebenen Bugreports an. Unternehmen, die sich an Open-Source-Projekten beteiligen, können davon unglaublich profitieren. Das ist die beste Werbung, um fähige Entwickler anzulocken, und eine Möglichkeit internes Know-How durch den Austausch mit ganz unterschiedlichen Projekten aufzubauen.
Wirklich großartiges Video! Hab diesen Kanal soeben entdeckt und bin echt begeistert von der Qualität des hier gebotenen Inhaltes.
[gr] Vielen, vielen Dank 😊
Bei uns im DAX-Konzern wird extrem viel Open Source genutzt, aber nichts dafür gemacht. Wir haben sogar als strategisches Ziel primär auf Open Source zu setzen.
Privat veröffentliche ich keine Software mehr als Open Source, früher schon. Wenn eine Firma meine IT-Leistung nutzen möchte, dann nur gegen entsprechende Bezahlung. Open Source ist so ein IT-Ding. Andere Branchen würden nie auf die Idee kommen ihre Arbeitsleistung kostenlos zu verschenken.
Bezüglich Komplexität gebe ich dir bei Java recht. Dazu kommen noch die ganzen Notationen zur Codegenerierung etc. Aber Bibliotheken gibt es in allen Sprachen und wirklich nach Schwachstellen überprüfen tut die keiner.
Ich bin mir bei Open Source nicht sicher, ob da nicht auch der ein oder andere Dienst gewisse Features einbringt, die er dann hinterher als Zeroday missbrauchen kann.
[gr] Ja, manchmal frage ich mich, ob wir uns als Branche mit Open-Source und freier Software nicht am Ende einen Bärendienst erwiesen haben …
Natürlich hat FOSS jede Menge Vorteile, von denen ich auch definitiv nicht mehr weg wollen würde, aber es geht halt in 99,9% der Fälle nicht wie ursprünglich gedacht um freie Software ("free as in speech"), sondern um kostenlose Software ("free as in beer"). Und das ist ein Problem.
Und das haben Lizenzen wie MIT & Co. zu verschulden, weil die "free as in beer" fördern, aber eben nicht "free as in speech", weil sie letztlich sagen "mir egal, was Du damit machst".
Danke, wie immer prima erklärt..!
[gr] Danke, das freut mich (wie immer) sehr 😊
Tolles Video bin da ganz bei Dir.
[gr] Vielen Dank 😊
Separation of Concerns ist für mich die Grundlage im Umgang mit Komplexität. Gerade in großen Projekten sollte man darüber immer wieder reden. Die Frage ist, wen man da mitnehmen kann. Das betrifft jetzt nicht nur die eigene Anwendung.
Sind denn Frameworks, die nach einem Baukastenprinzip aus wohldefinierten Bestandteilen funktionieren, am Markt erfolgreicher? Oder werden möglichst integrierte Frameworks von Entwicklern als einfacher wahrgenommen?
Ich habe den Eindruck, dass das Wort "einfach" gefährlich ist, weil viele Menschen darunter sehr unterschiedliches verstehen. Retrospektiv wird Dir in dem Beispiel jeder zustimmen. Nur wir müssen das irgendwie vorher vermitteln.
Ich persönlich mag den Ausdruck "You only pay what you eat". Nur habe ich den Eindruck, dass ich damit nur bei denen auf Gegenliebe stoße, die das Problem schon verstanden haben.
Es gibt viele Aspekte deiner Argumentation, denen ich voll zustimme. Es gibt schon ein großes Missverhältnis der Zahlungsbereitschaft bei Hard und Software, die ich immer wieder überraschend finde - aber leider auch zwischen kommerzieller Software und Opensource Software. Und ja jeder der was auch immer nutzt sollte sich überlegen, was das wen kostet und wie man solidarisch sein kann - gerade dann wenn Open Source Software im Enterprisesegment verwendet wird.
Ich halte es allerdings für einen Trugschluss bei 18:07 aus unsolidarischem Verhalten oder einer Nehmermentalität Fehler wie bei Log4j als immer wieder gegeben zu sehen. Das Quellcode jedem offen steht ist doch genau ein gegenteiliges Argument, dass ein solcher fehler viel früher hätte auffallen müssen. Vielleicht wären die Tests ja umfangreicher gewesen, wenn mehr Geld zurückfließen würde, aber hier wurde schlichtweg die Komplexität unterschätzt. Das hätte unter jeder beliebigen Lizenz und jedem Vergütungssystem genauso passieren können. Und passiert mit sicherheit auch immer wieder.
in der Schlussfolgerung Öizenzen zu fordern, die dann auch in einer Form mit vergütet wrden finde ich vollkommen richtig. Hier korreleiern aber Ursache und Wirkung nicht.
[gr] Vielen Dank für Deinen ausführlichen Kommentar 😊
Und ja, Du hast Recht - das kommt vielleicht nicht ganz raus, wie ich das gemeint hatte. Was ich sagen wollte, war: Ich finde es problematisch, dass Unternehmen zwar eine Erwartungshaltung haben, dass Open-Source gefälligst gepflegt werden soll, aber im Umkehrschluss nicht bereit sind, etwas dafür zu geben, dass sie weiterentwickelt wird.
Natürlich würden solche Fehler auch auftreten, wenn es eine andere Lizenz wäre oder auch dann, wenn dafür bezahlt würde - aber wenn man dafür etwas zahlen würde, wäre auf der anderen Seite auch ein Anspruch vorhanden, mit dem man begründen könnte, warum man jetzt ganz dringend auf einmal diesen Fix braucht 😉
Das kam vielleicht nicht richtig raus.
Danke, gerade, dass die Lizenzen mal angesprochen wurden. Euer Channel sollte wirklich mehr Reichweite habe, aber das kann ja noch werden👍👍
[gr] Danke schön 😊
Log4j ist das perfekte Beispiel, warum Feature Creep entgegengesteuert werden muss. Das Problem ist, dass solche Projekte oft zum Selbstzweck werden. Kein Programmierer sagt sich, "So, jetzt ist es fertig. Das brauche ich die nächsten 10 Jahre nicht mehr anzufassen", auch wenn das möglicherweise besser wäre. Aber dann wird das Projekt als "tot" eingestuft und darum von anderen Anwendern nicht benutzt (ironischerweise).
[gr] Leider wahr …
Danke für das gute informative Video, ich finde ebenso das man für eine getane Arbeit auch entlohnt werden sollte. Nur als einzelner (bsp.: großes Unternehmen) gegen mehrere steht man ziemlich verloren da. Prinzip geben nehmen, leider hat sich in der Gesellschaft eine andere Mentalität entwickelt ( die den Glauben hat das kostenloses bzw. Freies nicht gewürdigt werden braucht)
[gr] Ja, dass man als Einzelner nur bedingt etwas ausrichten kann, stimmt leider (und das, was Du über die Mentalität der Gesellschaft im Großen und Ganzen schreibst, leider auch).
Andererseits: Auch wenn man nicht in der Position ist, zu entscheiden, ob und wofür Budget bereitgestellt wird, kann man zumindest versuchen, der Sache Gehör zu verschaffen und dafür zu werben … jedes Umdenken startet ja mal irgendwo im Kleinen. Ob man damit Erfolg hat, ist natürlich eine andere Frage, aber das wäre zumindest das, was auch jede*r Einzelne leisten kann.
Ich komme aus einem Umfeld wo mehrere Hundert Systeme betreut werden. Jedes ist dabei anders und nicht wirklich transparent installiert und dokumentiert. Zudem gibt es kein Verständnis dass Systeme gepflegt werden müssen. Teilweise konnten uns die externen Produktentwickler keine Auskunft geben. Einige extern erreichbare Systeme mussten daher zunächst abgeschaltet werden. Gut bei allem ist die offene Kommunikation. Teilweise gibt es jetzt Anwender die verstehen dass ein gewisser Teamfokus auf Sicherheit und Pflege notwendig ist. Auch meine Forderung besser zu dokumentieren wird jetzt stärker akzeptiert. Dokumentieren ist schließlich besser als vermuten.
Danke für deine gute Erläuterungen zu den technischen Aspekten und zu Open Source. Werde mir selber ein paar Gedanken machen!
[gr] Danke für Deinen Kommentar und das Teilen Deiner Insights 😊
sehr interessant. meiner erfahrung: was man bei open source einsparrt gibt man für komerzielle software aus (zb: oracle database). es gäbe vielleicht die möglichkeit über npm und maven statistiken geld zu verteilen, aber das müsste erst eingezahlt werden.
[gr] Das fände ich tatsächlich auch ein schönes System, zumal npm, Maven & Co. da ja irgendwie an der Quelle sitzen. Und es wäre so schön einfach: Man (Einzelperson oder Unternehmen) hinterlegt die Kreditkarte, bestimmt den monatlichen Betrag, den man bereit ist, auszugeben, und dann werden einfach die Downloads gezählt, und am Ende des Monats wird der Betrag anteilig an die einzelnen Projekte ausgezahlt.
Moinmoin, mich stört nur das Geben eben immer stark mit monetären Transfers in Verbindung gebracht wird. Ich verstehen das Geben und nehmen eher im Sinne eines 'wir machen was zusammen, wir machen was besser, Du nimmst meinen Code, ich nehme Deinen und wenn ich ein irgendwas an Deiner Software besser mache, dann formuliere ich Dir einen Merge Request.
Das monetäre Ding, also die existenzielle Absicherung derjenigen, die Dinge verfügbar machen, ist IMHO ein soziales Problem, das wir in vielen Bereichen haben. Pflege, ehrenamtliches soziales und zivilgesellschaftliches Engagement, Politik - überall werden Leitungen erbracht ohne honoriert zu werden, weil sich in der Regel keine Person identifizieren lässt, die eine konkrete Motivation hat dafür zu löhnen, bzw. Objekt des Engagements ist (Pflege). Sondern es geht in der Regel um Dinge die allenfalls einen Gruppennutzen haben, wo dann wieder jemand die bauernschlaue Argumentation nutzt, sowieso nichts bewirken zu können. Die Tragik der Allmende, oder so geisterte mal als Titel durch die Welt. Die Frage ist aber, warum wir überhaupt die Abstraktion 'Geld' als soziales Interface brauchen, wo doch die Problemlösung und das Verstehen der Welt das ist was uns weiterbringt.
Allerdings muss man auch eine Motivation zur Problemlösung entwickeln, und das ist natürlich nicht ganz trivial wenn man wie wir in einer materiell übersättigten, und von künstlichen Sinnesreizen zugemüllten Welt lebt. Aber das mit der GPL finde ich an dieser Stelle auch angebracht, den der Grundgedanke der Zivilisation ist das Kant'sche Wirkungsquantum.
Erstens mal, sehr gutes Video. Ich teile praktisch alles außer den Aufruf zu AGPL.
Für mich ist der Grund für solche schwachsinnigen Features wie jetzt bei Log4j schon auch in der GitHub-Kultur verhaftet (und ich bin eigentlich ein großer Fan davon). Jeder Idiot kann einen Issue / Pull Request aufmachen, selbst wenn die Idee noch so dämlich ist. Und sobald jemand funktionierenden Code für sein Feature beisteuert, ist die Hemmschwelle sehr niedrig, den Code auch reinzumergen, weil es respektlos wäre, den Code abzulehnen. Auf einmal ist dann ne mords Lücke in der Software drinnen, weil 2-3 Leute auf der Welt mal nen schlechten Tag hatten und diesen Merge nicht gestoppt haben.
Klar, das passiert auch den besten, aber wenn die Maintainer vielleicht ihr Projekt in Vollzeit betreiben könnten anstatt als Hobby und weniger finanziellen Druck gehabt hätten, wäre es vielleicht nicht dazu gekommen, abgesehen vom bereits thematisierten, sehr fahrlässigen Umgang mit Komplexität in Java.
[gr] Ja, das ist wohl wahr - man bekommt quasi ein schlechtes Gewissen "aufgezwungen" … den Effekt kenne ich leider auch, und da gehört schon einiges dazu, dann zu sagen, "danke, aber nein danke" und einen PR abzulehnen.
Unternehmen, die nach einiger Zeit des finanziellen Undanks zu dem Schluss kommen, dass sie ihre teuer entwickelte Software unter einer zu freizügigen Lizenz zur Verfügung stellen, können diesen Umstand nachträglich nicht mehr ungestraft korrigieren. Bleibt die Lizenz so wie sie ist, wird das Unternehmen mit weiterhin zu geringen Einnahmen bestraft. Wird zu einer restriktiveren Lizenz gewechselt, wird das Unternehmen von der Open-Source-Gemeinschaft mit einer gepfefferten Abreibung und evtl. auch einem Fork der Software unter der alten freizügigen Lizenz bestraft.
Die Anzahl der Unternehmen, die wegen den sich schnell aufbauenden Besitzansprüchen der Open-Source-Gemeinschaft von einer Veröffentlichung der eigenen Software unter einer freien Lizenz abgeschreckt werden, könnte hoch sein.
Danke für das Video und die Aufklärung. Ich schaue mittlerweile täglich Videos von euch.
Ich weiß nicht, ob es so ein Video bereits gibt, allerdings würde mich die gängigsten Pattern/Muster in der Backend-Entwicklung / Frontend-Entwicklung interessieren.
Vielleicht so etwas wie eine Gegenüberstellung, was auf der Client- und Serverseite gängig ist.
Das Backend entwickelt sich in der Hinsicht meine Wissens nach nur sehr langsam fort (was ja nicht schlecht sein muss).
Gerade als Frontend-Entwickler habe ich da oft Verständnisprobleme, da ich mich im Moment in das Backend einarbeite.
Ich hatte dazu schon mal ein Video von euch gesehen, zu den Architekturmuster, allerdings würde ich mir dieses in mehr Umfang wünschen, wo man vielleicht Beispiele zu den Mustern hat.
Hast du vielleicht einen hilfreichen Tipp, wie ich im Backend besser zurecht komme (Verständnisebene, was dort überhaupt passiert)
[gr] Sorry für die späte Antwort … so richtig in die Richtung, was Du suchst, haben wir glaube ich noch nichts. Meine erste Antwort wäre "mach einfach mehr Backend", dann kommt der Rest schon von alleine. Viele Patterns ergeben sich ja daraus, wie man gewisse Dinge baut, einfach weil sich das etabliert hat.
Ich würde sogar sagen, dass die Kernkonzepte gar nicht so großartig anders sind als im Frontend (also so Sachen wie die SOLID-Prinzipien, Kopplung und Kohäsion, Interfaces, … gelten hier wie dort). Dazu haben wir auch einiges:
- SOLID: ua-cam.com/video/3to0t7YQMnU/v-deo.html
- Kopplung: ua-cam.com/video/kWP432pXP-U/v-deo.html
- Interfaces: ua-cam.com/video/5dIff-WXRvM/v-deo.html
Und vielleicht ist eine gute Idee, tiefer in Backend-Technologien einzusteigen, zum Beispiel Node.js:
- In 100 Minuten: ua-cam.com/video/5s7eFzI_fNo/v-deo.html
- Unser großer Kurs: ua-cam.com/play/PL6QrD7_cU23kaZ05MvixcoJ5vctRD1qgC.html
Ansonsten klingt das so, als könnte Dir so eine Art "Roadmap" helfen. Also: Was soll ich alles lernen und in welcher Reihenfolge. Ginge das in die richtige Richtung?
@@thenativeweb Ja, eine Roadmap ist immer sehr hilfreich.
Ich beschäftige mich bereits mit Node.js, da ich als Webentwickler natürlich mit JavaScript/TypeScript vertraut bin.
Ich habe mir z.B. auch das aktuellste Buch aus dem Rheinwerk-Verlag zu Node.js gekauft (aktuell zu Node.js Version 16) und mir fällt auf, dass es selbst dort kein Kapitel zu der Architektur im Backend bzw. Patterns gibt bzw. den Best Practice. Dort wird auch "einfach gemacht".
Ich kenne es aus der Java-Entwicklung ein wenig, dass man viel in diesen "Schichten" denkt. Für so etwas fehlt mir das Verständnis, platt ausgedrückt.
@@dCoder92 [gr] Hm, verstehe … also was wir planen, was vielleicht ein bisschen helfen könnte, ist, dass wir in diesem Jahr ein Projekt entwickeln, was wir auf UA-cam über einige Videos hinweg zeigen und erklären, Frontend wie Backend (beziehungsweise das wird eine Kollaboration mit einem anderen UA-camr, und wir machen das Backend).
Ansonsten glaube ich, dass es wahrscheinlich am sinnvollsten wäre, das mal an einem konkreten Beispiel gemeinsam durchzugehen, weil es eben doch recht schwierig ist, diese Frage(n) pauschal zu beantworten.
Gerade die von Dir angesprochenen Schichten sind in meinen Augen ein sehr überbewertetes Konstrukt (nicht unwichtig, aber bei weitem nicht so relevant, wie Dir gerne glauben gemacht wird).
Falls Du daran Interesse hast, melde Dich gerne mal unter hello [at] thenativeweb [dot] io bei uns, und dann können wir mal schauen, wie wir so etwas angehen könnten.
@@thenativeweb Das ist ein sehr nettes Angebot, danke.
Ich bin allerdings im Moment durch einen Stellenwechsel ziemlich ausgelastet (Frontend-Entwicklung).
Die ganze Backend-Entwicklung ist für mich im Moment noch "Zukunftsmusik".
Aus persönlichem Interesse beschäftige ich mich damit, habe auch bereits eine eigene REST-API unter Node.js / Express.js entwickelt.
Dabei habe ich die ganzen Entscheidungen oft einfach nicht hinterfragt (Ordnerstruktur, Zuständigkeiten, "Schichten" usw.)
Im Moment höre ich sehr oft die Begriffe "Microservices / Micro Frontends" beruflich.
Da ich meiner Meinung nach wenig Erfahrung im Backend habe, wollte ich mich dort mal etwas weiterbilden, um diese ganzen Begriffe besser einzuordnen.
Langfristig möchte ich gerne als "Full Stack-Entwickler" tätig sein und natürlich ist das Wissen von der Serverseite als hauptberuflicher "Frontendler" sehr hilfreich.
Dabei sind mir halt nur die angesprochenen Punkte aufgefallen, dass sehr wenig über die Architektur gesprochen wird bzw. über Muster/Pattern.
Ich verfolge natürlich weiterhin euren UA-cam-Kanal und Beispiele in diese Richtung.
Wenn ich mich tiefer in diesen Bereich eingearbeitet habe,
dann werde ich mich sicherlich mit konkreten Fragen noch einmal melden, so ein Angebot lehnt man natürlich nicht ab.
Ich schreibe auch freie Software und manchmal nervt es mich schon, kein $$$ davon zu kriegen (auch wenn ich durchaus oft eingesetzte Komponenten entwickelt bzw. mitentwickelt habe). Jedoch ist Log4j nicht da drauf zurückzuführen. Log4j hat so funktioniert, wie es sollte. Mit mehr Geld gäbe es evtl. noch mehr Sicherheitslücken dieser Art.
Das ist einfach dem Feature creep geschuldet. Da ist auch kommerzielle Software nicht immun dagegen. Leider tendieren wir dazu immer mehr Komponenten einzusetzen die man unmöglich überschauen kann. Die Softwarekomplexität ist schlichtweg zu hoch. Das ist erstmal vollkommen unabhängig von der Finanzierung.
Log4j hatte keinen "Bug" - solche Features finden eben genug Programmierer toll. Heutzutage ist es ja toll, dass Code von irgendwo kommt, irgendwie zusammengesetzt wird und dann irgendwas tut (oder auch nicht).
Aber gut… ist selten so eine Lücke #1 ist immer noch das C Geraffel mit den Memory Problemen. Grade OpenSource Lücken sind relativ selten - so dass sie ein richtiges Medienereignis sind.
Über irgendwelche Lücken über die Ransomware in Exchange und co. verteilt wird regt sich ja schon keiner mehr auf - ist zu normal. Wenn das was zeigt, dann nur, wie hoch die Qualität der Open Source ist :). Da sind die Sicherheitslücken absichtlich drin.
Gute Darstellung der Thematik! Allerdings wird der Zusammenhang zwischen dem materialistisch-moralischen Aspekt (kommerziell genutzte Open Source Software angemessen zu vergüten) und dem technischen Aspekt (Anzahl und Schwere von Softwarefehlern zu verringern) nicht klar. Die Aussage klingt eher wie "wer bisher nur genommen hat, sollte jetzt nicht jammern". Sicher berechtigt - aber würde ein fairer Umgang miteinander die Softwarequalität verbessern? Ich würde gerne beipflichten, verstehe die Kausalität aber nicht, insbesondere im konkreten Fall Log4j.
[gr] Danke für Deinen Kommentar 😊
Ja, der Bogen ist eventuell nicht so ganz herausgekommen im Video … natürlich ändert ein fairerer Umgang die Qualität nicht direkt, beeinflusst aber indirekt, wie viel Zeit, Aufwand und auch Motivation man in etwas steckt, von dem vor allem andere profitieren. Insofern ist das eher ein indirekter Ansatz.
OpenSource muss staatlich gefördert werden. Man kann da mit sehr wenig Geld, sehr viel sinnvolles tun.
Das Ministerium für Digitalisierung soll einen GitHub Clone bauen und wer dort etwas veröffentlicht bekommt auf Basis der Votes die sein Projekt hat einen entsprechenden Anteil aus dem Fördertopf.
Interessante Idee, aber die Entscheider in Ministerien (Beamte, Politiker) interessieren sich nur sehr begrenzt für Vorschläge von außerhalb. Viel lieber werden einschlägig bekannte Beratungsfirmen engagiert und Treffen mit Lobbyisten vereinbart.
Bravo!
[gr] Danke 😊
Gehe ich eigentlich irgendwelche Risiken ein, wenn ich eine andere Lizenz als MIT verwendet. Bin ich dann als Open Source Entwickler zu irgendwas verpflichtet? Bei der MIT bin ich davon ausgegangen das ich keinerlei Verpflichtungen habe. Sollte ich, aus welchen Gründen auch immer, kein Interesse mehr an dem Projekt haben, dann kann ich bei einer MIT Lizenz garantiert jederzeit aus dem Projekt aussteigen. Ist das bei anderen Lizenzen auch gegeben?
[gr] Einfache Frage, schwierige Antwort … 😉
Also zumindest nach deutschem Recht (und das kann in der Schweiz, in Österreich oder einem anderen Land schon wieder anders aussehen) ist es so, dass Open-Source als Schenkung gilt, und dass Du für etwas, was Du jemandem schenkst, nicht haftest - solange Du nicht grob fahrlässig oder vorsätzlich handelst.
Das heißt, *eigentlich* müsstest Du *immer* aus der Verpflichtung raus sein, solange die Lizenz nicht explizit etwas anders vorschreibt (aber das hast Du durch die Wahl der Lizenz ja selbst in der Hand). Mir persönlich ist keine aus dem Stegreif bekannt, bei der den Entwickler*innen Pflichten auferlegt würden (macht IMHO auch keinen Sinn, da es ja bei der Lizenz um das Einräumen von Rechten und Pflichten für die Nutzer*innen geht).
Im Zweifelsfall würde ich hierzu aber eine Anwältin oder einen Anwalt konsultieren - das Thema ist deutlich komplexer als man als juristischer Laie meint, und im dümmsten Fall ändert sich das ja auch immer mal wieder, wie die Rechtsprechung gerade so aussieht …
“Simplicity is the key to brilliance.” - Lee Jun-fan
[gr] Oh ja - es ist so viel schwieriger, Einfachheit zu erreichen als Komplexität … "Simplicity is the ultimate sophistication." (Leonardo da Vinci, IIRC)
Die Firma wofür ich arbeite unterstützt opensource. Wir sparen dadurch auch irgendwie steuern ein, weil die Arbeitszeit ja eine Betriebsausgabe ist. Wie das aber genau geht weiß ich aber auch nicht.
Meiner Meinung nach verwechselst Du Komplexität und Kompliziertheit.
Komplexität ist eine unveränderliche, abstrakte Größe eines Systems. Sie wird durch seine abstrakte Beziehungen definiert und ist vom Problem abhängig, das durch das System modelliert wird.
Kompliziertheit ist eine Größe eines spezifischen Lösungswegs für das Problem. Kompliziertheit ist zudem eine individuell wahrgenommene Größe.
Deshalb müsstest Du sagen, dass Entwickler gut mit Komplexität und schlecht mit Kompliziertheit umgehen können.
So kann ein und das selbe Problem auf zwei Arten gelöst werden, ohne dass sich die Komplexität des Problems ändert. In einem Fall wird es kompliziert gelöst, im anderen Fall nicht.
Java ist in vielen Fällen zu kompliziert für niederkomplexe Probleme und zu kompliziert für viele Entwickler. Nicht zu komplex.
[gr] Danke für Dein Feedback 😊
Allerdings sehe ich das mit Kompliziertheit / Komplexität genau umgekehrt: Die Kompliziertheit (was für ein Wort …) ist ein Maß für den Schwierigkeitsgrad einer Aufgabe beziehungsweise einer Lösung. Die Komplexität ist ein Maß für deren Umfang.
Beispiel: Es soll eine abs-Funktion geschrieben werden. Eine einfache Lösung, die sich dadurch auszeichnet, dass sie kurz ist, einfach zu verstehende Sprachmittel anwendet, und auch von wenig erfahrenen Entwickler:innen verstanden werden kann, wäre das hier:
const abs = function (number) {
if (number >= 0) {
return number;
}
return number * -1;
};
Das gleiche kann man aber auch sehr kompliziert lösen, indem man statt eines einfachen if das Strategy-Pattern implementiert, das in Abhängigkeit von dem Ergebnis eines AlgebraicSignDiscriminators eine entsprechende Berechnung ausführt und das Ergebnis zurück liefert. Völlig unabhängig davon, dass diese Lösung zugleich auch umfangreicher wäre, wäre sie erst einmal viel schwieriger nachvollziehbar und erfordert für das Verständnis deutlich mehr Erfahrung.
Nun ist es aber nicht immer so, dass eine kompliziertere (schwierigere) Lösung zugleich auch länger sein muss. Gerade, wenn man versucht, Code möglichst kompakt zu schreiben, so wenige Bytes wie möglich zu verwenden, wird er häufig zwar kürzer, aber trotzdem schlechter verständlich.
Die Kompliziertheit gibt also den Schwierigkeitsgrad an. Das passt auch der Erklärung im Wörterbuch, zum Beispiel in Wiktionary (siehe de.wiktionary.org/wiki/kompliziert):
"Subjektiv erscheint etwas als kompliziert, wenn man nicht über das Wissen, das Können, die Intelligenz oder die Bereitschaft verfügt, es zu verstehen oder zu beherrschen."
Als Bedeutungen werden angegeben: umständlich, undurchschaubar, schwierig, verzwickt, verstrickt
Komplexität ist aber etwas anderes: Komplexität entsteht durch die schiere Größe einer Lösung und die dieser Lösung innewohnenden Abhängigkeiten: Wenn man an einer Stelle etwas ändert, ändern sich (ungewollt) zig andere Stellen mit. Man verliert den Überblick. Das liegt aber nicht an den Fähigkeiten oder der Intelligenz, sondern an der fehlenden Möglichkeit des menschlichen Gehirns, mehr als ein paar Sachen zugleich zu verarbeiten.
Da es in größeren Lösungen häufig mehr Abhängigkeiten gibt und sie vielschichtiger sind, sind die in der Regel auch komplexer. Auch das passt zum Wörterbucheintrag (siehe auch hier Wictionary, zB de.wiktionary.org/wiki/komplex), was als Bedeutungen hat: verflochten, zusammenhängend, umfassend, vielschichtig
Java fördert nun Kompliziertheit nur bedingt, denn auch in Java kann ich zB oben genannte einfache abs-Funktion schreiben (auch wenn die Syntax etwas anders aussieht, aber sinngemäß). Um das machen zu können, brauche ich aber wahnsinnig viele Sprachmittel: Eine Klasse. Eine Methode. Zugriffsmodifizierer. Eventuell das Schlüsselwort static. Void. Imports. Und, und, und.
Das siehst Du sehr schön, wenn Du mal ein Hallo-Welt-Programm in Java mit einem in zB Python vergleichst. 10 Zeilen gegenüber 1 Zeile. 20 Sprachkonstrukte gegenüber 1 Sprachkonstrukt.
public class HelloWorld {
public static void main (String[] args) {
System.out.println("Hello world!");
}
}
ist nicht nur komplizierter als
print "Hello world!"
es ist auch deutlich komplexer. Und dann die Ausführung. Das JDK, javac, java, der Classpath, … um 10 Buchstaben auf den Bildschirm zu bringen?! Vergleich das mal mit:
python helloworld.py
Und das zeigt, finde ich, ziemlich gut, warum Java Komplexität fördert: Weil alles in Java von Vornherein auf Komplexität ausgelegt ist. Man schreibt keinen "einfachen" Code. Nein, man baut in nJava allzu bereitwillig eine AbstractProxyFactoryImpl, und erklärt, das sei "normal", weil Enterprise-Entwicklung eben anspruchsvoll sei. Und das färbt ab, auf die Art, wie man dann selbst entwickelt.
Man züchtet sich auf dem Weg ein künstlich komplexes, umfangreiches, unübersichtliches und völlig überfrachtetes Ökosystem heran, statt das Nächstliegende zu tun, statt eine => einfache
👍
Ich schreibe auch Open Source Software und meine Standard-Lizenz ist MIT. GPL oder AGPL nutze ich nicht und habe es auch nicht vor zu nutzen. In der Regel deckt die Software meine eigenen Probleme und Belange ab und nach mir die Sinnflut.
Sollte es mal doch passieren das jemand tatsächlich meine Software nutzt und Features vermisst, soll entweder diese selbst implementieren oder bekommt von mir entsprechend ein Angebot.
Die Software ist vielleicht kostenlos aber meine Arbeit, nicht.
[gr] Danke für Deinen Kommentar 😊
Gerne :) Ich hoffe es kommt nicht allzu negativ rüber. Aber das ist letztendlich auch das, was ich von anderen Entwicklern die Open Source Programme schreiben, gelernt habe ^^
Dennoch träumen nicht wenige vom gewissen finanzellem Reichtum :D Ich auch.
@@heinrichschiller4673 [gr] Keine Sorge, alles gut 😊
"Ich bin zwar kein Java Entwickler, aber... " 😁
Zu log4j: Die Appender Idee ist über 20 Jahre alt. 12 Faktor war damals noch nicht mal ne Idee. Zudem muss keiner diese heute nicht mehr sinnvollen Appender nutzen.
Außerdem ist log4j schon lange nicht mehr der Logging Standard.
All das weiß aber ein vernünftiger Java Entwickler 😋
In diesem Sinne wollte ich meine 2 Cent dazu geben. Danke, schon passiert! Glückwunsch für die knackigen Videos, kurz und auf den Punkt gebracht. Ich blicke jetzt auf 40 Jahre IT Erfahrung zurück und könnte über diese hier angerissen Themen, stundenlang referieren. Deshalb nur angerissen: Java Loggign Standard ist java util logging. Log4j in seiner ersten Version kam früher auf die Welt. Open Source ist nicht nicht gleich Open Source, ist gibt erhebliche Qualitätsunterschiede. Viele Java Apache Projekte sind alt, werden nicht selten in der Freizeit entwickelt und sind von schlechter Qualität. Das kritisierte Feature von log4j V2 wurde in der Entwicklerrunde diskutiert und fand trotz bekannter Sicherheitsmängel den Weg in die Codebasis, was einfach darin liegt, WER das in letzter Instanz entscheidet. Die GPL hat gravierende Schwächen, von Richard Stallman gut gemeint, aber wenig praxistauglich. Als C++ Entwickler verwende ich Java gerne. Ich empfinde die Sprache weniger komplex. Kann jedoch gut nachvollziehen, dass das ein NodeJS Entwickler anders beurteilt.
> Open Source maintainers owe you nothing.
Das kann man so nur unterschreiben.
Java ist ein schönes Anti-Pattern - geht in die Richtung einer esoterischen Programmiersprache wie "Shakespeare"
Ich sehe die von dir angesprochene „Gegenleistungs-Idee“ für Open Source nicht so zielführend.
Wenn ich Source veröffentliche, geht es mir darum, dass das auch verwendet wird da sind GPL Lizenzen einfach ein Show-Stoper.
"open source ist kostenlos", genau genommen heißt es auf deutsch: "offene quelle", nicht gratis, umsonst, geschenkt.
[gr] Ja, das ist das übliche Missverständnis. Deshalb betont sie FSF bei „freier Software“ ja auch immer „free as in speech, not free as in beer“.
Ich benutze Open source, mein wille Opensource zu unterstützen ist Open Source zu benutzen um andere Open Source software zu erstellen, genug geld um das zu fördern hab ich leider nicht :(
Steht ja in der OpenSource-Lizenz: Haftung ausgeschlossen. Am Ende haftet jeder einzeln für sein eigenes Produkt.
Warum Open-Source kaputt ist. Warum dieser reißerische Titel?
Also dass die Entwickler von Log4J hier Bockmist gebaut haben steht doch außer jeder Frage, und ob dieser Fehler nicht passiert wäre, wenn viel Geld geflossen wäre stelle ich mal in Frage! Ist Open-Source wirklich immer kostenlos? Also hier passt so einiges in diesem Video nicht, auch wenn ich die Gedankengänge verstehe und größtenteils sogar teile. Für kostenlose Software auch mal etwas spenden!! Auf jeden Fall!! Das mehr Geld bessere Qualität bedeutet? Auf keinen Fall, da gibts genügend Beispiele. Das ein Bug in Open-Source das Ende von Open-Source bedeutet? Hallo?