Schon 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 außer Acht lassen. Daher trägt einer unserer Vorträge den Titel . Dieser wird der Entwicklungsgeschichte von Embox als Open-Source-Projekt gewidmet sein. In diesem Artikel möchte ich die wichtigsten Ideen darlegen, die meiner Meinung nach die Entwicklung von Open-Source-Projekten beeinflussen. Der Artikel basiert, ähnlich wie der Vortrag, auf persönlichen Erfahrungen.
Lassen Sie uns mit einer einfachen Definition des Begriffs Open Source beginnen. Ein Open-Source-Projekt ist offensichtlich ein Projekt, das unter einer der Lizenzen steht, die den Zugang zum Quellcode des Projekts ermöglichen. Darüber hinaus impliziert ein Open-Source-Projekt die Möglichkeit von Änderungen durch externe Entwickler. Das bedeutet, dass, wenn ein Unternehmen oder Entwickler den Quellcode seines Produkts, entweder teilweise oder vollständig, veröffentlicht, dies das Produkt noch nicht zu einem Open-Source-Projekt macht. Und schließlich sollte jede Projektaktivität zu einem greifbaren Ergebnis führen, wobei die Offenheit des Projekts bedeutet, dass dieses Ergebnis nicht nur von den Entwicklern selbst genutzt wird.
Wir werden die Probleme offener Lizenzen nicht ansprechen. Das ist ein zu großes und komplexes Thema, das tiefere Einsichten erfordert. Zu diesem Thema gibt es bereits viele gute Artikel und Materialien. Aber da ich kein Fachmann im Urheberrecht bin, kann ich nur sagen, dass die Lizenz zu den Zielen des Projekts passen sollte. Zum Beispiel war die Wahl von BSD statt GPL-Lizenz für Embox nicht willkürlich.
Die Tatsache, dass ein Open-Source-Projekt Veränderungen ermöglichen und dessen Entwicklung beeinflussen soll, bedeutet, dass das Projekt verteilt ist. Es ist deutlich schwieriger, es zu verwalten, die Integrität und Funktionalität aufrechtzuerhalten, verglichen mit einem zentral gesteuerten Projekt. Daraus ergibt sich die berechtigte Frage, warum man überhaupt Open-Source-Projekte durchführen sollte. Die Antwort liegt im Bereich der kommerziellen Nützlichkeit: Für eine bestimmte Klasse von Projekten überwiegt der Nutzen dieses Ansatzes die Kosten. Das heißt, nicht für alle Projekte ist ein offener Ansatz geeignet und grundsätzlich möglich. Es ist zum Beispiel schwer vorstellbar, ein System zur Steuerung eines Kraftwerks oder eines Flugzeugs auf einem offenen Prinzip basieren zu lassen. Natürlich sollten in solche Systeme Module integriert werden, die auf Open-Source-Projekten basieren, da dies eine Reihe von Vorteilen mit sich bringt. Doch für das Endprodukt muss jemand die Verantwortung übernehmen. Selbst wenn das System vollständig auf dem Code von Open-Source-Projekten basiert, schließt der Entwickler, der alles in ein System integriert und spezifische Builds und Konfigurationen erstellt, dieses letztlich ab. Der Code kann dabei jedoch öffentlich zugänglich bleiben.
Für diese Systeme gibt es ebenfalls viele Vorteile, wenn man an offenen Projekten teilnimmt oder solche erstellt. Wie bereits erwähnt, kann der Code des Endsystems öffentlich zugänglich bleiben. Warum? Schließlich ist es nicht wahrscheinlich, dass jemand ein identisches Flugzeug hat, um das System zu testen. Das stimmt, aber es könnte durchaus Personen geben, die bestimmte Teile des Codes überprüfen möchten, oder beispielsweise könnte jemand feststellen, dass die verwendete Bibliothek nicht ganz korrekt konfiguriert ist.
Noch größere Vorteile ergeben sich, wenn ein Unternehmen einen bestimmten Basisteil des Systems in ein separates Projekt ausgliedert. Zum Beispiel eine Bibliothek zur Unterstützung eines bestimmten Datenübertragungsprotokolls. In diesem Fall, selbst wenn das Protokoll spezifisch für einen bestimmten Fachbereich ist, können die Kosten für die Wartung dieses Systemteils mit anderen Unternehmen aus diesem Bereich geteilt werden. Darüber hinaus benötigen Fachleute, die diesen Systemteil öffentlich studieren können, viel weniger Zeit für eine effektive Nutzung. Und schließlich ermöglicht die Auslagerung eines Teils zu einer eigenständigen Einheit, die von externen Entwicklern genutzt wird, diese Komponente qualitativ hochwertiger zu gestalten, da effektive APIs angeboten, Dokumentationen erstellt und ich spreche noch nicht einmal von der Verbesserung der Testabdeckung.
Unternehmen können kommerzielle Vorteile erzielen, ohne eigene Open-Source-Projekte zu erstellen. Es reicht aus, wenn ihre Fachleute an externen Projekten teilnehmen, die im Unternehmen eingesetzt werden. Die Vorteile bleiben bestehen: Die Mitarbeiter kennen das Projekt besser und nutzen es somit effizienter. Das Unternehmen kann die Richtung der Projektentwicklung beeinflussen, und die Nutzung von bereits optimiertem Code reduziert offensichtlich die Kosten.
Die Vorteile der Erstellung von Open-Source-Projekten enden hier jedoch nicht. Nehmen wir einen weiteren wichtigen Aspekt des Geschäfts, das Marketing. Hier bietet sich eine hervorragende Testumgebung, um die Marktbedürfnisse 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 positionieren. In einigen Fällen ist es sogar der einzige Weg, um auf den Markt zu gelangen. Zum Beispiel begann Embox als Projekt zur Erstellung eines Betriebssystems. Es bedarf wohl keiner Erklärung, dass es jede Menge Konkurrenz gibt. Ohne den Aufbau einer Gemeinschaft hätten wir schlichtweg nicht die Ressourcen gehabt, um das Projekt bis zu den Endnutzern zu bringen, sprich, damit das Projekt von externen Entwicklern genutzt wird.
Die Gemeinschaft ist der Schlüssel zu einem Open-Source-Projekt. Sie ermöglicht eine erhebliche Reduzierung der Projektmanagementkosten und unterstützt die Entwicklung und den Fortbestand des Projekts. Man kann sagen, dass es ohne eine Gemeinschaft im Grunde kein Open-Source-Projekt gibt.
Es gibt zahlreiche Materialien darüber, wie man eine Community für ein Open-Source-Projekt aufbaut und verwaltet. Um bekannte Fakten nicht zu wiederholen, möchte ich den Fokus auf die Erfahrungen von Embox legen. Ein sehr interessantes Thema ist der Prozess der Gemeinschaftsbildung. Viele erklären, wie man eine bestehende Gemeinschaft verwaltet, aber die Aspekte der Gründung werden oft übersehen, da man dies als selbstverständlich annimmt.
Das Hauptprinzip bei der Schaffung einer Community für ein Open-Source-Projekt ist, dass es keine Regeln gibt. Damit meine ich, dass es keine universellen Regeln gibt, ebenso wenig wie eine Silberkugel, denn die Projekte sind sehr unterschiedlich. Mit denselben Regeln lässt sich kaum eine Community für eine Logging-Bibliothek in JS und einen hochspezialisierten Treiber aufbauen. Darüber hinaus ändern sich die Regeln in verschiedenen Phasen der Projektentwicklung (und damit auch der Community).
Embox begann als Studentenprojekt, da wir Zugang zu den Studierenden des Instituts für Systemprogrammierung hatten. Im Grunde genommen traten wir in eine andere Community ein. Wir konnten die Mitglieder dieser Community, die Studierenden, durch gute industrielle Praktika in ihrem Fachgebiet und wissenschaftliche Arbeiten im Bereich Systemprogrammierung, Projekte und Diplomarbeiten interessieren. Das heißt, wir hielten uns an eines der grundlegenden Regeln für die Organisation einer Community: Die Mitglieder müssen etwas gewinnen, wobei dieser Preis dem Beitrag des Teilnehmers entsprechen sollte.
Der nächste Schritt für Embox war die Suche nach externen Nutzern. Es ist wichtig, zu verstehen, dass die Nutzer vollwertige Mitglieder der Open-Source-Community sind. In der Regel gibt es mehr Nutzer als Entwickler. Um Contributor eines Projekts zu werden, muss man es zuerst irgendwie verwenden.
Die ersten Nutzer von Embox waren die Mitarbeiter des Lehrstuhls für Theoretische Kybernetik. Sie schlugen vor, eine alternative Firmware für Lego Mindstorm zu entwickeln. Auch wenn es sich um lokale Nutzer handelte (wir konnten sie persönlich treffen und besprechen, was sie wollten), war es dennoch eine sehr wertvolle Erfahrung. Zum Beispiel entwickelten wir Demos, die man anderen zeigen konnte, denn Roboter sind spannend und ziehen Aufmerksamkeit an. Letztendlich hatten wir tatsächlich externe Nutzer, die begannen zu fragen, was Embox ist und wie man es nutzen kann.
In dieser Phase mussten wir über die Dokumentation und die Kommunikationsmittel mit den Nutzern nachdenken. Natürlich haben wir uns auch vorher über diese wichtigen Aspekte Gedanken gemacht, aber es war zu früh und brachte keinen positiven Effekt. Der Effekt war eher negativ. Ein paar Beispiele: Wir haben Google Code verwendet, dessen Wiki Mehrsprachigkeit unterstützte. Wir haben Seiten in mehreren Sprachen erstellt, nicht nur in Englisch und Russisch, mit denen wir mehr schlecht als recht kommunizieren konnten, sondern auch in Deutsch und Spanisch. Das Resultat war sehr seltsam, wenn Fragen in diesen Sprachen gestellt wurden, auf die wir überhaupt nicht antworten konnten. Oder wir hatten Regeln für das Schreiben von Dokumentationen und Kommentaren eingeführt, aber da sich die API ziemlich oft und erheblich änderte, stellte sich heraus, dass unsere Dokumentation veraltet war und mehr verwirrte, als half.
Letztendlich haben all unsere Bemühungen, selbst die nicht ganz richtigen, dazu geführt, dass externe Nutzer entstanden. Es gab sogar einen kommerziellen Auftraggeber, der wollte, dass wir ein eigenes OSR für ihn entwickeln. Und das haben wir auch getan, da wir Erfahrung und einige Vorarbeiten hatten. Hier muss ich sowohl über die guten als auch über die schlechten Momente sprechen. Ich beginne mit den schlechten. Da viele Entwickler auf kommerzieller Basis an diesem Projekt beteiligt waren, war die Gemeinschaft insgesamt recht instabil und gespalten, 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 Weiterentwicklung des Projekts war. Zumindest war dieses Ziel nicht vorrangig.
Andererseits gab es eine Reihe positiver Aspekte. Wir haben tatsächlich externe Nutzer gewonnen. Es waren nicht nur die Auftraggeber, sondern auch diejenigen, für die dieses System gedacht war. Die Motivation zur Teilnahme an dem Projekt ist gestiegen. Schließlich ist es immer angenehm, wenn man mit einer interessanten Tätigkeit auch noch Geld verdienen kann. Das Wichtigste ist jedoch, dass wir einen Wunsch der Auftraggeber gehört haben, der uns damals absurd erschien, jetzt aber die zentrale Idee von Embox ist: bereits entwickelten Code in das System zu integrieren. Derzeit besteht die Kernidee von Embox darin, Linux-Software ohne Linux zu verwenden. Das heißt, ein wesentlicher positiver Aspekt, der zur weiteren Entwicklung des Projekts beitrug, war das Bewusstsein, dass das Projekt von externen Nutzern genutzt wird und bestimmte Probleme lösen muss.
Zu diesem Zeitpunkt hatte sich Embox bereits über das Niveau eines studentischen Projekts hinausentwickelt. Der Hauptfaktor, der das Wachstum des Projekts nach dem studentischen Modell hemmt, ist die Motivation der Teilnehmer. Studierende engagieren sich, solange sie studieren, aber nach ihrem Abschluss muss eine andere Motivation entstehen. Wenn diese Motivation nicht entsteht, hören die Studierenden einfach auf, am Projekt teilzunehmen. Berücksichtigt man, dass die Studierenden zunächst ausgebildet werden müssen, wird deutlich, dass sie zum Zeitpunkt ihres Abschlusses gute Fachkräfte sind, jedoch aufgrund ihrer Unerfahrenheit nur einen begrenzten Beitrag zum Projekt leisten.
Im Grunde genommen kommen wir jetzt zum zentralen Punkt, der die Schaffung eines Open-Source-Projekts ermöglicht: die Entwicklung eines Produkts, das die Probleme seiner Nutzer löst. Wie ich bereits erwähnt habe, ist das Hauptmerkmal eines Open-Source-Projekts seine Gemeinschaft. Die Mitglieder dieser Gemeinschaft sind in erster Linie die Nutzer. Doch woher sollen sie kommen, wenn es noch nichts gibt, was sie nutzen können? Es zeigt sich also, dass man, ähnlich wie bei einem nicht-Open-Source-Projekt, auf die Schaffung eines MVP (Minimal Viable Product) fokussieren sollte. Wenn dieses Produkt die Nutzer anspricht, wird sich eine Gemeinschaft um das Projekt bilden. Wenn man jedoch versucht, eine Gemeinschaft lediglich durch PR, das Schreiben von Wiki-Artikeln in allen Sprachen oder die richtige Git-Workflow auf GitHub zu schaffen, wird das in den frühen Phasen des Projekts wahrscheinlich keine Bedeutung haben. Natürlich sind diese Aspekte in den entsprechenden Phasen nicht nur wichtig, sondern notwendig.
Abschließend möchte ich anführen , meiner Meinung nach spiegelt es die Erwartungen der Nutzer an ein Open-Source-Projekt wider:
Ich denke ernsthaft über einen Wechsel zu diesem Betriebssystem nach (zumindest um es auszuprobieren. Es wird wirklich viel damit gearbeitet und es werden beeindruckende Dinge gemacht).
P. S. Auf Wir haben gleich drei Vorträge. Einen über Open Source und zwei über Embedded-Systeme (davon einer praktisch). Am Stand führen wir einen Masterclass über die Programmierung von Mikrocontrollern mit Hilfe von . Traditionell bringen wir Hardware mit und lassen die Teilnehmer selbst programmieren. Es wird auch ein Quiz und andere Aktivitäten geben. Kommen Sie zum Festival und an unseren Stand, es wird Spaß machen.
Quelle: habr.com
