Ist Open Source gefährlich? - podcast episode cover

Ist Open Source gefährlich?

Jan 11, 202439 min
--:--
--:--
Download Metacast podcast app
Listen to this episode in Metacast mobile app
Don't just listen to podcasts. Learn from them with transcripts, summaries, and chapters for every episode. Skim, search, and bookmark insights. Learn more

Episode description

Willkommen bei den Coding Buddies! In der neuen Folge sprechen wir über Open Source Software und welche Vor- und Nachteile es dabei geben könnte. Hat dir die Folge gefallen? Dann folge uns doch zusätzlich auf unseren anderen Plattformen oder schau auf unserer Website vorbei: Discord: https://discord.gg/C2Zntw6Sq4 Instagram: https://www.instagram.com/the_coding_buddies Youtube: https://www.youtube.com/@thecodingbuddies Twitch: https://www.twitch.tv/thecodingbuddies TikTok: https://www.tiktok.com/@thecodingbuddies Du hast Feedback für uns? Kontaktiere uns doch per Mail: [email protected]

Transcript

Also wieso sollte ich denn jetzt zum Beispiel mich hinstellen und sagen, komm, ich mach das Open Source, was bringt mir das also weißt du, das ist ja vielleicht auch ne Frage, die vielleicht im Raum steht. Dein Podcast rund um Softwareentwicklung und aktueller Technews. Herzlich Willkommen. Halli Hallo und herzlich Willkommen zur neuen Folge vom Coling Buddies Podcast. Wir sind natürlich wieder da, der Fabi, das bin ich und Tino, der ist auch dabei. Tino, Grüß dich.

Halli Hallo Fabi, Was geht ab? Tino Na Mensch, schön, dass wir uns hier wieder hören. Gut halten. Coding Buddies Podcast Es ist mal wieder soweit. Neue Folge, Neue Folge, neues Glück? Genau, und ich würde sagen, ich steig gleich mal ein, lass uns gar nicht so lange fackeln. Und zwar haben wir in der letzten Folge oder beziehungsweise da hattest du mal in den Raum geworfen, so ein bisschen als Challenge sozusagen, dass man sich selber fragen soll.

Wieviel oder wie oft man sich denn vielleicht auch anderen Code anguckt, also Code von anderen Leuten, nicht seinen eigenen, sondern einfach mal guckt, wie ist anderer Code aufgebaut beziehungsweise auch professioneller Code vielleicht. Also es kommt natürlich immer darauf an, welchen Code man sich dann im Endeffekt anguckt. Ja ach so, du meinst wegen.

Das als Übung zu betrachten, sich mal von anderen Codern entwickelten Code anzuschauen, um so auch Best Practices quasi zu erkennen oder für sich mitzunehmen. Genau da bist du jetzt gerade. Und da ist mir zum Beispiel so ein bisschen eingefallen, okay wann also was für anderen Code guckt man sich denn eigentlich an? Und da bin ich halt einfach auf Open Source gekommen und das ist eigentlich genau der Punkt, über den wir heute mal vielleicht ein

bisschen sprechen wollen. Und zwar, was ist Open Source und auch ein bisschen die Frage beleuchten, ist Open Source eigentlich unsicher, weil wir können ja gleich mal darauf eingehen, was open Source ist. Aber prinzipiell ist es ja so, wenn du dir andere Repos oder anderen Code anguckst, dann ist das ja meistens jetzt vielleicht nicht gerade der Code von der Nachbarabteilung nicht unbedingt, oder also bzw das haben wir in dem Moment nicht gemeint, oder?

Von deinem Kumpel. Sondern im Endeffekt ja wirklich Code, der irgendwo auf öffentlichen Repositories hängt. Und da kommt man halt im Endeffekt zwangsläufig auf Open Source und deswegen wollt ich dich jetzt einmal, möcht ich jetzt mal direkt eine Frage an dich weiterleiten oder dich sozusagen zum Einstieg in die Folge motivieren. Was ist eigentlich Open Source? Was ist eigentlich Open Source?

Ja, also allgemein kann man ja sagen, ist also oder ursprünglich sag ich mal so ist Open Source ja definiert als öffentliche Software, die wo der Quellcode einsehbar ist, veränderbar ist. Natürlich. Nutzbar dann quasi für jedermann, sag ich mal. Also mal angenommen man entwickelt irgendwie ne coole Library, die ein Problem löst und denkt sich ach ja, das das ist wirklich ne coole Lösung und das können ruhig andere nutzen,

die einen eben. Gleiches Problem haben oder auch auf diese Problematik treffen könnten. Dann können Sie quasi meine entwickelte Software nehmen oder diese Code Schnipsel sage ich mal. Um das Problem für sich zu lösen, also sie können es halt weiter verwenden. Ja und halt im klassischen Open Source Sinne auch mit dran entwickeln oder beispielsweise Verbesserungsvorschläge geben, naja. Genau, weil sie. Sehen ja den Code und können ja zum Beispiel sehen, wie etwas implementiert ist.

Und dann zum Beispiel ja, da verschiedene Plattformen so was wie github bieten, daher auch Mechanismen, dass du so Issues aufmachen kannst und dann einfach reporten kannst. Im Prinzip auch, wenn du zum Beispiel Bug findest. Auch ein ganz spannender Punkt, da könnte man vielleicht auch

mal drüber reden. Wenn du sagst, ja, ist cool, was du gemacht hast, also wie jetzt von der anderen Seite aus, nicht vom Entwickler her, aber mir ist aufgefallen, bei der und der Funktion da da ist ein Bug drin, da stimmt was nicht. So, und das ist für mich, sag ich mal so, die klassische Open Source Anwendung oder Definition.

Genau. Also wenn wir jetzt mal sagen, OK, wir haben jetzt zum Beispiel, es gibt vielleicht n Entwicklerteam, die privat oder auch in aus einer Organisation heraus sagen okay, ich möchte jetzt einen bestimmten Quellcode zu einem bestimmten Problem entwickeln beispielsweise und möchte diesen Code auch anderen Leuten zugänglich machen. Dann kann man natürlich sagen okay, es gibt ein öffentliches Repository, nutzt diesen Code und entwickelt quasi eure

Software damit weiter. Bzw wenn man jetzt zum Beispiel sagt okay ich möchte. Sagen wir mal ein Video irgendwo einbetten in meine Anwendungen oder so, dann gibt es vielleicht irgendwie ein Plugin, was einem hilft, was quasi von irgendwem entwickelt wurde, dass man das Problem nicht noch mal lösen muss, sondern dass man sagen kann okay, ich benutze das

einfach so weiter. Und kann natürlich auch öffentlich darauf einsehen, also öffentlich diesen Code einsehen, das ist ja auch Open Source, du musst es auch nicht kaufen. Diese Software, um die zu verwenden und kannst auch wie du ja meintest das weiterentwickeln. Ne also beziehungsweise könnte man ja jetzt auch sagen na gut, was heißt denn jetzt weiterentwickeln? Also du hast jetzt n repo und jeder kann also was bedeutet

das? Ne heißt das jetzt du hast n repo und jeder kann ja im Endeffekt. Wild seine Änderungen, wie er möchte oder wie sie möchte, dann im Endeffekt da committen und pushen und das klingt für mich dann in dem Fall würde das ja alles drunter und drüber gehen, oder wie funktioniert? Das ja.

Deswegen habe ich auch gesagt, im klassischen theoretischen Sinne. Oftmals kann man das ganze ja auch noch mal unterscheiden zwischen klassisch Open Source, das heißt, ich kann mit dran entwickeln oder Vorschläge machen oder zum Beispiel per Pull request dann. Vorschläge machen, Änderungen zeigen, die dann entweder angenommen werden oder nicht. Das ist, so sag ich mal, der klassische Weg. Aber man kann auch unterscheiden und sagen, dass die Software einsehbar ist, aber nicht

veränderbar. Also ich kann es verwenden und mir den Code auch anschauen, wie es gelöst wurde, habe aber jetzt nicht sage ich mal die Rechte daran da aktiv mitzuwirken.

Also ich finde, dass das muss man da auch noch mal ein bisschen differenzieren, auch wenn das sage ich mal unter Open Source fällt, aber ich würde da halt schon differenzieren zwischen es ist öffentlich einsehbar und ich kann es verwenden und ich kann wirklich aktiv dran mit entwickeln, dass es halt quasi eine coder Community gibt, die zusammen Patches entwickeln zum Beispiel. Finde ich auch ganz gut.

Das so zu sehen also was mir halt zum Beispiel einfällt, ist ja npm Libraries oder so, die kannst du ja beispielsweise im Node Kontext, die kannst du ja verwenden unter Umständen aber. Nicht unbedingt. Sozusagen auf diesem Repo verändern. Also du kannst theoretisch auch dieses Repo auschecken und damit selber auch, also du kannst es ja auch verändern, um deinen eigenen deine eigene Version davon zu erstellen, aber es ist ja nicht immer so, dass du auch

wirklich. Bei jeder Sache, bei jedem Repo oder bei jedem Modul oder wie man es nennen möchte, auch wirklich aktiv mitarbeiten kannst. Aber es ist natürlich möglich. Also diese Unterscheidung ist da schon wichtig. Und wenn wir schon bei dem Punkt sind, was darf man, was darf man nicht, muss man natürlich auch in dem Zuge erwähnen, dass es ja meistens lizenziert ist. Die Software und es da verschiedene Lizenzmodelle gibt, die auch quasi sage ich mal vorgefertigt sowie ein Template

sind, die man verwenden kann. Ja, zum Beispiel mit Lizenz ist ja auch gängig und in diesen Lizenzen ist ja auch geklärt, was erlaubt ist und was nicht. Deswegen finde ich, ist auf wichtig. Wenn man weiß, wofür man Fremdcode oder öffentlichen Code nimmt, zu wissen, unter welchem Lizenzmodell das fällt, also wie es lizensiert ist, ist ja auch n spannendes Thema, vielleicht auch mal für ne Extrafolge, weil das ist ja auch n großes Feld, aber.

Im Prinzip, wenn man, wenn man n Open Source Projekt hat, kann man über Lizenzen ja auch definieren was erlaubt ist und was nicht. Genau. Also was auf jeden Fall zum Beispiel gesagt sein kann, hier mal an der Stelle ist, dass zum Beispiel so sogenannte MIT Lizenz, die es halt im Normalfall relativ light White, also du kannst quasi im Endeffekt ne Menge damit machen, eigentlich alles im groben und ganzen jetzt vielleicht nicht wirklich alles, also man sollte sich auf jeden Fall mal genau

nochmal die Lizenz durchlesen. Aber wie gesagt, das ist auf jeden Fall meistens unbedenklich zu benutzen. Aber lass uns darüber wirklich vielleicht mal eine eigene Folge machen im Punkt Lizenzen, weil das ist ja echt ein Riesenthema, aber wenn wir uns jetzt das Ganze noch mal angucken und sagen okay, wir haben jetzt einen Open Source Projekt und

können. Keine Ahnung, du kannst anderen das zur Verfügung stellen, andere können das benutzen, das ist ja irgendwie, klingt ja sehr, sag ich jetzt mal gönnerhaft, dass man sagt, Ey, Mensch, ich hab mir hier was entwickelt. Nutz das doch einfach und wir

wollen dafür nichts haben. Das ist ja sehr selbstlos und im Endeffekt kann ich mir auch vorstellen, dass zum Beispiel auch unternehmen sich vielleicht denken, na ja, wieso soll ich denn jetzt zum Beispiel, ich sag mal in Anführungsstrichen firmengeheimnisse irgendwie rausgeben, mit einem mit einer Open Source Software. Das mache ich doch lieber

proprietär. Das heißt einfach sozusagen meine eigene Software, die unter Verschluss gehalten wird, und die kann man dann vielleicht irgendwie mit einer bestimmten, für bestimmte Kosten eben sozusagen so ein Modul erwerben. Also wieso sollte ich denn jetzt zum Beispiel mich hinstellen und sagen, komm, ich mach das Open Source, was bringt mir das, also weißt du, das ist ja vielleicht auch eine Frage, die vielleicht im Raum steht. Was meinst du?

Ja, ist n spannender Punkt. Ich finde wir sollten da vielleicht mal das in 2 Teile teilen damit es n bisschen verständlicher ist und zwar einmal aus der Sicht, die du ja gerade angefangen hast des Unternehmens oder des Entwicklers, warum sollte ich als Unternehmen oder Entwickler etwas Open Source machen, also wirklich öffentlich zur Verfügung stellen und dann würde ich auch gern mal die andere Seite betrachten, warum sollte ich open Source verwenden?

Ja welche vor und Nachteile gibt es dabei? Da kommen wir, glaube ich, relativ schnell zu unterschiedlichen Punkten. Das würde ich ganz spannend finden. Und deswegen lass uns mal anfangen mit. Wir sind jetzt auf der Seite der der Entwickler und wollen. Überlegen jetzt. Wir haben ganz coole Software geschrieben und ein Modul der Software zum Beispiel ist wirklich eine coole Lösung für einen sehr generelles Problem und überlegen jetzt, ob wir das

Open Source auslagern. Also dass wir sagen, OK, das ist öffentlich jetzt verwendbar, ja, welche vor und Nachteile siehst du da? Also soll ich anfangen oder möchtest du einfach mal n Punkt raushauen? Ja, ich kann einfach mal gerne anfangen. Also was, was mir da direkt in den Kopf kommt ist natürlich, wenn du jetzt zum Beispiel angenommen, keine Ahnung, sagen wir mal, wir beide überlegen uns irgendwas cooles und sagen, ey,

das wär ja irgendwie. Nicht schlecht, wenn man jetzt sich hinstellen würde und sagen würde, wir brauchen diesen Teil von Code und den wollen wir aber irgendwie auch pushen. Ne, also wir wollen ja quasi, dass dieser Code teil auch irgendwie vielleicht schneller wächst. Dann hast du natürlich über Open Source die Möglichkeit, dass du im Endeffekt natürlich noch mehr Leute ins Boot holen kannst, die

sich dafür interessieren. Das heißt, du kannst natürlich schon schaffen, dass deine deine Software oder dein Softwarepaket ein Softwaremodul, wie wir es auch immer nennen wollen, hat. Viel, viel schnelleren Wachstum hat weil halt einfach viel mehr Leute, die sich eben dafür auch interessieren, daran mitarbeiten können und ihre eigene Arbeit mit einfließen lassen können. Also das ist zum Beispiel eine Sache, die aus Entwicklersicht zum Beispiel mir als Erstes eingefallen wäre jetzt.

Also im im klassischen Sinne von Open Open Source. Dass sie auch das Leute mit dran entwickeln können. Also das ist nicht nur einsehbar ist. Ja, ja genau, genau. Also das wäre für mich auf jeden Fall als Entwickler beispielsweise schon wichtig, weil also. Wenn wenn ich jetzt als Entwickler sich darauf gucke, würde ich natürlich auch wollen, dass andere mitentwickeln und quasi das ganze vorantreiben, weil ich möchte ja, dass diese Software wächst.

Ja, bin ich ganz bei dir. Ich find da passt auch mein Punkt ganz gut rein, weil das quasi so einhergeht. Damit ist natürlich auch, dass ich. Weil du meintest man sich so ne Fanbase quasi aufbaut man ja auch n gewisses Standing damit aufbauen kann, weil ich zeige was ich gecoded hab. Ich zeige quasi auch die Qualität meines Software Moduls nenne ich es mal.

Wenn ich jetzt nur so ein Teil zum Beispiel öffentlich mache und kann mir ja dann Entwickler oder kann damit Entwickler für mich gewinnen die das cool finden, verwenden wollen und weiterentwickeln wollen und. Kriegt, wie soll ich sagen, so eine Art Prestige, vielleicht auch für mein Unternehmen, dass es halt für Qualität steht, was da entwickelt wird, weil du, du packst ja die Karten auf den Tisch, das klingt immer ein bisschen blöd, aber es ist ja auch nicht so.

Ja gut, dann guckt euch halt an, was ich hier mache, sondern da gehen auch gewisse Verantwortlichkeiten mit einher und. Ja, also das ist halt öffentlich dann. Das heißt, wenn da Schwachstellen drin sind, dann können die gefunden werden, was gleichzeitig auch wieder ein Vorteil ist. Wenn du sagst, ich packe es öffentlich und Leute sagen.

Mal auf an der und der Stelle, da ist ne Schwachstelle in der Software, dann hilft dir das ja natürlich auch deine Software zu verbessern und die Qualität zu steigern. So kann man das ja auch betrachten, aber es ist halt in

dem Moment öffentlich einsehbar. Ja. Ja, das stimmt, das stimmt, aber da ist man natürlich, also bist, da bist du ja schon n bisschen gut, kannst natürlich so deinen eigenen Prestige steigern, das kannst du natürlich jetzt aber auch auf Unternehmenssicht quasi Münzen und sagen, ne. Guckt mal ne was wir hier quasi machen, ne?

Genau. Also wenn jetzt Firma XY sagt, Wir haben hier echt n geiles Produkt, das kommt in einem halben Jahr auf den Markt und du schmeißt halt Teile von von vielleicht von irgendeinem coolen Algorithmus, den du da entwickelt hast, quasi in ein öffentliches Repo und die Leute merken, ey, das ist ganz schön geil, was da gemacht wird und das ist jetzt aber auch nur ein Bruchteil von dem, was da kommt, dann kannst du dir wahrscheinlich einfach auch

schon eine coole Community aufbauen, so muss man das ja auch mal sehen und nicht. Nee, das alles meins. Und ich will das jetzt nicht zeigen, so nach dem Motto. Ja, gerade. Also ich find, dass das kann man schon so. Betrachten gerade aus Unternehmenssicht beispielsweise hast du natürlich auch schon unter Umständen eine gute Kosteneffizienz, weil du halt

eben auch zusätzlich. Andere Leute hast die eben dran mit entwickeln, ohne dass sie jetzt quasi jetzt mal blöd gesagt, entgeltlich dafür bezahlt werden müssen, weil Leute halt einfach aus Interesse daran mitarbeiten können. Also. Das natürlich ein zweischneidiges Schwert. Das kann gut laufen, aber du hast natürlich auch ne gewisse Verantwortung für dieses Repo, das zu maintain und alles und da wirst du natürlich auch. Entwicklungsleistung abdrücken müssen von der eigentlichen

Entwicklung dann allein. Dafür ist zu maintain, was ja im Endeffekt wieder in das Produkt einfließt. Angenommen, da kommen jetzt 10 Entwickler und sagen ey und Reporten halt so 2030 issues mit Bugs, dann kostet dich das ja Zeit. Andererseits kannst du sagen ja okay aber diese Bugs hätten wir auch selbst finden müssen erst mal und können jetzt die Qualität wieder steigern. Also das meine ich halt so mit zweischneidigen Schwert, es kostet dich einerseits zusätzliche Energie.

Das zu Maintain und du diese Verantwortlichkeit für das Repo zu übernehmen. Andererseits wenn du keinen Input kriegst von anderen Entwicklern bringt dich das ja auch vorwärts. Ja, es ist halt wirklich ein Trade Off von der Stelle. Wie du schon meintest. Es kann natürlich guter Code oder gute Ideen können mit einfließen. Den, die du vielleicht auch 7

musst. Auf der anderen Seite kann es auch sein, dass du halt, also du hast natürlich diesen Aufwand, den du an dieser Stelle betreibst, wo du sagst, OK, ich muss jetzt differenzieren, zwischen welcher Pull request ist wertvoll und welcher ist nicht wertvoll beispielsweise und. Diesem wertvolle Pull request hätte ich eventuell auch selber implementieren müssen.

Ne, also das sind natürlich Zeit Aufwände die auf der einen oder der anderen Seite zum Tragen kommen und da hängt es natürlich an der Stelle auf jeden Fall von der Community sozusagen ab, die mit daran mitentwickelt. Auf der anderen Seite, was auch noch n Trade off ist, ist zum Beispiel das, was ich auch am

Anfang gesagt hatte. Ich finde das ist n sehr sehr häufig genannter Punkt ist zum Beispiel das oder hab ich auf jeden Fall schon häufig gehört, dass man sagt, so Open Source Software ist zum Beispiel nicht sicher, weil man ja zum Beispiel sagt, Ja jeder kann da irgendwie mit dran rum arbeiten und das ist ja irgendwie blöd. Und das ist ZB auch so ein Punkt, weil ich den jetzt gerne einmal so mit ins Boot ziehen möchte. Den man natürlich auch nicht

unbedingt so sehen kann. Also ich würde auch wieder sagen, es ist ein zweischneidiges Schwert oder ein Trade off, weil auf der einen Seite ist es natürlich so, dass dein Code komplett einsehbar ist im Open Source, also als wenn du den als Open Source hast, was natürlich bedeuten kann, dass andere Leute, die vielleicht Sicherheitslücken finden, diese Sicherheitslücken ausnutzen können.

Erfahrungsgemäß ist es aber auch so, dass dadurch, dass du eine Community hast und je größer deine Community ist, desto schneller werden noch gleichzeitig diese Sicherheitslücken erkannt. Reported. Das heißt, du kannst natürlich sehen, OK, vielleicht habe ich eine Sicherheitslücke, die. Erkannt wird und ausgenutzt wird. Aber vielleicht habe ich auch eine Sicherheitslücke, die erkannt wird und super schnell

gefixt wird. Ne, also vergleichen wir das jetzt mal mit proprietärer Software wo man sagt Okay, du hast vielleicht eine Sicherheitslücke Monitors observed was auch immer deine Anwendung sehr schlecht und es wird eine Sicherheitslücke entdeckt und die Entwickler oder Entwicklerinnen die an dieser Software arbeiten wissen nicht von dieser Sicherheitslücke, dann kann es durchaus unter Umständen sein, dass diese Sicherheitslücke sehr lange offen ist. Und das ist natürlich dann.

Finde ich entkräftet n bisschen das Argument zu sagen Open Source Software ist nicht sicher. Also wie siehst du das? Ja, gehe ich auf jeden Fall mit. Ist ein ist wirklich ein guter Punkt und da spielen auch noch

so andere Faktoren mit rein. Zum Beispiel ist es ja nicht nur können Sicherheitslücken aufgedeckt werden, sondern auch das Firmware oft sich denken, das ist doch jetzt aber unsere Idee, die wir verkaufen wollen oder unser Produkt, unser Know How innerhalb der Firma, dass wenn wir das jetzt öffentlich machen, dann kann das ja geklaut werden.

Also du hast einerseits, sage ich mal oder diese Bedenken oft bei Entwicklern und Firmen, dass sie sagen, okay Sicherheitslücken können auffallen und ausgenutzt werden, das finde ich, hast du aber gut erklärt, dass du ja in der Community auch Leute hast, die sagen, hier ist eine Sicherheitslücke. Reporten das und dann kannst du es fixen. So würdest du es nicht finden und vielleicht würden trotzdem die Anwender am Ende diese Sicherheitslücke sehen und ausnutzen.

Also wie sage ich mal Leute die böse gesinnt sind, sage ich mal und das missbrauchen. Wollen böse. Leute, die bösen, bösen Entwickler. Und andererseits halt immer dieser, dieser Gedanke von Ey. Nee, wenn wir das rausgeben, dann wird die Konkurrenz unsere Idee klauen, und das finde ich halt auch spannend. Das Thema Ich verstehe den Gedanken. Also ist nicht so, dass ich das jetzt komplett abtun möchte.

Ich verstehe das und das muss abgewogen werden, aber mal angenommen, du bist jetzt n Startup, du hast legst komplett von vorne los, dann wirst du ja irgendwann diese Idee bewerben. Ja, so. Und dann bist du aber noch an den Anfängen und hast vielleicht 2 Entwickler, 3 Entwickler. Vielleicht bist du auch alleine so was soll da jetzt schon an groß an an Menge an Software rumkommen? Ich mein ein Entwickler der kann jetzt auch nicht die Welt

bewegen. Ja. So, das heißt, du Bewirbst da die Idee und dann kommt irgendwie n Big Player und sagt geile Idee, ich leg jetzt, ich hau jetzt meine 100 Entwickler da drauf, die machen das in 2 Monaten haben die den anderen eingeholt und in 3 Monaten sind wir weit an ihm vorbei. Kannst du nicht verhindern. Spätestens wenn du die Idee ja öffentlich trägst, kannst du es ja nicht verhindern, dass jemand denkt ist cool, mach ich

ähnlich. Ja. Und das ist auch n guter Punkt. Mach ich ähnlich, dann kannst du es, dann kannst du gar nichts machen. Ne so, und das ist der eine Punkt und der andere Punkt ist, wenn du schon so n Riesenunternehmen bist, dass du, dass das so ne riesen Software ist und du da ein Teil von Auslagerst, dann kann ja keine anderer sagen OK, ich hab jetzt hier 3 Entwickler haha jetzt werden wir das mal schön

nachbauen. Ich meine, wie viele Jahre sollen die denn daran entwickeln, weißt du, und um quasi den Rang abzulaufen von diesem etablierten Unternehmen. Also da verstehe ich halt manchmal einfach nicht, wovor man Angst. Hat also im Endeffekt sagst du jetzt quasi okay, wenn du wenig Manpower hast.

Dann ist es schon sinnvoll, eventuell eine geile Idee als Open Source zu machen, weil du halt einfach viel mehr Unterstützung von außen hast, dass du quasi deine Software kann, viel schneller wachsen an dieser Stelle genau. Das ist halt ein Punkt und es muss ja nicht die gesamte

Software sein. Es kann ja wirklich nur so ein Key Punkt sein, dass du sagst, guck doch mal, wie geil das ist, was wir hier machen und andere können das Nutzen und auch geile Sachen erschaffen und dadurch werden sie dir später keine Kunden abnehmen oder so. Das ist auf jeden Fall. Eigentlich da n bisschen naiv dran, aber im Endeffekt ich mein jemand der der den Markt bestimmen will oder da wo du dein Produkt platzierst, der wird das auch tun, wenn du es

nicht open Source machst. Spätestens wenn du mit dem mit der Sache auf den Markt gehst und er sagt gut in 2 Monaten haben wir das auch. Ja, also es ist natürlich immer die Frage an wer, also was du gerade entwickelt. Es kann ja durchaus sein, dass du zum Beispiel irgendwo eine komplett neue Erfindung hast, eine sehr innovative. Erfindung, die du oder eine innovative Idee, die du

irgendwie etablieren möchtest? Dann ist es natürlich immer die Frage okay ist es jetzt sinnvoll, das zu machen oder nicht? An der Stelle würde ich sagen, natürlich macht das schon Sinn, weil du halt mehr Leute hast. Du kannst deine Software schneller wachsen lassen.

Wenn du jetzt zum Beispiel aber auch keine Ahnung angenommen, also wir sind irgendwie noch unterschiedliche Sachen, weil wenn du jetzt zum Beispiel sagst, also man kann an dieser Stelle tatsächlich überlegen, möchte man das oder nicht, weil es hat halt, wie gesagt, es ist nicht immer nur ein ja oder

nein. Der Stelle, sondern man muss es abwägen, wo ich relativ schnell sagen würde, das ist n auf jeden Fall macht man das Open Source, warum auch nicht, ist zum Beispiel wenn du sagen wir mal dich in einem Sektor vielleicht etablieren möchtest, der vielleicht schon.

Existiert ne und du möchtest quasi mit in diese in diese Schiene. Also du möchtest quasi dazwischen mitspielen und es gibt das Rad nicht neu zu erfinden, aber du weißt, dass du Sachen wirklich sehr sehr gut machen kannst und du weißt vielleicht auch, dass du bestimmte Sachen weiß, nicht, dass du vielleicht selber eigene Best Practices entwickelst und musst vielleicht sozusagen allen zeigen oder willst allen zeigen, guck mal Leute, wir haben das

sogar technisch drauf, also angenommen, das sind vielleicht auch sicherheitskritische Sachen, die da passieren müssen, dann ist es ja vielleicht durchaus sinnvoll zu zeigen, guckt mal Leute, wenn ihr auf. Service setzt, das ist unser Code. Guckt euch den an, der ist gut, der ist der der funktioniert und da da kannst du ja auch Vertrauen gewinnen um zu zeigen, OK, das ist jetzt vielleicht ne Software und alle können das nachmachen, aber was ist denn

das Problem? Erstens gewinnst du vielleicht Kunden dadurch, dass weil die Kunden sagen okay, ich stecke wirklich ein hohes Vertrauen in das, was ich da sehe und zum anderen machst du den Rest der Welt auch sicherer, weil andere vielleicht von dir lernen können und sagen können, ach so, geht sicher, also hast du damit ja quasi vielleicht auch bestimmte Sicherheitsstandards, kannst du vielleicht schaffen oder

etablieren. Also das sind auf jeden Fall, da würde ich schon sagen, das macht irgendwie Sinn, obwohl es bestimmt auch wieder Leute gibt, die sagen. Aber warte mal ganz. Kurz. Warte mal. Das ist ja das, was wir ganz am Anfang noch schon gesagt hatten, einfach Prestige sozusagen

aufzubauen. Dass man dein Unternehmen zumindestens anfangs in in so einem kleinen Coderkreis mit dem Prädikat geile Software. Belegt und dass, dass du einfach für Qualität stehst und das ja dann auch andere Unternehmen mitkriegen und vielleicht ein bisschen ideologisch auch schwieriges Wort, aber auch wichtiger Punkt ist. Was wäre denn, wenn die letzten Jahre niemand etwas Open Source gemacht hätte? Wo wäre der Gesamtentwicklungsstand und wo ist er jetzt Realität?

Also in der Realität, wo man sagt okay ich share meine Software und verwendet sie, entwickelt sie weiter und lasst uns zusammen was geiles machen, das finde ich ist auch ein wichtiger Punkt, wenn jeder für sich in seinem Kämmerchen entwickelt und dann nur noch irgendwie was zeigt was du kaufen kannst oder halt Black Box mäßig verwenden kannst. Das würde ja auch die gesamte Entwicklung der der Welt, sage ich mal, der Titel der Technischen Welt, oder?

Also das ist auf jeden Fall ein schönes Gedankenexperiment, was man sich auf jeden Fall auch als Zuhörer oder Zuhörerin, einmal aufgepasst, einmal vielleicht mal durchspielen könnte. Also find ich schon interessant. Was, weil wir gerade noch mal bei Sicherheit waren, was vielleicht noch ein Punkt ist, an wo man vielleicht noch mal auf jeden Fall auch an jeden einzelnen oder jede einzelne appellieren sollte.

Was würde ich sagen, auch wichtig ist, ist, Open Source ist prinzipiell eine gute Sache, würde ich sagen, ich glaube, da kann ich für dich sprechen, oder Tino kommt natürlich immer auch ein bisschen darauf an, wofür man das benutzen möchte und was dahinter steht, haben wir auch gesagt, das ist halt meistens nicht nur einfach ja oder nein, open Source ja, open source, nein, das muss man natürlich direkt auf den Anwendungsfall,

auf jeden Fall auch. Ein bisschen wirklich überlegen, was steht dahinter, was aber wichtig ist, was ich auf jeden Fall gerne auch noch mal ein bisschen mitgeben möchte, ist, dass man sich zum Beispiel sagen kann, Ok, Open Source heißt aber auch jetzt nicht gleichzeitig jedes.

Großprojekt ist glasklar oder lupenrein, oder wie man das nennen möchte, weil es gibt, zum Beispiel, weil ich vorhin auch NPM angesprochen hatte, es gibt, es ist nicht zu empfehlen, einfach irgendwie jede NPM Package Library einfach blind zu installieren und da sind wir auch wieder nochmal an dem Punkt vom Anfang. Es ist nicht nur sinnvoll sich Code anzugucken um daraus zu lernen, sondern manchmal ist es auch sinnvoll Code sich anzugucken und ein bisschen

unter die Lupe zu nehmen, weil man gucken kann, okay wird da irgendwie Schindluder betrieben oder nicht. Weil es gibt. Auf jeden Fall kann man einfach mal im Internet ein bisschen recherchieren und durchsuchen. Es gibt diverse npm Packages, die halt eben ich sag mal auf die Blacklist gesetzt wurden, weil sie halt eben nicht lupenrein waren, weil sie, weil da eben Schindluder betrieben

wurde und ein Mist passiert ist. So viel wie an Software theoretisch auf dem Markt kommen kann und auch kommt, so schnell kann keiner reagieren. Also sowas wird natürlich in vielen Fällen auch oft erkannt, weil es halt eben Open sources aber auch nicht sofort, also immer n bisschen auch. Mit Bedacht das ganze angucken. Würde ich jetzt mal so auf jeden Fall, da noch kurz, dann driften wir ja jetzt quasi auf die andere Seite. Wann?

Was sind so vor und Nachteile? Open Source Software oder einsehbare Software zu verwenden? Weil was du beschrieben hast finde ich ist auf jeden Fall super. Wichtiger Punkt aus Sicht des Anwenders, ob ich quasi Open Source verwende oder nicht für meine eigene Software und das ist halt auf jeden Fall ein super wichtiger Punkt, dass man sich anguckt, was für zb jetzt in der mpm Welt was für Packages sind denn das die ich da

verwende? Es klingt immer n bisschen simpel, aber ich finde, es ist zum Beispiel einfach auch schon mal n guter Anhaltspunkt, wieviel das Package verwendet wird oder wie oft besser gesagt ist es sehr beliebt.

Wie ist es bewertet, wie oft wird das in in der Woche zum Beispiel runtergeladen, guter Punkt, ja das sind das sind halt so so erste Anhaltspunkte dann wie gesagt hatten wir vorhin die Lizenz, gucke ich mir an, zum Beispiel weil wenn es zur Lizenztechnisch gar nicht das erfüllt, was ich damit machen möchte, dann ist ja eh schon Quatsch, ja. Dann sollte man es auch nicht tun. Also hier nicht irgendwas Verbotenes tun, liebe Zuhörer. Lieber Zuhörer, ja, das ist. Natürlich.

Also die Lizenz finde ich halt auch immer noch wichtig. Gerade, dass du zum Beispiel. Kriterien, gerade wenn du zum. Beispiel n Package verwenden willst für ne Software, die man vielleicht selber implementiert und kommerziell verwenden will. Aber diese Lizenz ist vielleicht gar nicht für den kommerziellen

Gebrauch zugelassen. Oder, oder du bist verpflichtet deine Software hat Anteile auch öffentlich zu machen, gibt es auch oft Lizenzen, die das beinhalten und dann ist das deine Pflicht, weil du diese Lizenz vereinbart hast. Also deswegen, das ist halt auch ein wichtiger Punkt, da reinzuschauen. Ja, ansonsten verfällt mir noch n Punkt ein. Gute Frage, gute Frage. Ah ja, ja, ja, ich hab noch ich hab noch n wirklich guten Punkt, der mir auch oft schon auf die Füße gefallen ist.

Bin. Ich gespannt. Ja, und zwar du verwendest ne n Package, was wirklich cool ist. Du suchst du hast also sagen wir mal du hast ne Problemstellung

und du suchst ne Lösung dafür. Du findest n Package, das wird auch verwendet, vielleicht jetzt nicht übertrieben viel, aber es ist schon in Benutzung und das löst dein Problem, das heißt du verwendest den Code, integrierst ihn und bist erstmal fein damit so und gefühlt in einem halben dreiviertel Jahr hat sich was geändert und das Package erfüllt. Die Aufgabe, was es soll, oder es funktioniert nicht mehr.

Du kriegst auf einmal Fehler in deiner Software, beispielsweise bei irgendwelchen Drittanbieter. Irgendwelche Anbindung third Party mäßig und dann denkst du dir, na gut, dann muss ich wohl mal neue Version von meinem Package, weil das halt mal updaten so und dann siehst du der letzte Commit auf diesem Repo auf dem Package ist auch ein halbes Jahr her und das wird nicht mehr Main Tainte die Wartung ist eingestellt, du erreichst niemanden mehr, du kannst es auch nicht abändern,

außer jetzt vielleicht lokal für dich, aber das hilft dir dann auch nur in dem Fall. Ja, dann stehst du halt blöd da und hast dich darauf verlassen, dieses Package zu verwenden und stehst dann halt vor einem sehr, sehr blöden Problem, um es mal milde auszudrücken. Ich. Hoffe du kannst mir folgen und auch Liebe zuhören. Lieber Zuhörer, du kannst mir folgen, aber das ist wirklich

wirklich. Ein Problem? Gerade in zum Beispiel im javascript Bereich ist die Welt da auch sehr sehr schnelllebig, was halt durchaus dazu führen kann, dass Inkompatibilität auftreten können. Und da hängt es natürlich immer wieder ein bisschen von der Community ab, auch wie schnell zum Beispiel auf bestimmte Änderungen reagiert wird. Aber zum Beispiel ist wieder auch NNN weites Thema und es gibt natürlich auch

verschiedene. Packagesysteme nicht nur im im Notebereich natürlich, von daher will ich da jetzt nicht näher drauf eingehen, aber das ist auf jeden Fall NN Punkt, den man natürlich bei Open Source mit im Kopf haben muss. Und deswegen ist es halt immer die Frage, an welcher Stelle man Open Source anwenden sollte. Ich würde sagen, am Ende hängt es einfach auch ein bisschen vom, also sehr individuell vom Anwendungsfall ab. Und man sollte sich wirklich überlegen. Worauf man hinaus möchte.

Also wenn man jetzt zum Beispiel Kosteneffizienz die Software wachsen lassen möchte, dann ist es durchaus möglich das mit Open Source zu machen. War noch lange nicht, dass das auch wirklich, wie wir ja schon das diskutiert haben, auch kosteneffizient wirklich stattfinden kann. Aber prinzipiell geht die Tendenz schon dorthin, würde ich

sagen. Dann ist natürlich Transparenz auf der einen Seite kann es ne gute Sache sein, es kann es kann n Segen sein, es kann aber natürlich auch irgendwo n Fluch sein, das ist der Sicherheitsaspekt den wir betrachtet haben, die Sicherheit kann unter Umständen im ist tendenziell aus Erfahrung recht hoch. Weil du ja natürlich auf der einen Seite viele Leute hast, die drauf gucken können, aber vielleicht auch nicht. Die Experten haben, die du vielleicht sonst im proprietären

Bereich für eine Software hast. Das kann natürlich aber auch sein, dass wenn du diese Experten vielleicht oder wenn diese Experten oder Expertinnen betriebsblind sind, dass sie dann bestimmte Sicherheitslücken nicht finden und diese Kompatibilitätsprobleme, die du gerade geschildert hast, die sind natürlich auf Seiten von Open Source eher zu finden als in proprietärer Software. Und deswegen ist es halt wirklich, wirklich abzuwiegen. Ok, wann sollte man was

verwenden? Eine Sache spannend finde oder wie er fair sein müssen. Wir können ja sagen, OK, die. Von diesem öffentlichen Package wurde eingestellt, da kümmert sich niemand mehr drum. Das ist natürlich n Problem, was bei kaufsoftware Blackbox Lösungen auch auftreten kann, also da stimmt, fairerweise muss man das natürlich auch

ansprechen. Beispielsweise ein Startup gründet sich, hat eine ganz coole Softwarelösung für ein Problem. Man selbst als Unternehmen oder Endanwender setzt darauf, kauft eine Lizenz oder oder oder, kauft diese Software vielleicht nicht mehr irgendein Abo Modell, sondern wirklich so einmalig dieses Software und das Unternehmen. Dieses Startup geht aber insolvent und also wird halt aufgelöst sage ich mal und wird nicht weiterentwickelt die Software dann habe ich am Ende

auch eine Software gekauft und stehe vor dem gleichen Problem. Plus dass ich noch Geld dafür bezahlt habe und vertraglich halt nicht so was drin steht wie du kriegst auf jeden Fall Updates noch, sondern da ist halt denn auch niemand mehr da. Da gibt es ja auch. Dann im Endeffekt das gleiche Problem am Ende für dich als Endanwender.

Also wenn man mal so darüber nachdenkt, jetzt ist natürlich die Frage, wenn du jetzt von großen Unternehmen Softwarelösungen kaufst, dann gehst du natürlich davon aus, dass die auch überleben. Klar. Aber am Ende, ich würd. Dir gern?

Ja, ich wollte. Eigentlich nur sagen, dass es halt so n paar Punkte gibt, die man abwägen muss für Open Source um am Ende halt auf wirklich Nenner zu kommen und das da gibt es nie einen Punkt wie wir ja schon meinten, das ist so oder so, aber was man ins Kalkül ziehen kann sind ja zum Beispiel die Kosten, die Anpassbarkeit, Sicherheit, Support und Wartung, Verfügbarkeit und Kompatibilität, die Lizenzen wie du meintest ist auch ein wichtiger Punkt, wie sollen die

aussehen oder? Die wie lang soll die Verfügbarkeit sein? Das ist ja im Endeffekt das, was du auch gerade genannt hast. Und was für ne Community steht dahinter, wenn man denn Open Source betrachtet oder halt eben welche Mitarbeiter habe ich in meinem Unternehmen? Das sind halt würde ich sagen, so grobe Punkte, an denen man sich theoretisch lang hangeln könnte. Sehr gut zusammengefasst die Folge.

Ja, bevor ich die Folge beende. Fabi würde ich gerne noch in der provokative Frage in den Raum stellen, und zwar an dich und auch an dich, liebe Zuhörerin, lieber Zuhörer, und zwar bei diesem ganzen Open Source Thema, was wir jetzt besprochen haben, kann man sich ja mal die Frage stellen bei den Software oder Programmen oder Software Lösung die ich oder man selbst entwickelt. Welche davon sind denn überhaupt

ohne Anteile von Open Source? Oder ist man je nachdem in welchem Bereich man arbeitet, doch eh an dem Punkt, dass Open Source Elemente mit dabei sind? Das kann ja mal jeder so für sich beantworten oder möchtest du hast du ne Antwort? Berater drauf, aber ich find das ist ne sehr coole Frage, die man sich selbst mal stellen kann bei dem ganzen Thema ja definitiv. Also ich würd es mal kurz machen für mich ganz kurz und sagen.

Viel also. Meistens nutzt man Open Source Software irgendwie im Alltag, im im Berufsalltag oder im privaten Alltag. Weil es halt einfach die Entwicklung auch beschleunigt ohne Ende, weil du einfach, du musst ja nicht das Rad neu erfinden, wie du es vorhin so schön gesagt hast. Richtig, es gibt natürlich wie gesagt auch Projekte, wo man das nicht macht, auch hier genannten Gründen in der Folge aber grundsätzlich bei uns beiden kann man sagen, wir dem schon zum Beispiel im Note Jazz Umfeld

Packages, logisch. Sonst bist du halt doch irgendwann nicht mehr wettbewerbsfähig, wenn du alles immer selber machen musst. Ja, dann würde ich sagen, haben wir es wirklich ausführlich besprochen und ich würde die Folge jetzt beenden. Das hat mir extrem viel Spaß gemacht. Fabi, vielen Dank dafür, es war ein extrem cooler Talk. Ja, ich mag das Thema auch sehr,

muss ich sagen. Ja, liebe zuhören, liebe Zuhörer, falls dir diese Folge gefallen hat, lass doch gerne n Like da abonnier diesen Podcast Erfolg uns auch gerne auf anderen Plattformen. Die Links findest du wie immer in den Shownotes und falls dir noch Punkte einfallen, die wir hier vergessen haben vor und Nachteile sowohl als Anwender als auch als Entwickler von Open Source, meld dich gerne bei uns in den Show Notes findest du auch die E-Mail Adresse von

diesem Podcast. Da kannst du uns gerne schreiben, wir sind super gespannt was dir noch einfällt. Wir würden das dann auch gerne mit der Community teilen und ansonsten würde ich sagen, mach dir noch einen schönen Tag. Wir hören uns beim nächsten Mal deine Coding Buddies. Gemeinsam besser. Was? Was?

Transcript source: Provided by creator in RSS feed: download file
For the best experience, listen in Metacast app for iOS or Android
Open in Metacast