Bereits diese Woche findet in St. Petersburg das
TechTrain IT-Festival statt. Einer der Redner wird Richard Stallman sein.
Embox nimmt auch am Festival teil, und natürlich konnten wir das Thema Open Source-Software nicht ignorieren. Daher heißt einer unserer Berichte
„Vom studentischen Handwerk zum OpenSource-Projekt. Embox-Erfahrung .
“ Es wird der Geschichte von Embox als Open Source-Projekt gewidmet sein. In diesem Artikel möchte ich über die Hauptideen sprechen, die meiner Meinung nach die Entwicklung von OpenSource-Projekten beeinflussen. Der Artikel basiert wie der Bericht auf persönlichen Erfahrungen.
Beginnen wir mit einer einfachen Definition des Begriffs OpenSource. Offensichtlich ist ein Open Source-Projekt ein Projekt mit einer der Lizenzen, mit denen Sie auf den Quellcode des Projekts zugreifen können. Darüber hinaus impliziert ein offenes Projekt die Möglichkeit von Änderungen durch Drittentwickler. Das heißt, wenn ein Unternehmen oder Entwickler den Code seines Produkts teilweise oder vollständig veröffentlicht, wird dieses Produkt nicht zu einem Open Source-Projekt. Und schließlich sollte jede Projektaktivität zum Auftreten eines Ergebnisses führen, und Offenheit des Projekts impliziert, dass nicht nur die Entwickler selbst dieses Ergebnis verwenden.
Wir werden die Probleme offener Lizenzen nicht ansprechen. Dies ist ein zu großes und kompliziertes Thema, das eingehend untersucht werden muss. Zu diesem Thema wurden viele gute Artikel und Materialien geschrieben. Da ich selbst kein Spezialist auf dem Gebiet des Urheberrechts bin, kann ich nur sagen, dass die Lizenz die Ziele des Projekts erfüllen sollte. Für Embox beispielsweise war die Auswahl einer BSD-Lizenz anstelle einer GPL-Lizenz nicht zufällig.
Die Tatsache, dass ein offenes Projekt es ermöglichen sollte, Änderungen vorzunehmen und die Entwicklung eines offenen Projekts zu beeinflussen, impliziert, dass das Projekt verteilt wird. Die Verwaltung, Aufrechterhaltung von Integrität und Effizienz ist im Vergleich zu einem Projekt mit zentraler Verwaltung viel schwieriger. Es stellt sich eine vernünftige Frage: Warum überhaupt Open-Source-Projekte? Die Antwort liegt im Bereich der kommerziellen Machbarkeit: Bei einer bestimmten Klasse von Projekten überwiegen die Vorteile dieses Ansatzes die Kosten. Das heißt, nicht für alle Projekte ist ein offener Ansatz im Allgemeinen akzeptabel. Beispielsweise ist die Entwicklung eines Kraftwerks oder eines Flugzeugsteuerungssystems nach einem offenen Prinzip schwer vorstellbar. Nein, es lohnt sich natürlich, Module, die auf offenen Projekten basieren, in die Zusammensetzung solcher Systeme einzubeziehen, da dies eine Reihe von Vorteilen bietet. Aber jemand muss für das Endprodukt antworten. Selbst wenn das System vollständig auf Open Source-Code basiert, schließt der Entwickler, der alles in ein System packt und bestimmte Assemblys und Einstellungen vornimmt, es im Wesentlichen. Der Code ist möglicherweise öffentlich verfügbar.
Für diese Systeme bietet die Erstellung oder Teilnahme an Open Source-Projekten eine Reihe von Vorteilen. Wie gesagt, der Endsystemcode kann gemeinfrei bleiben. Warum, denn es ist offensichtlich, dass es unwahrscheinlich ist, dass jemand das gleiche Flugzeug hat, um das System zu testen. Dies ist wahr, aber es kann durchaus jemanden geben, der einzelne Abschnitte des Codes überprüfen möchte, oder jemand kann beispielsweise feststellen, dass die verwendete Bibliothek nicht ganz richtig konfiguriert ist.
Ein noch größerer Vorteil ergibt sich, wenn das Unternehmen einen grundlegenden Teil des Systems einem separaten Projekt zuordnet. Zum Beispiel eine Bibliothek zur Unterstützung eines Datenaustauschprotokolls. In diesem Fall ist es möglich, die Kosten für die Wartung dieses Teils des Systems mit anderen Unternehmen aus diesem Bereich zu teilen, selbst wenn das Protokoll für einen bestimmten Themenbereich spezifisch ist. Darüber hinaus benötigen Spezialisten, die dieses Teil des Systems öffentlich untersuchen können, viel weniger Zeit, um es effektiv zu nutzen. Wenn Sie ein Teil als eigenständige Einheit hervorheben, das von Drittentwicklern verwendet wird, können Sie diesen Teil verbessern, da Sie effektive APIs anbieten und Dokumentation erstellen müssen. Ich spreche nicht einmal von einer Verbesserung der Testabdeckung.
Ein Unternehmen kann kommerzielle Vorteile erzielen, ohne offene Projekte zu erstellen. Es reicht aus, wenn seine Spezialisten an Projekten Dritter teilnehmen, die vom Unternehmen verwendet werden. Schließlich bleiben alle Vorteile erhalten: Die Mitarbeiter kennen das Projekt besser, nutzen es daher effizienter, das Unternehmen kann die Richtung der Projektentwicklung beeinflussen. Die Verwendung von vorgefertigtem Debug-Code senkt offensichtlich die Kosten des Unternehmens.
Die Vorteile der Erstellung von OpenSource-Projekten enden hier nicht. Nehmen wir einen so wichtigen Bestandteil des Geschäfts wie das Marketing. Für ihn ist dies ein sehr guter Sandkasten, mit dem Sie die Anforderungen des Marktes effektiv einschätzen können.
Und natürlich dürfen wir nicht vergessen, dass das OpenSource-Projekt ein effektiver Weg ist, sich als Träger einer Spezialisierung zu deklarieren. In einigen Fällen ist dies im Allgemeinen der einzige Weg, um in den Markt einzutreten. Zum Beispiel begann Embox als Projekt zur Erstellung eines RTOS. Wahrscheinlich müssen Sie nicht erklären, dass es eine Reihe von Wettbewerbern gibt. Ohne die Schaffung einer Community hätten wir einfach nicht genügend Ressourcen, um das Projekt dem Endbenutzer zur Verfügung zu stellen, dh damit Drittentwickler das Projekt verwenden können.
Die Community ist der Schlüssel zum OpenSource-Projekt. Sie können damit die Projektmanagementkosten erheblich senken, das Projekt entwickeln und unterstützen. Wir können sagen, dass es ohne Community überhaupt kein OpenSource-Projekt gibt.
Es wurden viele Materialien zum Erstellen und Verwalten einer Open Source-Projektgemeinschaft geschrieben. Um bereits bekannte Fakten nicht noch einmal zu erzählen, werde ich versuchen, mich auf die Erfahrung von Embox zu konzentrieren. Ein sehr interessantes Thema ist beispielsweise der Prozess der Schaffung einer Community. Das heißt, viele erzählen, wie man die bestehende Gemeinschaft verwaltet, aber die Momente ihrer Entstehung werden manchmal übersehen, wenn man sie als gegeben betrachtet.
Die Hauptregel beim Erstellen des Community-OpenSource-Projekts - es gibt keine Regeln. Ich meine, es gibt keine universellen Regeln, genau wie bei einer Silberkugel, schon allein deshalb, weil die Projekte sehr unterschiedlich sind. Es ist kaum möglich, dieselben Regeln zu verwenden, wenn eine Community für eine js-Protokollierungsbibliothek und einen hochspezialisierten Treiber erstellt wird. Darüber hinaus ändern sich in verschiedenen Phasen der Projektentwicklung (und damit der Community) die Regeln.
Embox begann als Studentenprojekt, da Studenten der Abteilung für Systemprogrammierung Zugang hatten. Tatsächlich gingen wir in eine andere Gemeinschaft. Teilnehmer dieser Gemeinschaft, Studenten, wir könnten an guter industrieller Praxis in ihren Fachgebieten, wissenschaftlichen Arbeiten im Bereich Systemprogrammierung, Hausarbeiten und Diplomen interessiert sein. Das heißt, wir haben eine der Grundregeln der Organisation der Community eingehalten, Community-Mitglieder müssen etwas bekommen, und dieser Preis sollte dem Beitrag des Teilnehmers entsprechen.
Die nächste Stufe für Embox war die Suche nach Benutzern von Drittanbietern. Es ist sehr wichtig zu verstehen, dass Benutzer Vollmitglieder der OpenSource-Community sind. Es gibt normalerweise mehr Benutzer als Entwickler. Und um einen Beitrag zum Projekt zu leisten, nutzen sie es zunächst auf die eine oder andere Weise.
Die ersten Benutzer für Embox waren die Abteilung für Theoretische Kybernetik. Sie schlugen vor, eine alternative Firmware für Lego Mindstorm zu erstellen. Und obwohl es immer noch lokale Benutzer waren (wir konnten uns persönlich treffen und besprechen, was sie wollen). Trotzdem war es eine sehr gute Erfahrung. Zum Beispiel haben wir Demos entwickelt, die anderen gezeigt werden können, weil Roboter Spaß machen und Aufmerksamkeit erregen. Infolgedessen hatten wir wirklich Drittanbieter, die sich fragten, was Embox ist und wie man es verwendet.
In dieser Phase mussten wir über Dokumentation und Kommunikationsmittel mit Benutzern nachdenken. Nein, natürlich haben wir vorher über diese wichtigen Dinge nachgedacht, aber es war verfrüht und wirkte sich nicht positiv aus. Der Effekt war eher negativ. Lassen Sie mich einige Beispiele nennen. Wir haben Googlecode verwendet, dessen Wiki Mehrsprachigkeit unterstützt. Wir haben Seiten in mehreren Sprachen erstellt, nicht nur in Englisch und Russisch, die schlecht kommunizieren konnten, sondern auch in Deutsch und Spanisch. Infolgedessen sah es in diesen Sprachen sehr lächerlich aus, aber wir können überhaupt nicht antworten. Oder sie führten Regeln für das Schreiben von Dokumentationen und das Kommentieren ein. Da sich die API jedoch häufig und erheblich änderte, stellte sich heraus, dass unsere Dokumentation veraltet und irreführend war, mehr als es half.
Infolgedessen führten alle unsere Bemühungen, auch nicht die richtigen, zur Entstehung externer Benutzer. Und sogar ein gewerblicher Kunde erschien, der wollte, dass er sein eigenes RTOS entwickelte. Und wir haben es entwickelt, weil wir Erfahrung und einige Entwicklungen haben. Hier müssen Sie über die guten und die schlechten Punkte sprechen. Ich werde mit den schlechten beginnen. Da viele Entwickler kommerziell an diesem Projekt beteiligt waren, trennte sich die Community und war daher ziemlich instabil, was natürlich nur die Entwicklung des Projekts beeinflussen konnte. Ein weiterer Faktor war, dass die Richtung des Projekts von einem gewerblichen Kunden festgelegt wurde und sein Zweck nicht die Weiterentwicklung des Projekts war. Zumindest war dieses Ziel nicht das Hauptziel.
Auf der anderen Seite gab es eine Reihe positiver Punkte. Wir haben wirklich Drittanbieter. Es waren nicht nur die Kunden, sondern auch diejenigen, für die dieses System bestimmt war. Die Motivation zur Teilnahme am Projekt ist gewachsen. Wenn Sie auch mit einer interessanten Angelegenheit Geld verdienen können, ist es immer schön. Und vor allem hörten wir einen Wunsch von Kunden, der uns damals verrückt vorkam, aber jetzt die Hauptidee von Embox ist, nämlich den bereits im System entwickelten Code zu verwenden. Die Hauptidee von Embox ist jetzt, Linux-Software ohne Linux zu verwenden. Das heißt, der wichtigste positive Faktor, der zur Weiterentwicklung des Projekts beitrug, war die Erkenntnis, dass das Projekt von Drittbenutzern verwendet wurde und einige ihrer Probleme lösen sollte.
Zu diesem Zeitpunkt ging Embox bereits über den Rahmen des Studentenprojekts hinaus. Das Haupthindernis für die Entwicklung des Projekts nach dem Studentenmodell ist die Motivation der Teilnehmer. Die Schüler nehmen während des Studiums teil, und wenn sie ihren Abschluss machen, sollte eine andere Motivation auftreten. Wenn keine Motivation auftritt, hört der Student einfach auf, am Projekt teilzunehmen. Wenn wir berücksichtigen, dass die Schüler zuerst ausgebildet werden müssen, stellt sich heraus, dass sie zum Zeitpunkt des Abschlusses gute Spezialisten werden, aber der Beitrag zum Projekt ist aufgrund von Unerfahrenheit nicht sehr groß.
Im Allgemeinen bewegen wir uns reibungslos zum Hauptpunkt, der es uns ermöglicht, über das Erstellen eines OpenSource-Projekts zu sprechen - das Erstellen eines Produkts, das die Probleme seiner Benutzer lösen würde. Wie ich oben erklärt habe, ist die Haupteigenschaft des OpenSource-Projekts seine Community. Darüber hinaus sind Community-Mitglieder in erster Linie Benutzer. Aber woher kommen sie bis zu dem, was sie verwenden sollen? Es stellt sich also heraus, dass Sie sich genau wie bei einem Nicht-OpenSource-Projekt auf die Erstellung eines MVP (Minimum Viable Product) konzentrieren müssen. Wenn es Benutzer interessiert, wird eine Community um das Projekt herum angezeigt. Wenn Sie nur durch Community-PR an der Schaffung einer Community beteiligt sind, ein Wiki in allen Sprachen der Welt schreiben oder einen geeigneten Git-Workflow auf Github durchführen, ist dies in den frühen Phasen des Projekts wahrscheinlich nicht von Bedeutung. In den entsprechenden Phasen sind dies natürlich nicht nur wichtige, sondern auch notwendige Dinge.
Abschließend möchte ich einen
Kommentar abgeben , der meiner Meinung nach die Erwartungen des Benutzers an das OpenSource-Projekt widerspiegelt:
Ich denke ernsthaft darüber nach, auf dieses Betriebssystem umzusteigen (probieren Sie es zumindest aus. Sie sind sehr aktiv darin, es zu sägen und coole Dinge zu tun).
PS Bei
TechTrain werden wir bis zu drei Berichte haben. Eine über Open Source und zwei über Embedded (und eine praktische). Am Stand werden wir eine Meisterklasse zum Programmieren von Mikrocontrollern mit
Embox durchführen . Traditionell bringen wir die Drüsen und lassen sie programmieren. Es wird auch eine Quest und andere Aktivitäten geben. Komm zum Festival und zu unserem Stand, es wird Spaß machen.