ubuntuusers.de

Hallo zusammen,

mich würde interessieren wie man im Rahmen eines Open Source Projekts eine große Community aufbaut und was die Erfolgsfaktoren eines Open Source Projektes sind/wären.

Falls jemand, Videos, Podcasts oder Lesestoff hat würde ich mich sehr über Postings und Empfehlungen freuen. Interessiert mich wirklich.

Hintergrund ist, dass ich auf den Chemnitzer Linuxtagen die Prüfung zum "Open Source Specialist" gemacht habe, vorher die Prüfungsziele mit erfahrenen Linuxern besprochen hatte aber die meinten zu der Prüfung: Eigentlich sollte man das Kleingedruckte der Lizenzen eher kennen als zu wissen, wie man ein Open Source Projekt "zum Fliegen" bringt.

Stimmt eigentlich. Deswegen frage ich euch danach. Feuer frei!

Schließe mich Mankind75 an, würde mich auch interessieren. Habe auf Launchpad ein paar Open Source Projekte, aber diese dümpeln ohne Resonanz vor sich hin.

Zu dem Thema habe ich viele Ideen (erst später ist mir aufgefallen, dass es um Launchpad geht, da kenne ich die Interaktionsmöglichkeiten weniger, drum sind meine Ideen eher allgemein). Für Sortierung und Ausformulierung wollte ich mir gerade keine Zeit nehmen, drum schlage ich als erste Maßnahme vor, selbst solche Optionen sortiert und nach Machbarkeit/eigenen Präferenzen zu erarbeiten, vielleicht mit anderen zusammen, sind ja schon 2, die sich grob dafür interessieren.

• statt eines Tomcat-It works! Link in die Signatur eines großen Forums zu setzen, würde ich den Github-Link und Links zu eventuell anderen Plattformen bringen

• Blog zu den Projekten betreiben, vielleicht da, wo man leichter Abonnenten (= mehr regelmäßige Lesende) sammeln kann, regelmäßig Neuigkeiten postem, durchaus auch auf X, Instagram, ...

• ich selbst mag Videos, Projekte auf Youtube vorstellen, nicht nur in Bezug auf den Blog mit SEO beschäftigen (Youtubekanal: SoGehtYoutube oder so ähnlich), GUIs, Kommandozeilenoptionen vorstellen, erweiterte Nutzungsmöglichkeiten in Scripts, Weiterverarbeitung ausgegebener Daten, etc., dazu ermuntern, an Projekten mitzuarbeiten, Pull-Requests einzureichen, machen andere auch Werbung für die Projekte, kann das das Ganze multiplizieren, Mitarbeit am Wiki/an der Dokumentation kann aucn positive Effekte haben, weil du dann Leute mit an Bord hast, die genauso Interesse an dem Projekt haben

• Kooperationen mit anderen eingehen, du stellst deren Projekte vor, sie deine, Abonnenten/Follower des einen folgen dann auch dem/den anderen, typische Reichweitenerhöhung, lässt sich auf vielen Plattformen umsetzen, Gastbeiträge für andere Blogs schreiben

• Mehrsprachigkeit, dank KI und Onlineübersetzungstools ist es leicht, Dokumentation und andere Inhalte mehrsprachig zur Verfügung zu stellen, das erweitert die Zielgruppe beträchtlich, bei meinem Testvideo sagen laut Statistik manche meine chinesische Beschreibung, weil das die im Browser, oder bei Youtube speziell, die gesetze Sprache war

• Auf Github und wo man sonst mit den eigenen Projekten aktiv ist auch bei anderen Kanälen aktiv sein, kommentieren, auf eigene Projekte hinweisen, die sonstwo fehlende Features ergänzen oder Alternativen darstellen, kommentieren, Probleme anderer lösen, Discussions, je mehr man da vertreten ist, desto öfters wird der eigene Account, werden die eigenen Repositories, angeklickt, Stack Overflow ist auch so eine Plattform, auf Reddit gibt es große Subs mit vielen Teilnehemnden, wo man eigene Projekte auch vorstellen kann, etwa: opensource 220k

• Je nach Projekten würde ich die auch in der Offlinewelt einbeziehen, auf Linux-Tagen und ähnlichen Events vorstellen, die Videos der Vorträge und sonstige Materialien sind dann idealerweise lange im Web verfügbar

Mankind75 schrieb:

Hintergrund ist, dass ich auf den Chemnitzer Linuxtagen die Prüfung zum "Open Source Specialist" gemacht habe

Kurz OT: hast Du einen Link zu? Gehört das zu den LPIC?

Hallo,

mich würde interessieren wie man im Rahmen eines Open Source Projekts eine große Community aufbaut und was die Erfolgsfaktoren eines Open Source Projektes sind/wären.

IMHO ist das relativ einfach: a) eine Software, die genug Leute brauchen und die innovativ ist oder besser als vorhandene Lösungen und b) genug Leute, die die Software geil finden und sich dran beteiligen und c) selber aktiv in der Community sein, bis die Community selber aktiv genug ist.

Einfach gesagt, schwer umzusetzen.

Die Lizenz spielt IMHO erstmal keine Rolle, weil die Lizenz ja nur interessant wird, wenn es um eine mögliche kommerzielle Verwertung geht. Und die Lizenz sollte so gewählt werden, dass man diese auch durchsetzen möchte und willens ist, dass zu tun. Wenn du z.B. eine der restriktiven OS Lizenzen nimmst, aber nicht bereit bist, bei Lizenzverstößen Rechtsmittel einzulegen, dann brauchst du die Lizenz auch nicht nehmen.

Gruß, noisefloor

U0679 schrieb:

Kurz OT: hast Du einen Link zu? Gehört das zu den LPIC?

Habe mich bei der Bezeichnung verschrieben: Das Zertifikat heißt "Open Source Essentials" und ja, es ist vom LPIC. Hier der entsprechende Link.

Ich würde "noisefloor" in den Punkten A und B zustimmen, eine Software, die niemand braucht, braucht niemand, das ist vergebene Liebesmüh. Also erstmal fragen, was wollen die Leute, was brauchen die Leute, dies wäre der erste Schritt.

Dazu sollte man sie vielleicht mal fragen, am besten nicht unbedingt in einem Computerforum, da man hier unter Leuten ist, die mehr oder weniger gleich ticken und man dann keine neuen Ideen bekommt. Zweitens sollte man auch mal mit Leuten sprechen, die nicht Programmierer sind, die eine andere Sicht auf Probleme haben (Fachleute, Anwender) und man sollte sie vor allem ernst nehmen und ihre Einwände nicht vom Tisch wischen, sie sind diejenigen, die später mit der Software arbeiten sollen, wenn sie aber ihren Ansprüchen nicht genügt, werden sie mit etwas anderem arbeiten und die ganze Sache war zwar nicht umsonst aber vergeblich. Ein "Brainstorming" ist hier ganz hilfreich, man sollte dann aber auch offen sein für unerwartete Antworten.

Dazu sollte man sich von der weitverbreiteten, aber falschen Vorstellung verabschieden, dass das Problem auf der anderen Seite der Tastatur sitzt. Dort sitzt der User, der mit dieser oder eben einer anderen Software arbeitet, er entscheidet, nicht der Programmierer.

Zwei Prinzipien sind für gutes Produktdesign wichtig, das "KISS-Prinzip" und "Easy to use" auf einfachem und schnellem Weg vom Start zum Ziel ohne Umwege, wenn man diese berücksichtigt, werden dir die Leute die Türen einrennen.

Um so etwas zu visualisieren, ist es hilfreich, sich den Programmablauf aufzuzeichnen, eine Startlinie, eine Ziellinie, die mit einer Führungslinie verbunden ist, entlang derer man sich bewegt, um tote Pfade, die ins Nichts führen, abzuschneiden. Dazu kann man Assistenten anbieten, die, die Arbeiten ganz oder teilweise automatisch durchführen und wenn Entscheidungen getroffen werden sollen nicht nur JA oder NEIN, sondern auch "ein weiß nicht" mit Hilfestellung anbieten, die sich genau auf diesen Punkt beziehen und nicht allgemein das Hilfefenster aufpoppen lassen, das ist für'n Ar....

Nicht „Was nützt dem Unternehmen?“, sondern „Wie verbessern wir das Leben der Kunden?“ ist die entscheidende Frage.

KISS-Prinzip https://de.wikipedia.org/wiki/KISS-Prinzip

Produktdesign: Easy to use – darum geht's https://newmanagement.haufe.de/en/skills/it-s-the-design-stupid

Brainstorming https://de.wikipedia.org/wiki/Brainstorming

Mankind75 schrieb:

Hier der entsprechende Link.

Danke!

Wichtig ist auch noch die "Software-Ergonomie", die teilweise zu Wünschen übrig lässt. Wenn man diese Punkte berücksichtigt, sollte einem erfolgreichen "Open Source Projekt" nichts mehr im Wege stehen.

Was ich mir z. B. wünschen würde wären Bedienoberflächen für Kommandozeilen Programme, mit denen stehe ich auf Kriegsfuß, wie viele andere auch. Und dies in einer Bedienoberfläche zusammenfassen, ich kenne so etwas von "WSCC" das für verschiedene Tool-Sammlungen eine Oberfläche zur Verfügung stellt und sie nach Funktionen sortiert, ein sehr sinnvolles und nützliches Programm.

Etwas anderes ist das Aufspüren von Zombie Dateien, die zwar defekt sind, aber noch vorhanden, dies wurde in dem Beitrag "Ordnerstrukturen zuverlässig vergleichen" behandelt. Hierfür gibt es wohl derzeit auf keinem System eine brauchbare Lösung.

Frei nach dem Motto: Es gibt viel zu tun, lassen wir's liegen.

Ordnerstrukturen zuverlässig vergleichen https://forum.ubuntuusers.de/topic/ordnerstrukturen-zuverlaessig-vergleichen/

ARBEITSSCHUTZGUTACHTEN SOFTWARE-ERGONOM https://www.usability-ux.fit.fraunhofer.de/content/dam/usability/de/documents/Gutachten-Software-Ergonomie.pdf

Software-Ergonomie: Streßfreie Bildschirmarbeit https://www.aerzteblatt.de/archiv/11898/Software-Ergonomie-Stressfreie-Bildschirmarbeit

Software-Ergonomie https://de.wikipedia.org/wiki/Software-Ergonomie

Software Ergonomie (DIN 9241-110) https://www.youtube.com/watch?v=vFF21WTrF7Y

Nabend Mankind75, und Homer65 - 😀

... ihr werft ja eine interessante Frage auf - die eines Community-Aufbaus im Bereich Open-Source bzw. Was denn das Geheimnis erfolgreicher Open Source Projekte ist - eine ausgesprochen spannende Frage.

Verdoooft, Yabba-Dabba-Doo und Noisefloor haben schon einiges sehr wichtige genannt - ....

Für deine Fragestellung, Mankind dafür interessiert sich u.a. auch die allgemeinen Organisationsforschung, die Forschung zur Organisation im Wandel schon lange - und diese Forschunsgebiete haben bei der konkreten OpenSource-Forschung viel viel lernen könne - also etwa, wenn es darum geht wie man eine Open Source Projekt und eine große Community (bestehend aus einer sehr heterogenen Gruppe) aufbaut und was dann dabei die Erfolgsfaktoren eines Open Source Projektes sind/wären.

Die Open-Source Forscher haben ihre Arbeiten am MIT in Boston gebündelt und in ihren Ergebnisse zusammentragen in Thesen, Abstracts u.v.a. mehr - in den letzten 40 Jahren. https://flosshub.org/biblio Diese fast 1800 Arbeiten, die dort zusammengetragen sind - haben z.B. kleine oder auch große Projekte im Open-Source-Feld untersucht, wie etwa Linux, Apache, KDE, unzähliger SourceForge-Projekte - und viele viele andere mehr - mit Fragen nach den Erfolgsbedingungen, der Bedingungen des Wachstums, des Scheiterns, der Zusammenarbeit, der Good Governance u. vielen anderen mehr.

Vorweg: entscheidend scheinen mir hier einig der Schlüsselkonzepte zu sein, die ich einige wenige in folgenden Schlagworten kurz anreiße... Hier sind einige Schlüsselpunkte zum Aufbau einer erfolgreichen Open-Source-Community und den Erfolgsfaktoren von Open-Source-Projekten:

Offene Kommunikation und Transparenz: Open-Source-Projekte zeichnen sich m.E. durch offene Kommunikation und Transparenz aus. Dies schafft Vertrauen innerhalb der Community und fördert die Zusammenarbeit.

Beteiligungsmöglichkeiten für alle: Erfolgreiche Open-Source-Projekte bieten vielfältige Möglichkeiten zur Beteiligung, unabhängig von technischen Fähigkeiten oder Erfahrungsniveau. Dies kann von der Fehlerbehebung über das Schreiben von Dokumentationen bis hin zur Entwicklung neuer Funktionen reichen. Lave und Wenger haben meines Erachtens viel zu diesem Thema beigetragen (vgl. unten mehr)...

Community-orientierte Governance: Eine effektive Governance-Struktur ist meines Erachtens entscheidend, um die Beteiligung der Community zu fördern und Konflikte zu lösen. Modelle wie die meritokratische Governance, bei der Beitragende aufgrund ihrer Leistungen und ihres Engagements mehr Einfluss erhalten, haben sich bewährt. Dazu haben die Autoren van Hippel, Hemetsberger, Lanzara und Mourner viel beigetragen.

Unterstützung für Neueinsteiger: meines Erachtens ziemlich wichtig ... die einladende und unterstützende Umgebungen für Neueinsteiger sind wichtig, um eine breitere und diverse Community aufzubauen. Dies kann durch Anleitungen, Mentoring-Programme und spezielle Veranstaltungen für Neueinsteiger erreicht werden - vgl. Legitimate Peripheral Participation (siehe auch unten bzw. die Autoren Glaser und Genepp)

Werte und Kultur: Erfolgreiche Open-Source-Projekte haben oft eine starke gemeinsame Wertebasis und Kultur. Dies kann die Werte von Zusammenarbeit, Offenheit, Respekt und gegenseitiger Hilfe umfassen. und last but not least noch die letzten zwei Punkte - zu denen auch etwa der technische Aspekt gehoert.. nämlich:

Technische Exzellenz: Die Qualität des Codes und der technischen Lösungen ist entscheidend für den langfristigen Erfolg eines Open-Source-Projekts. Dies erfordert eine sorgfältige Code-Überprüfung, kontinuierliche Verbesserung und eine klare Architektur.

Community-Management und Moderation: Effektive Community-Manager und Moderatoren spielen eine wichtige Rolle bei der Förderung einer positiven und produktiven Community-Dynamik. Sie können Konflikte lösen, Feedback sammeln und die Beteiligung der Community fördern.

Weil hier ausdrücklich nach Autoren und Literatur - also nach Vertiefung des Themas gefragt wird, kurz noch das: Forschungsarbeiten von Autoren wie Eric S. Raymond, Eric Van Hippel, und Lave and Wenger haben wichtige Einsichten in die Funktionsweise und Entwicklung von Open-Source-Communities geliefert. Raymond's "The Cathedral and the Bazaar" beispielsweise hebt die Bedeutung der offenen Entwicklung und des Peer-Reviews hervor, während Van Hippel's Arbeit die Rolle von Benutzerinnovationen und Co-Creation in Open-Source-Projekten untersucht. Lave und Wenger haben das Konzept der "Communities of Practice" entwickelt, das die informellen Lern- und Wissensaustauschprozesse innerhalb von Open-Source-Communities beschreibt.

Eine kleine Zusammenstellung wichtiger Konzepte innerhalb der Innovationsforschung, der OpenSource-Forschung und auch (neuerdings) innerhalb der Digital Innovation - Hubs hab ich mal hier zusammengestellt - sozusagen eine Short-list: https://wiki.openstreetmap.org/wiki/User:Tagtheworld/Open-source-research

Das ist - wie gesagt nur ein Auszug u. eine Zusammenfassung der gesamten Open-Source Forschungen, die am MIT in Boston ihre Ergebnisse zusammentragen in Thesen Abstracts u.v.a. mehr - in den letzten 40 Jahren. https://flosshub.org/biblio

Wollte man das an einzelnen Autoren festmachen, die ich in meine Liste der Open-Source-, oder Innovationsforschung aufgenommen hab - dann wären das etwa der folgenden Autoren:

• Eric Van Hippel

• Eric S. Raymond

• Michele Mourner Giovanni Lanzara

• Andrea Hemetsberger

• Lave and Wenger

• Illka Tuomi

• Nonaka & Takeuchi

• vgl. also hier: https://wiki.openstreetmap.org/wiki/User:Tagtheworld/Open-source-research

und bezogen auf einige Schlagworte, und Kontepte wären hier noch einige der wichtigen Ansätze aus der allgemeinen Organisationsforchung - der Forschung zur Organisation im Wandel ,bzw der konkreten OpenSource-Forschung hier zu nennen - also die Perspektiven

• - discourse of universe / universe of discourse (G.H.Mead)

• - Cathedral or Bazaar - Eric Raymond

• - Network of innovation - Illka Tuomi

• - Community of Practice CoP Lave & Wenger darüher hinaus

• und darüber hinaus:

LPP: Aufbauend auf Lave und Wengers: Theorie der legitimen peripheren Partizipation (LPP) bietet dieses Papier eine Längsschnittuntersuchung einer OSS-Gemeinschaft, in der nachhaltige Partizipation vermutlich mit der Koevolution zweier Hauptelemente der LPP-Theorie verbunden ist: „situiertes Lernen“. (der Prozess des sachkundigen und zielgerichteten Handelns in der Welt) und „Identitätskonstruktion“ (der Prozess der Identifikation innerhalb der Gemeinschaft).

SECI-Modell der Wissensdimensionen: von Nonaka & Takeuchi; Das SECI-Modell der Wissensdimensionen ist ein Modell der Wissensgenerierung, das erklärt, wie implizites und explizites Wissen in Organisationswissen umgewandelt wird. Das SECI-Modell unterscheidet vier Wissensdimensionen – Sozialisation, Externalisierung, Kombination und Internalisierung – die zusammen das Akronym „SECI“ bilden. Das SECI-Modell wurde ursprünglich 1990 von Ikujiro Nonaka entwickelt und später von Hirotaka Takeuchi weiter verfeinert.

liminaler Ansatz – vgl. die Bewegung von Einzelpersonen, die sich in Open-Source-Gemeinschaften engagieren. Angesichts der Tatsache, dass Open-Source-Gemeinschaften und ein wachsender Wissensschatz über das Engagement von Unternehmen in Open-Source-Gemeinschaften vorhanden sind, ist unser Verständnis der Bewegungen von Einzelpersonen innerhalb dieser Gemeinschaften begrenzt. Um diese Bewegungen zu analysieren, stützen wir uns auf die Liminalitätstheorien von Arnold Van Gennep und Victor Turners. Durch diese Linse bauen wir ein Verständnis für die Bewegungen einzelner Mitglieder innerhalb von Open-Source-Communities auf.

Nachsatz; Neuerdings interessiert sich für das Thema auch die neuere Innovations- und Organisationsforschung - die z.B. die Digital Innovation-Hubs (vgl. etwa hier den EDIH Catalogue, der eine Zusammenfassung in Europa zum Thema darstellt: https://european-digital-innovation-hubs.ec.europa.eu/edih-catalogue

Sie kann m.E. an die MIT-basierten Gruppen anknüpfen... - hier ein Link zu den Arbeiten rund um die Digital-Innovation-Hub-Forscher: https://wiki.openstreetmap.org/wiki/User:Tagtheworld/_Digital_Hubs: Wie gesagt, aufs Ganze gesehen knüpfen sie meines Erachtens ganz gut an an die allgemeinen Open-Source-Forschungstradition.... hier: https://wiki.openstreetmap.org/wiki/User:Tagtheworld/Open-source-research

soviel vorweg mal von mir..

ciao - pregmatch 😉

noch ein paar Links zu den Digital Innovation Hubs - einer eropäischen Bewegung die versucht Innovationsbedingungen - wie sie im Silicon Valley gibt - hier in Europa herzustellen... Links: der EDIH Catalogue: https://european-digital-innovation-hubs.ec.europa.eu/edih-catalogue

Browse this catalogue to find essential information about the European Digital Innovation Hubs (EDIH), the one-stop shops assisting companies and public administration in addressing digital challenges. The EDIH Network is co-financed by the European Commission and EU Member States. Search. Explore the complete EDIH catalogue, including hub descriptions. EDIH type. Choose from three types of hubs: Funded under Digital Europe programme: Co-funded by the European Commission and Member States/Associated Countries. Seal of Excellence: Positively evaluated in a European competitive call but funded exclusively by national or regional resources. Funded by other initiatives: Digital innovation hubs with similar activities to EDIHs but not connected to the network. Users will need to select this type manually.

Morgen Leuts - servus Mankind75 , homer65 und alle. 😀

noch ein kleiner Nachtrag: zwar finden sich hier in Boston Massachusetts die sprichwörtlichen kilomenterlangen "Regale" mit den Abstracts, den Thesen, Studien und META-Studien zu tausenden kleinen und großen Projekten in der OS-Welt. fast alle Studien sind hier zusammengetragen - von 1985 bis 2017 jedenfalls.. vgl. https://flosshub.org/biblio

Dort liegen die Befunde: die Aufschluss geben über zentralen Geheimnisse und die Bedingungen der Möglichkeit von Erfolg in Teams: Antworten auf die Fragen, was hält ein OS-Projekt zusammen, was fördert Wachstum, Innovation, Akzeptanz, was hilft Mitmacher zu gewinnen und Projekte in eine dynamische Bewegung nach oben zu bringen. All das ist hinreichend erforscht - die meisten Befunde sind mittlerweile auch in Nachbardisziplinen rezipiert. Und die Welt ist scharf darauf - die Corporate Welt im Großen und Ganzen - und auch die Welt der Organisationen also etwa dort wo sich die Frage stellt, wie werden Teams innovativ - sie alle wollen gern wissen, was die freien Projekte stark macht, wie dort die Leute gewonnen werden - wie sich Linux so stark entwickeln konnte? Da trifft sich eure Frage, Mankind 75 und homer65 - nach den zentralen Bedingungen der Möglichkeit von Erfolg in Projekten - das ist die Frage die im Grunde so viele beschäftigt.

und am Ende meines letzten Beitrags oben, da hab ich das noch ganz kurz an einem jungen Projekt erläutert - zum Beispiel sei hier die EU-Initiative erwähnt, den EDIH - also den Europäischen digitalen Innovation Hubs: die https://european-digital-innovation-hubs.ec.europa.eu/edih-catalogue

Was mir aber noch wichtig ist - ist der Hinweis auf einen wichtigen Forschungszweig der Netzwerkforschung - auf die ANT - die Actor Network Theory. Bin davon überzeugt dass OpenSource am allerbesten dann verstanden wird - wenn wir die Nachrichten selber als Akteure verstehen - m.a.W. also im SYSTEM nicht nur menschliche Akteure sondern auch anderes - wie etwa Nachrichten mit veranschlagen. Sehr schön auf den Punkt haben dies die beiden OpenSource-Forscher Lanzara & Mourner gebracht:

The Knowledge Ecology of Open-Source Software Projects:

In this paper we characterize the processes of knowledge making in open-source software projects as an ecology of agents, artifacts, rules, resources, activities, practices and interactions. In order to grasp its dynamic features e consider open-source software projects as interactive systems based on dense interactions between humans and technical artifacts within electronic media. Technology, rather than formal or informal organization, embodies most of the conditions for governance in open-source software projects, hence becoming a critical pathway to the understanding of collective task accomplishment, coordination and knowledge making processes. Based on an in-depth analysis of two open-source software projects, we examine three kinds of artifacts, respectively inscribing technical, organizational, and institutional knowledge. Our preliminary findings support the ecological view, that the contradictory requirements of innovation and stability in project-based knowledge making are balanced by mechanisms variation, selection, and stabilization.

Link: https://flosshub.org/sites/flosshub.org/files/lanzaramorner.pdf

Hier schließen die beiden Autoren Michelle Mourner und Giovanny Lanzara an die Actor Network Theory

Für sie, und für Bruno Latour sind Akteure eben nicht nur Menschen, sondern es gibt auch non-human Akteure (wichtig) in Prozessen: im Sinne von... "Human &/ non-human-actants are equal... " hier ein paar schöne Einführungen zur Actor Network-Theory:

kurz - und hinreißend: - kann man schnell mal in der Mittagspause gucken Actor-Network Theory in Plain English (Spreadlove) https://youtu.be/X2YYxS6D-mI

mittel: - sehr modern - The Social Life of Machines: Bruno Latour's Actor-Network Theory https://youtu.be/LmrdwU1fYrc

lang: - mit sehr schönen Animationen: bitte mit Kopfhörer ansehen - ist echt wie großes Kino.. A Brief Explanation of Bruno Latour's Actor Network Theory https://youtu.be/X57uy0ahlZk

Servus und Pfiats eich pregmatch 😀

noch ein paar Links:

EDIH: https://european-digital-innovation-hubs.ec.europa.eu/edih-catalogue

Die regionalen Digital Hubs - das sind gewissermaßen wie Kristallisationspunkte für digitale Innovationen in den Regionen Europas.

Initiiert von einer EU-Initiative (die wie gesagt am Silicon Valley gesehen hat wie digitale Ökosysteme innovativ werden können) sollen (wollen) hier die Bedingungen der Möglichkeit von Innovation nachgebaut werden. Also - in diesen in Europa geschaffenen Digitalisierungszentren treffen unterschiedlichste Kompetenzen, Disziplinen, Ideen, Technologien und Kreativität aufeinander - so der Plan: Diese regionalen Digital Hubs - sie bieten gewissermaßen Netzwerke - stellen also regionale Anlaufstelle für kleine und mittlere Unternehmen aller Branchen bei Fragen zur Digitalisierung dar. Im Ansatz sind diese Hubs grundsätzlich branchenoffen konzipiert und bieten die Möglichkeit, neue Ideen für digitale Projekte in Experimentierräumen zu entwickeln und zu erproben. vgl. mehr dazu: EDIH: https://european-digital-innovation-hubs.ec.europa.eu/edih-catalogue - mit einer Karte dieser Europäischen digitalen Innovations-Hubs....

Als Nachtrag zum Thema Softwareergonomie habe ich hier noch eine Veröffentlichung der Deutschen Gesetzlichen Unfallversicherung (DGUV) verlinkt, die darauf eingeht, welche Bedeutung Softwareergonomie auf den Menschen hat.

Die Leute wollen Lösungen und keine zusätzlichen Probleme.

Wenn man diese Punkte, die ich und andere genannt haben berücksichtigt, kann man einen Erfolg kaum verhindern.

Was man vermeiden sollte, ist "Squirrel Programming" Eichhörnchen verstecken die Früchte ihrer Arbeit auch so gut, dass sie sie am Ende nicht wiederfinden und verhungern. Also keine versteckten Funktionen, die nur mit Aufwand zu finden sind.

Letzten Endes haben alle einen Vorteil davon.

Man könnte auch mal fragen, was die Leute besonders nervt, dann hätte man schon mal ein paar Punkte wo man den Hebel ansetzen könnte.

DGUV Information 215-450 Softwareergonomie April 2021 https://publikationen.dguv.de/widgets/pdf/download/article/3046

Ich wollte auch nochmal kurz Rückmeldung geben und mich schon mal vorab bedanken. Insgesamt ist mein Fazit, dass man nach Möglichkeit ein Team bilden sollte.

Für einen Einzelkämpfer stelle ich mir die Komplexität jenseits des reinen Codeschreibens sehr schwer vor. Und Teamentscheidungen sind sehr oft besser als wenn man als Einzelner entscheidet. An der Hochschule hatten wir dazu mal das "NASA-Experiment" (gibt einen Wikipedia Artikel dazu) gespielt und es kamen im Team wirklich bessere Ergebnisse raus.

Servus Mankind und Yabba-Dabba-Doo, Nabend...

jupp das seh ich auch so wie du mankind:

Ich wollte auch nochmal kurz Rückmeldung geben und mich schon mal vorab bedanken. Insgesamt ist mein Fazit, dass man nach Möglichkeit ein Team bilden sollte. Für einen Einzelkämpfer stelle ich mir die Komplexität jenseits des reinen Codeschreibens sehr schwer vor. Und Teamentscheidungen sind sehr oft besser als wenn man als Einzelner entscheidet. An der Hochschule hatten wir dazu mal das "NASA-Experiment" (gibt einen Wikipedia Artikel dazu) gespielt und es kamen im Team wirklich bessere Ergebnisse raus.

ganz genau: das mit dem Rückmeldung einholen. Das halte ich für grundlegend wichtig:

Es kommt dies auch in den sog. digtal (design-) principles - auch eingesetzt in der Lean Startup - Method (Eric Ries) und darüber hinaus gibet imho eben auch bereits sehr früh von Hewlett & Packard in den Rules of the Grarage frühe Vorläufer resṕ. Anklänge daran. (vgl. unten_)

hier worum es m.E. halt auch geht:

• * Why lean startup?

• Concepts in the lean startup method

• Iterate: Release early - release often

• create a Minimum Viable Product (MVP)

• iterate: Build, Measure, Evaluate and Learn

• Pivoting

• Actionable metrics

• und genauer:

also ich denke mal, dass hier auch die digitalen Designprinzipien von Bedeutung sind, die auch von Lean Startups verwendet werden: und ansonsten eben agile Teams treiben.

Warum Lean Startup?: Die Lean-Startup-Methode basiert auf dem Prinzip der kontinuierlichen Iteration und Anpassung, um schnell auf Kundenfeedback zu reagieren und erfolgreich zu sein.

Konzepte in der Lean-Startup-Methode:

release early - release often: das Superprimat - damit fäng imho alles an: m.a.W: ist hier also gemeint: Frühzeitig veröffentlichen - häufig veröffentlichen: Durch regelmäßige Veröffentlichungen von Produktversionen kannste halt im Grunde früh wertvolle Daten gewinnen - einfach gesagt, schnell Feedback sammeln und dein Produkt iterativ verbessern.

Minimum Viable Product (MVP): Ein MVP - das ist so etwas wie die einfachste Version deines Produkts: sie hat im Grunde nur das allerallernotwendigste. So wenig, dass es grad eben ausreicht den Kunden damit zu erreichen - um ein allererstes Feedback einzuholen - und dabei ganz wesentliches zu lernen: Ein MVP - ist imho also so klein und basal, dass es grade eben (noch oder sagen wir "schon") ausreicht, um Kundenfeedback zu erhalten und grundlegende Funktionen zu validieren.

build measure, evaluate & learn: oder eben: Bauen, Messen, Auswerten und Lernen: Dieser iterative Prozess (oder besser dies iterative Schleife - denn es ist tatsächlich ein Kreis!) beinhaltet das schnelle Erstellen eines Produkts, das Messen von Ergebnissen, das Auswerten von Feedback und das Lernen aus den Erkenntnissen, um das Produkt (also deine Software eben) kontinuierlich zu verbessern.

Pivote - bilde Create / Release-Zyklen: Wenn ein Produkt (um jetzt mal ganz allgemein zu sprechen) nicht den gewünschten Erfolg erzielt, ist es wichtig, halt daraus zu lernen und auch flexibel zu sein und Anpassungen vorzunehmen, indem man das Geschäftsmodell, die Zielgruppe oder das Produkt selbst ändert.

use actionable metrics: Handlungsorientierte Metriken einsetzen: Es ist entscheidend, möglichst frühzeitig im Prozess aussagekräftige Metriken zu definieren, solche also die möglichst viel Aufschluss geben - m.a.W. also solche, die möglichst frühzeitig im Entwicklungsprozess einem mit Wissen versorgen - etwa in dem sie moeglichst direkt darauf hinweisen, ob das Produkt erfolgreich ist, und dann Maßnahmen zu ergreifen, um diese Metriken zu beeinflussen.

conclusio: Denke dass diese Prinzipien echt voll wichtig sind und dabei helfen, Lean Startups, insges. auch agilen Teams, um effizien(ter) zu sein, indem sie schnelle Experimente durchführen, uns halt wann immer es geht das Kundenfeedback möglichst früh nutzen und ihre Produkte und Geschäftsmodelle kontinuierlich verbessern.

ganz am Ende sei hier noch darauf hingewiesen ,dass das nicht alles furchtbar modern ist - sondern dass ein Teil dieser Methoden u. Prinzipien ja auch schon von Hewlett und Packard in den 10 Rules of the Garage formuliert haben.. - oder es ihnen so zugeschrieben wird.

Die "Rules of the Garage" von Hewlett und Packard umfassen m.E. ja auch Prinzipien, die - wenn man genau hinsieht, einige Ähnlichkeiten mit den Konzepten der Lean-Startup-Methode teilen. Bin vor ein paar Jahren nochmals drauf gestoßen; diese Regeln wurden von den beiden Gründern von Hewlett-Packard, William Hewlett und David Packard, aufgestellt;

Ich würde mal sagen, dass sie zumindest auch eine relativ wichtige Rolle bei der Entwicklung der Unternehmenskultur von HP gespielt haben. Zumindest einige der Prinzipien, die dann später in die "Rules of the Garage" eingegangen sind, können meines Erachtens durchaus als Vorläufer der Lean-Startup-Prinzipien angesehen werden.

ich würde mal sagen, dass wir hier sicher die folgenden näher in Betracht ziehen können:

Belohnung für Risikobereitschaft und Innovation: Hewlett und Packard betonten die Wichtigkeit von Risikobereitschaft und Experimenten. Da trifft sich das Ganze dann mit der Lean Startup-Methode: Denn ich finde, dass die Lean-Startup-Methode sehr sehr ähnlich Wert darauf legt, dass Unternehmen bereit sein sollten, auch mal ein paar Risiken einzugehen und dabei eben auch zu experimentieren, um erfolgreiche Innovationen voranzutreiben ... und darüber hinaus:

Schnelles Prototyping und Testen: In den "Rules of the Garage" wird die Bedeutung von schnellen Prototypen und Tests hervorgehoben, eben darum und dafür dass man dadurch dann auch Ideen schnell validieren zu können. Dies ähnelt meines Erachtens dann doch dem Konzept des Minimum Viable Products (MVP) in der Lean-Startup-Methode, bei dem Unternehmen schnell einfache Versionen ihrer Produkte erstellen, um Kundenfeedback zu erhalten... und weiters:

Offene Kommunikation und Zusammenarbeit: Hewlett und Packard betonten die Bedeutung von offener Kommunikation und Zusammenarbeit in ihrer Garage, wo sie HP gründeten. Dies spiegelt den Wert wider, den die Lean-Startup-Methode auf die Zusammenarbeit und den Austausch von Ideen legt, um schnell zu lernen und zu wachsen.

also als Zwischenfazit könnte man vielleicht sagen: Obwohl die "Rules of the Garage" von HP nicht direkt die Konzepte der Lean-Startup-Methode umfassen, zeigen sie dennoch ähnliche Prinzipien und Werte, die für die Förderung von Innovation und Unternehmertum entscheidend sind.

Lit:

Eric Ries: The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses – 13. September 2011

Most startups fail. But many of those failures are preventable. The Lean Startup is a new approach being adopted across the globe, changing the way companies are built and new products are launched. Eric Ries defines a startup as an organization dedicated to creating something new under conditions of extreme uncertainty. This is just as true for one person in a garage or a group of seasoned professionals in a Fortune 500 boardroom. What they have in common is a mission to penetrate that fog of uncertainty to discover a successful path to a sustainable business.

und weiter

The Lean Startup approach fosters companies that are both more capital efficient and that leverage human creativity more effectively. Inspired by lessons from lean manufacturing, it relies on “validated learning,” rapid scientific experimentation, as well as a number of counter-intuitive practices that shorten product development cycles, measure actual progress without resorting to vanity metrics, and learn what customers really want. It enables a company to shift directions with agility, altering plans inch by inch, minute by minute.

Servus und

Pfiats Eich ... 😉

pregmatch schrieb:

Eric Ries: The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses – 13. September 2011

Endlich mal ein Text, den ich auch hier im Regal stehen habe. Fand es aber schwierig. Das Gründerteam kann sicherlich jede Menge Learnings aus so einem Projekt ziehen. Andererseits nehme ich auch mal an, dass die Investoren ihr Kapital verzinst haben wollen und da wird das Gründerteam dann auch erklären müssen wie es dies umzusetzen gedenken tut.

Ist ja auch irgendwie blöd wenn das Team dann nach ein paar Monaten kommt: "Okay, dein Investment haben wir verbraucht aber wir haben soo viel gelernt, dass wir noch einen kleinen Nachschub brauchen. Wir stehen soo kurz vor dem Durchbruch.." Ich persönlich würde da schon fragen: "Was gedenkt ihr zu tun, dass sich mein investiertes Kapital verzinst?" und spätestens dann braucht man auch einen schlüssigen Plan.

Letztendlich ging es um die Diskussion "Businessplan vs. Lean Startup" wobei ich selbst mehr "old school" bin obwohl kein Businessplan genau auf den Cent aufgeht. Beispielsweise hatte ich gefragt: Wie ist denn beispielsweise Liquiditätsplanung vorgesehen? Im Lean Startup habe ich den Begriff nicht gefunden. (Liquidität geht vor Profitabilität)