Diese Woche findet in St. Petersburg ein IT-Festival statt. . Einer der Sprecher wird Richard Stallman sein. nimmt ebenfalls am Festival teil, und natürlich konnten wir das Thema Open Source nicht ignorieren. Daher trägt einer unserer Vorträge den Titel . Dieser wird sich mit der Geschichte der Entwicklung von Embox als Open Source-Projekt befassen. In diesem Artikel möchte ich die wichtigsten Ideen skizzieren, die meiner Meinung nach die Entwicklung von Open Source-Projekten beeinflussen. Der Artikel, wie auch der Vortrag, basiert auf persönlichen Erfahrungen.
Lassen Sie uns mit dem Einfachsten beginnen, mit der Definition des Begriffs Open Source. Offensichtlich ist ein Open Source-Projekt ein Projekt, das eine der Lizenzen besitzt, die den Zugriff auf den Quellcode des Projekts erlauben. Darüber hinaus impliziert ein offenes Projekt die Möglichkeit von Änderungen durch andere Entwickler. Das heißt, wenn ein Unternehmen oder Entwickler den Code seines Produkts, ganz oder teilweise, veröffentlicht, macht ihn das noch nicht zu einem Open Source-Projekt. Und schließlich sollte jede Projektaktivität zu einem bestimmten Ergebnis führen, wobei die Offenheit des Projekts bedeutet, dass dieses Ergebnis nicht nur von den Entwicklern selbst genutzt wird.
Die Probleme offener Lizenzen lassen wir außen vor. Dies ist ein zu großes und komplexes Thema, das eine tiefgehende Auseinandersetzung erfordert. Zu diesem Thema wurden bereits viele gute Artikel und Materialien geschrieben. Da ich selbst jedoch kein Fachmann im Bereich des Urheberrechts bin, möchte ich nur sagen, dass die Lizenz den Zielen des Projekts entsprechen sollte. Zum Beispiel war die Wahl der BSD-Lizenz anstelle der GPL für Embox kein Zufall.
Die Tatsache, dass ein Open-Source-Projekt die Möglichkeit bieten muss, Änderungen vorzunehmen und Einfluss auf die Entwicklung des Projekts zu nehmen, impliziert, dass das Projekt dezentralisiert ist. Es ist wesentlich schwieriger, es zu verwalten, die Integrität zu wahren und die Funktionsfähigkeit im Vergleich zu einem zentral gesteuerten Projekt sicherzustellen. Es stellt sich die berechtigte Frage, warum überhaupt Open-Source-Projekte entwickelt werden. Die Antwort liegt im Bereich der wirtschaftlichen Rentabilität; für bestimmte Klassen von Projekten überwiegt der Nutzen eines solchen Ansatzes die Kosten. Das bedeutet, dass nicht alle Projekte für einen offenen Ansatz geeignet sind oder dieser überhaupt zulässig ist. Zum Beispiel ist es schwer vorstellbar, ein System zur Steuerung eines Kraftwerks oder eines Flugzeugs auf offenen Prinzipien zu basieren. Natürlich sollten Module, die auf Open-Source-Projekten basieren, Teil solcher Systeme sein, da dies eine Reihe von Vorteilen bieten kann. Aber jemand muss die Verantwortung für das Endprodukt übernehmen. Selbst wenn das System vollständig auf dem Code offener Projekte basiert, schließt der Entwickler, der alles in ein System integriert und spezifische Builds und Konfigurationen erstellt, es im Grunde genommen. Der Code kann dabei zwar öffentlich zugänglich sein.
Für diese Systeme gibt es ebenfalls zahlreiche Vorteile in der Schaffung oder Beteiligung an Open-Source-Projekten. Wie ich bereits sagte, kann der Code des Endsystems öffentlich zugänglich bleiben. Warum? Es ist offensichtlich, dass kaum jemand das gleiche Flugzeug hat, um das System zu testen. Das stimmt, aber es könnte durchaus jemanden geben, der bestimmte Teile des Codes überprüfen möchte, oder zum Beispiel könnte jemand entdecken, dass die verwendete Bibliothek nicht ganz korrekt konfiguriert ist.
Ein noch größerer Nutzen entsteht, wenn ein Unternehmen einen bestimmten Basisanteil des Systems in ein separates Projekt auslagert. Zum Beispiel eine Bibliothek zur Unterstützung eines bestimmten Datenübertragungsprotokolls. In diesem Fall können die Kosten für die Wartung dieses Teils des Systems sogar dann geteilt werden, wenn das Protokoll spezifisch für einen bestimmten Fachbereich ist, mit anderen Unternehmen aus diesem Bereich. Darüber hinaus benötigen Spezialisten, die diesen Systemteil in der Öffentlichkeit kennenlernen, viel weniger Zeit für eine effektive Nutzung. Schließlich ermöglicht es die Auslagerung eines Teils in eine eigenständige Entität, die von Drittentwicklern verwendet wird, diesen Teil qualitativer zu gestalten, da effektive APIs angeboten, Dokumentationen erstellt und ich spreche nicht einmal von einer Verbesserung der Testabdeckung.
Ein kommerzieller Nutzen kann auch dann von einem Unternehmen erzielt werden, wenn keine offenen Projekte entwickelt werden. Es reicht aus, dass die eigenen Fachkräfte an externen Projekten beteiligt sind, die im Unternehmen verwendet werden. Denn alle Vorteile bleiben bestehen: Die Mitarbeiter kennen das Projekt besser, verwenden es also effizienter, das Unternehmen kann den Entwicklungsverlauf des Projekts beeinflussen und die Nutzung von bereits ausgereiftem Code reduziert offensichtlich die Kosten des Unternehmens.
Die Vorteile der Erstellung von Open-Source-Projekten enden hier nicht. Nehmen wir einen so wichtigen Geschäftszweig wie Marketing. Für Marketing ist das eine sehr gute Sandkiste, die es ermöglicht, die Anforderungen des Marktes effektiv zu bewerten.
Und natürlich sollte man nicht vergessen, dass ein Open-Source-Projekt ein effektiver Weg ist, um sich als Träger einer bestimmten Spezialisierung zu präsentieren. In einigen Fällen ist dies sogar der einzige Weg, um auf den Markt zu gelangen. Beispielsweise begann Embox als Projekt zur Erstellung eines Echtzeitbetriebssystems. Man muss wahrscheinlich nicht erklären, dass es eine Menge Konkurrenten gibt. Ohne die Schaffung einer Community hätten wir schlichtweg nicht die Ressourcen gehabt, um das Projekt bis zum Endbenutzer zu bringen, das heißt, damit das Projekt von Drittentwicklern genutzt wird.
Die Community ist der Schlüssel zu einem Open-Source-Projekt. Sie ermöglicht es, die Projektverwaltungskosten erheblich zu senken und das Projekt zu entwickeln und zu unterstützen. Man kann sagen, dass es ohne eine Community überhaupt kein Open-Source-Projekt gibt.
Über die Erstellung und Verwaltung von Gemeinschaften bei Open-Source-Projekten wurden zahlreiche Materialien geschrieben. Um nicht bereits bekannte Fakten zu wiederholen, möchte ich den Schwerpunkt auf die Erfahrungen von Embox legen. Zum Beispiel ist der Prozess der Erstellung einer Gemeinschaft eine sehr interessante Frage. Viele erzählen, wie man eine bestehende Gemeinschaft leitet, wobei die Aspekte der Gründung gelegentlich übersehen werden, da man sie als gegeben ansieht.
Die wichtigste Regel bei der Gründung einer Gemeinschaft für ein Open-Source-Projekt ist: Es gibt keine Regeln. Ich meine, dass es keine universellen Regeln gibt, ebenso wie es keine Silberkugel gibt, zumindest weil die Projekte sehr unterschiedlich sind. Es ist unwahrscheinlich, dass man dieselben Regeln für die Gründung einer Gemeinschaft für eine Logging-Bibliothek in JavaScript und einen hochspezialisierten Treiber verwenden kann. Darüber hinaus ändern sich die Regeln in den verschiedenen Phasen der Entwicklung des Projekts (und damit auch der Gemeinschaft).
Embox begann als Studentenprojekt, da wir Zugang zu Studenten der Abteilung für Systemprogrammierung hatten. Tatsächlich traten wir einer anderen Gemeinschaft bei. Die Mitglieder dieser Gemeinschaft, die Studenten, konnten wir mit guter industrieller Praxis in ihrem Fachbereich, wissenschaftlichen Arbeiten im Bereich der Systemprogrammierung sowie mit Abschlussarbeiten und -projekten interessieren. Das heißt, wir erfüllten eines der grundlegendsten Regeln der Gemeinschaftsorganisation: Die Mitglieder der Gemeinschaft sollten etwas erhalten, und dieser Preis muss dem Beitrag des Mitglieds entsprechen.
Die nächste Phase für Embox war die Suche nach externen Nutzern. Es ist sehr wichtig zu verstehen, dass Nutzer vollwertige Teilnehmer an der Open-Source-Gemeinschaft sind. Die Anzahl der Nutzer ist in der Regel größer als die der Entwickler. Um als Mitwirkender eines Projekts in Betracht gezogen zu werden, muss man es zunächst auf die eine oder andere Weise nutzen.
Die ersten Nutzer von Embox waren die Lehrstühle für Theoretische Kybernetik. Sie schlugen vor, eine alternative Firmware für Lego Mindstorm zu erstellen. Obwohl es sich immer noch um lokale Nutzer handelte (wir konnten sie persönlich treffen und besprechen, was sie wollten), war es dennoch eine sehr gute Erfahrung. Zum Beispiel entwickelten wir Demos, die wir anderen zeigen konnten, denn Roboter sind spannend und ziehen Aufmerksamkeit auf sich. Letztendlich hatten wir tatsächlich externe Benutzer, die fragten, was Embox ist und wie man es benutzt.
In diesem Stadium mussten wir über die Dokumentation und die Kommunikationsmittel mit den Benutzern nachdenken. Natürlich hatten wir schon früher über diese wichtigen Dinge nachgedacht, aber das war verfrüht und brachte keinen positiven Effekt. Der Effekt war eher negativ. Ich gebe ein paar Beispiele. Wir nutzten googlecode, dessen Wiki Mehrsprachigkeit unterstützte. Wir erstellten Seiten in mehreren Sprachen, nicht nur Englisch und Russisch, in denen wir mehr schlecht als recht kommunizieren konnten, sondern auch in Deutsch und Spanisch. Es sah sehr lächerlich aus, wenn in diesen Sprachen Fragen gestellt wurden, wir aber überhaupt nicht antworten konnten. Oder wir führten Regeln für das Schreiben von Dokumentationen und Kommentaren ein, aber da sich die API ziemlich oft und erheblich änderte, stellte sich heraus, dass unsere Dokumentation veraltet war und mehr Verwirrung stiftete, als half.
Letztendlich führten all unsere Bemühungen, selbst die nicht richtigen, dazu, dass externe Benutzer auftauchten. Und sogar ein kommerzieller Auftraggeber kam dazu, der wollte, dass wir für ihn ein eigenes OSR (öffentliche Software-Ressource) entwickelten. Und wir entwickelten es, da wir Erfahrung und einige Entwicklungen hatten. Hier muss ich sowohl von den guten als auch von den schlechten Momenten berichten. Ich beginne mit den schlechten. Da viele Entwickler für dieses Projekt auf kommerzieller Basis engagiert wurden und die Gemeinschaft ohnehin schon recht instabil war, spaltete sie sich, was sich natürlich auf die Entwicklung des Projekts auswirken konnte. Ein zusätzlicher Faktor war, dass die Richtung des Projekts von einem kommerziellen Auftraggeber vorgegeben wurde, dessen Ziel nicht die weitere Entwicklung des Projekts war. Zumindest war dieses Ziel nicht vorrangig.
Auf der anderen Seite gab es eine Reihe positiver Aspekte. Wir haben wirklich externe Nutzer gewonnen. Es waren nicht nur Kunden, sondern auch diejenigen, für die dieses System gedacht war. Die Motivation, am Projekt teilzunehmen, ist gestiegen. Denn wenn man bei einer interessanten Sache auch noch Geld verdienen kann, ist das immer angenehm. Und das Wichtigste ist, dass wir einen Wunsch der Kunden gehört haben, der uns damals absurd vorkam, aber der jetzt die zentrale Idee von Embox ist: nämlich bereits entwickelten Code im System zu verwenden. Jetzt ist die Hauptidee von Embox, Software auszuführen, die auf Linux basiert, ohne Linux selbst zu nutzen. Das heißt, der Hauptpositivpunkt, der die weitere Entwicklung des Projekts vorangetrieben hat, war die Erkenntnis, dass das Projekt von externen Nutzern verwendet wird und deren Probleme lösen sollte.
Zu diesem Zeitpunkt war Embox bereits über die Grenzen eines Studentenprojekts hinausgegangen. Der Hauptfaktor, der die Entwicklung des Projekts im studentischen Modell bremst, ist die Motivation der Teilnehmer. Studierende nehmen teil, solange sie studieren, und sobald sie ihren Abschluss gemacht haben, muss eine andere Motivation entstehen. Wenn diese Motivation nicht auftaucht, hört der Student einfach auf, am Projekt teilzunehmen. Wenn man bedenkt, dass die Studierenden zunächst geschult werden müssen, ergibt sich, dass sie zum Zeitpunkt ihres Abschlusses zu guten Fachleuten werden, aber ihr Beitrag zum Projekt aufgrund von Unerfahrenheit nicht sehr groß ist.
Allgemein gesagt, kommen wir allmählich zum zentralen Punkt, der es ermöglicht, von der Schaffung eines Open-Source-Projekts zu sprechen — der Schaffung eines Produkts, das die Probleme seiner Nutzer löst. Wie ich bereits oben erklärte, ist die wichtigste Eigenschaft eines Open-Source-Projekts seine Community. Und die Teilnehmer der Community sind in erster Linie die Nutzer. Aber woher sollen diese Nutzer kommen, wenn es nichts gibt, was sie verwenden können? So stellt man fest, dass man, genau wie bei einem nicht Open-Source-Projekt, sich auf die Schaffung eines MVP (minimal lebensfähiges Produkt) konzentrieren muss. Wenn dieses die Nutzer interessiert, wird eine Community um das Projekt herum entstehen. Wenn man jedoch die Community nur durch PR-Maßnahmen, das Schreiben von Wikis in allen Sprachen der Welt oder durch einen richtigen Git-Workflow auf GitHub aufbauen möchte, wird dies in den frühen Phasen des Projekts wahrscheinlich keine Bedeutung haben. Natürlich sind diese Dinge zu den entsprechenden Phasen nicht nur wichtig, sondern auch notwendig.
Zum Schluss möchte ich anmerken , meiner Meinung nach die Erwartungen der Nutzer an ein Open Source-Projekt widerspiegelnd:
Ich denke ernsthaft darüber nach, auf dieses OS umzusteigen (zumindest es auszuprobieren. Es wird sehr aktiv entwickelt und es werden tolle Dinge gemacht).
P. S. Auf haben wir gleich drei Vorträge. Einen über Open Source und zwei über Embedded (wobei einer praktisch ist). An unserem Stand führen wir einen Workshop zur Programmierung von Mikrocontrollern mit Hilfe von . Traditionell bringen wir Hardware mit und lassen sie programmieren. Es wird auch eine Schnitzeljagd und andere Aktivitäten geben. Kommt zum Festival und an unseren Stand, es wird Spaß machen.
Quelle: habr.com
