Diese Woche findet in St. Petersburg ein IT-Festival statt . Einer der Redner wird Richard Stallman sein. nimmt auch am Festival teil, und natürlich konnten wir das Thema Freie Software nicht außer Acht lassen. Deshalb heißt einer unserer Berichte . Es wird der Geschichte der Entwicklung von Embox als Open-Source-Projekt gewidmet sein. In diesem Artikel möchte ich über die wichtigsten Ideen sprechen, die meiner Meinung nach die Entwicklung von OpenSource-Projekten beeinflussen. Der Artikel basiert, wie auch der Bericht, auf persönlichen Erfahrungen.
Beginnen wir mit etwas Einfachem, mit der Definition des Begriffs OpenSource. Offensichtlich ist ein Open-Source-Projekt ein Projekt, das über eine der Lizenzen verfügt, die den Zugriff auf den Quellcode des Projekts ermöglicht. Darüber hinaus bedeutet ein offenes Projekt, dass Drittentwickler Änderungen vornehmen können. Das heißt, wenn ein Unternehmen oder Entwickler den Code seines Produkts teilweise oder vollständig veröffentlicht, macht dies dieses Produkt noch nicht zu einem Open-Source-Projekt. Und schließlich muss jede Projektaktivität zu einem Ergebnis führen, und die Offenheit des Projekts impliziert, dass dieses Ergebnis nicht nur von den Entwicklern selbst genutzt wird.
Wir werden nicht auf die Probleme offener Lizenzen eingehen. Dies ist ein zu großes und komplexes Thema, das einer eingehenden Untersuchung bedarf. Zu diesem Thema wurden viele gute Artikel und Materialien geschrieben. Da ich selbst jedoch kein Experte auf dem Gebiet des Urheberrechts bin, kann ich nur sagen, dass die Lizenz den Zielen des Projekts entsprechen muss. Beispielsweise war die Wahl einer BSD- statt einer GPL-Lizenz für Embox kein Zufall.
Die Tatsache, dass ein Open-Source-Projekt die Möglichkeit bieten sollte, Änderungen vorzunehmen und die Entwicklung des Open-Source-Projekts zu beeinflussen, impliziert, dass das Projekt verteilt wird. Die Verwaltung sowie die Aufrechterhaltung von Integrität und Leistung ist im Vergleich zu einem Projekt mit zentraler Verwaltung wesentlich schwieriger. Es stellt sich die berechtigte Frage: Warum öffnen Projekte überhaupt? Die Antwort liegt im Bereich der kommerziellen Machbarkeit; für eine bestimmte Klasse von Projekten überwiegen die Vorteile dieses Ansatzes die Kosten. Das heißt, es ist nicht für alle Projekte geeignet und ein offener Ansatz ist grundsätzlich akzeptabel. Es ist beispielsweise schwer vorstellbar, ein Steuerungssystem für ein Kraftwerk oder ein Flugzeug nach einem offenen Prinzip zu entwickeln. Nein, natürlich sollten solche Systeme Module enthalten, die auf offenen Projekten basieren, da dies eine Reihe von Vorteilen bietet. Aber jemand muss für das Endprodukt verantwortlich sein. Auch wenn das System vollständig auf dem Code offener Projekte basiert, schließt der Entwickler es im Wesentlichen, nachdem er alles in ein System gepackt und spezifische Builds und Einstellungen vorgenommen hat. Der Code ist möglicherweise öffentlich verfügbar.
Es gibt auch viele Vorteile für diese Systeme, wenn sie Open-Source-Projekte erstellen oder dazu beitragen. Wie ich bereits sagte, bleibt der Endsystemcode möglicherweise öffentlich verfügbar. Warum, denn es ist offensichtlich, dass es unwahrscheinlich ist, dass jemand das gleiche Flugzeug hat, um das System zu testen. Das stimmt, aber es kann durchaus sein, dass jemand bestimmte Abschnitte des Codes überprüfen möchte oder beispielsweise feststellt, 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 zuweist. Zum Beispiel eine Bibliothek zur Unterstützung eines Datenaustauschprotokolls. In diesem Fall können Sie, selbst wenn das Protokoll spezifisch für einen bestimmten Themenbereich ist, die Kosten für die Wartung dieses Teils des Systems mit anderen Unternehmen aus diesem Bereich teilen. Darüber hinaus benötigen Spezialisten, die diesen Teil des Systems im öffentlichen Bereich studieren können, viel weniger Zeit, um ihn effektiv zu nutzen. Und schließlich können wir durch die Aufteilung eines Teils in eine unabhängige Einheit, die von Drittentwicklern verwendet wird, diesen Teil verbessern, da wir effektive APIs anbieten und Dokumentation erstellen müssen, und ich spreche nicht einmal über die Verbesserung der Testabdeckung.
Ein Unternehmen kann kommerzielle Vorteile erzielen, ohne Open-Source-Projekte zu erstellen; es reicht aus, wenn seine Spezialisten an im Unternehmen verwendeten Drittprojekten teilnehmen. Schließlich bleiben alle Vorteile erhalten: Die Mitarbeiter kennen das Projekt besser und nutzen es daher effektiver, das Unternehmen kann die Richtung der Projektentwicklung beeinflussen und die Verwendung von vorgefertigtem, debuggtem Code senkt offensichtlich die Kosten des Unternehmens.
Die Vorteile der Erstellung von Open-Source-Projekten enden hier nicht. Nehmen wir einen so wichtigen Bestandteil des Geschäftslebens wie das Marketing. Für ihn ist dies eine sehr gute Sandbox, die es ihm ermöglicht, Marktanforderungen effektiv zu bewerten.
Und natürlich dürfen wir nicht vergessen, dass ein OpenSource-Projekt eine wirksame Möglichkeit ist, sich als Träger einer beliebigen Spezialisierung zu deklarieren. In manchen Fällen ist dies die einzige Möglichkeit, in den Markt einzusteigen. Embox begann beispielsweise als Projekt zur Erstellung eines RTOS. Dass es viele Konkurrenten gibt, muss wohl nicht erklärt werden. Ohne die Schaffung einer Community hätten wir einfach nicht über genügend Ressourcen verfügt, um das Projekt zum Endbenutzer zu bringen, d. h. damit Drittentwickler mit der Nutzung des Projekts beginnen können.
Die Community ist der Schlüssel in einem OpenSource-Projekt. Es ermöglicht Ihnen, die Projektmanagementkosten erheblich zu senken, das Projekt zu entwickeln und zu unterstützen. Wir können sagen, dass es ohne eine Community überhaupt kein OpenSource-Projekt gibt.
Es wurde viel Material darüber geschrieben, wie man eine Open-Source-Projekt-Community erstellt und verwaltet. Um nicht bereits bekannte Fakten noch einmal zu erzählen, werde ich versuchen, mich auf die Erfahrung von Embox zu konzentrieren. Beispielsweise ist der Prozess der Gründung einer Community ein sehr interessantes Thema. Das heißt, viele sagen, wie man eine bestehende Gemeinschaft verwaltet, aber die Momente ihrer Entstehung werden manchmal übersehen, wenn man dies als gegeben betrachtet.
Die Hauptregel beim Erstellen einer OpenSource-Projektgemeinschaft ist, dass es keine Regeln gibt. Ich meine, es gibt keine allgemeingültigen Regeln, genauso wie es kein Allheilmittel gibt, schon allein deshalb, weil die Projekte sehr unterschiedlich sind. Es ist unwahrscheinlich, dass Sie beim Erstellen einer Community für eine JS-Protokollierungsbibliothek und einen hochspezialisierten Treiber dieselben Regeln verwenden können. Darüber hinaus ändern sich die Regeln in verschiedenen Entwicklungsstadien des Projekts (und damit der Community).
Embox begann als Studentenprojekt, da es Zugang zu Studenten aus der Abteilung für Systemprogrammierung hatte. Tatsächlich betraten wir eine andere Gemeinschaft. Wir könnten die Teilnehmer dieser Gemeinschaft, Studenten, für gute industrielle Praxis in ihrem Fachgebiet, wissenschaftliche Arbeiten im Bereich der Systemprogrammierung, Studienleistungen und Diplome interessieren. Das heißt, wir folgten einer der Grundregeln der Organisation einer Community: Community-Mitglieder müssen etwas erhalten, und dieser Preis muss dem Beitrag des Teilnehmers entsprechen.
Der nächste Schritt für Embox war die Suche nach Drittnutzern. Es ist sehr wichtig zu verstehen, dass Benutzer vollwertige Teilnehmer der OpenSource-Community sind. Normalerweise gibt es mehr Benutzer als Entwickler. Und um an einem Projekt mitwirken zu wollen, beginnen sie zunächst, es auf die eine oder andere Weise zu nutzen.
Die ersten Nutzer von Embox waren die Abteilung für Theoretische Kybernetik. Sie schlugen vor, eine alternative Firmware für Lego Mindstorm zu erstellen. Und das, obwohl es sich immer noch um lokale Nutzer handelte (wir konnten sie persönlich treffen und besprechen, was sie wollten). Aber es war trotzdem eine sehr gute Erfahrung. Wir haben zum Beispiel Demos entwickelt, die man anderen zeigen kann, denn Roboter machen Spaß und erregen Aufmerksamkeit. Als Ergebnis bekamen wir echte Drittbenutzer, die zu fragen begannen, was Embox ist und wie man es verwendet.
In dieser Phase mussten wir über die Dokumentation und die Kommunikationsmittel mit den Benutzern nachdenken. Nein, über diese wichtigen Dinge haben wir natürlich schon vorher nachgedacht, aber das war verfrüht und hat keinen positiven Effekt gebracht. Der Effekt war eher negativ. Lassen Sie mich Ihnen ein paar Beispiele nennen. Wir haben Googlecode verwendet, dessen Wiki Mehrsprachigkeit unterstützt. Wir haben Seiten in mehreren Sprachen erstellt, nicht nur Englisch und Russisch, in denen wir uns kaum verständigen konnten, sondern auch Deutsch und Spanisch. Daher sieht es in diesen Sprachen sehr lächerlich aus, aber wir können überhaupt nicht antworten. Oder sie führten Regeln zum Schreiben von Dokumentationen und Kommentieren ein, aber da sich die API häufig und erheblich änderte, stellte sich heraus, dass unsere Dokumentation veraltet und eher irreführend als hilfreich war.
Infolgedessen führten alle unsere Bemühungen, auch die falschen, zum Auftauchen externer Benutzer. Und es meldete sich sogar ein kommerzieller Kunde, der sich für ihn ein eigenes RTOS entwickeln lassen wollte. Und wir haben es entwickelt, weil wir Erfahrung und einige Grundlagen haben. Hier müssen Sie sowohl über die guten als auch die schlechten Momente sprechen. Ich fange mit den schlechten an. Da viele Entwickler auf kommerzieller Basis an diesem Projekt beteiligt waren, war die Community bereits recht instabil und gespalten, was sich natürlich auf die Entwicklung des Projekts auswirken musste. Hinzu kam, dass die Richtung des Projekts von einem gewerblichen Kunden vorgegeben wurde und sein Ziel nicht die Weiterentwicklung des Projekts war. Zumindest war dies nicht das Hauptziel.
Andererseits gab es eine Reihe positiver Aspekte. Wir haben echte Drittbenutzer. Es waren nicht nur die Kunden, sondern auch diejenigen, für die dieses System gedacht war. Die Motivation, am Projekt teilzunehmen, ist gestiegen. Denn wenn man mit einem interessanten Geschäft auch noch Geld verdienen kann, ist das immer schön. Und vor allem haben wir von Kunden einen Wunsch gehört, der uns damals verrückt vorkam, heute aber die Hauptidee von Embox ist, nämlich bereits entwickelten Code im System zu verwenden. Die Hauptidee von Embox besteht nun darin, Linux-Software ohne Linux zu verwenden. Das heißt, der wichtigste positive Aspekt, der zur Weiterentwicklung des Projekts beitrug, war die Erkenntnis, dass das Projekt von Drittbenutzern genutzt wird und einige ihrer Probleme lösen sollte.
Zu diesem Zeitpunkt war Embox bereits über den Rahmen eines Studentenprojekts hinausgegangen. Der wichtigste limitierende Faktor bei der Entwicklung des Projekts nach dem Studentenmodell ist die Motivation der Teilnehmer. Studierende beteiligen sich während des Studiums, und wenn sie ihren Abschluss machen, sollte es eine andere Motivation geben. Wenn keine Motivation auftritt, beendet der Student einfach die Teilnahme am Projekt. Berücksichtigt man, dass die Studierenden zunächst ausgebildet werden müssen, stellt sich heraus, dass sie bis zum Abschluss gute Fachkräfte sind, ihr Beitrag zum Projekt jedoch aufgrund ihrer Unerfahrenheit nicht sehr groß ist.
Im Allgemeinen kommen wir problemlos zum Hauptpunkt, der es uns ermöglicht, über die Erstellung eines Open-Source-Projekts zu sprechen – die Schaffung eines Produkts, das die Probleme seiner Benutzer löst. Wie ich oben erklärt habe, ist die wichtigste Eigenschaft eines OpenSource-Projekts seine Community. Darüber hinaus sind Community-Mitglieder in erster Linie Benutzer. Aber woher kommen sie, wenn es nichts zu gebrauchen gibt? Es stellt sich also heraus, dass Sie sich, genau wie bei einem Nicht-Open-Source-Projekt, auf die Erstellung eines MVP (Minimum Viable Product) konzentrieren müssen, und wenn es Benutzer interessiert, entsteht eine Community rund um das Projekt. Wenn Sie eine Community nur durch Community-PR erstellen, ein Wiki in allen Sprachen der Welt schreiben oder den Git-Workflow auf Github korrigieren, ist dies in den frühen Phasen des Projekts unwahrscheinlich. Natürlich sind das in den entsprechenden Phasen nicht nur wichtige, sondern auch notwendige Dinge.
Abschließend möchte ich darauf hinweisen Meiner Meinung nach spiegelt es die Erwartungen der Benutzer an ein Open-Source-Projekt wider:
Ich denke ernsthaft darüber nach, auf dieses Betriebssystem umzusteigen (versuche es zumindest. Sie verfolgen es aktiv und machen coole Dinge).
PS: An Wir werden bis zu drei Berichte haben. Eines über Open Source und zwei über Embedded (und eines ist praktisch). Am Stand führen wir einen Meisterkurs zur Programmierung von Mikrocontrollern durch . Wie gewohnt bringen wir die Hardware mit und lassen Sie diese programmieren. Außerdem wird es eine Quest und andere Aktivitäten geben. Kommen Sie zum Festival und an unseren Stand, es wird Spaß machen.
Source: habr.com