Open Source gewonnen. Im Kampf zwischen Software, die offen von jedem erstellt wurde, der etwas beitragen möchte, und denen, die in geschlossenen Läden starr codiert sind, war es kein Wettbewerb. Wenn Sie Closed-Source-Software verwendet und neue Funktionen enthalten oder Fehler behoben haben wollten, mussten Sie warten, bis sich das Produkt ändert, sich darüber beschweren oder eine Problemumgehung entwickeln, in der Hoffnung, dass die Änderung eines Tages in das Produkt einfließt. Mit Open Source können Sie selbst daran teilnehmen, indem Sie Änderungen und Verbesserungen anbieten, solange Sie zeigen, dass Sie bereit sind, Teil ihrer Community zu sein.
Diese geschlossenen Softwareshops beginnen, sich Notizen zu machen und Open Source in ihren Prozess zu integrieren. Unternehmen öffnen nicht nur immer mehr Teile ihres benutzerdefinierten Stapels, sondern integrieren auch die Techniken und Prozesse, die Open Source so erfolgreich machen.
Dies wird InnerSource genannt: Open-Source-Softwareentwicklung innerhalb einer Unternehmens-Engineering-Organisation. Es ist eine aufregende Veränderung in der Art und Weise, wie Software erstellt wird, und gibt einzelnen Mitwirkenden die Möglichkeit, bedeutende Änderungen außerhalb ihres Silos vorzunehmen. Um einen besseren Eindruck davon zu bekommen, wie diese Praktiken in der realen Welt aussehen, haben wir mit Danese Cooper, Gründer und Vorsitzender von InnerSource Commons und langjähriger Open-Source-Verfechter, gesprochen.
Offene Prozesse hinter verschlossenen Türen
Als Open-Source-Software populär wurde, befürchteten viele, dass sie zu mehr Fehlern, Sicherheitslücken und anderen Problemen führen würde. Es wurde jedoch festgestellt, dass Open-Source-Codebasen Fehler langsamer erzeugen als geschlossene. „Das Geheimnis der Open-Source-Methode ist ihre Transparenz. “Viele Augen machen kleine Arbeit mit allen Käfern”, sagte Cooper.
Wenn Sie viel Zeit damit verbracht haben, Ihren eigenen Text zu überprüfen, sei es beim Schreiben oder Coden, haben Sie wahrscheinlich die Erfahrung gemacht, einfache Fehler zu übersehen, weil Sie mit dem Text zu vertraut sind. Wenn Sie es erneut lesen, sehen Sie, was in Ihrem Kopf vorgeht, nicht auf dem Bildschirm. Wenn Open-Source-Arbeitsstile über InnerSource in einen geschlossenen Shop integriert werden, bekommen Sie viele neue Augen auf Ihre Arbeit, und diese Augen sehen am Ende die Probleme, die Sie übersehen haben. Neben dem Erkennen von Fehlern können neue Perspektiven auch neue Lösungen oder Optimierungen einführen. Dies ist möglich, weil InnerSource ein offenes Beitragsmodell bevorzugt. Jeder in einem beliebigen Team kann einige Änderungen in einen Pull-Request einfügen und vom Product Owner überprüfen lassen, damit sie in das Produkt aufgenommen werden. Wie bei vielen Open-Source-Projekten bedeutet dies nicht, dass es für alle kostenlos ist. Jede Codebasis – sei es ein Service innerhalb einer größeren serviceorientierten Architektur, ein Feature innerhalb eines Monolithen oder ein Produkt innerhalb der Produktsuite eines Unternehmens – verfügt über eine Reihe von vertrauenswürdigen Committern, Personen, die alle Commits überprüfen und für die Produktion freigeben.
Vertrauensvolles Engagement ist der Schlüssel zum Prozess. Zunächst müssen Sie möglicherweise Ihren besten Entwicklern die Rolle des Mentors und der Überprüfung/Genehmigung von Commits übertragen, anstatt Code zu schreiben, was so aussieht, als würden Sie sie untätig sitzen lassen. „Ich empfehle, 10 % Ihrer Ingenieursbelegschaft zu einem vertrauenswürdigen Engagement zu verpflichten“, sagte Cooper. „Wenn Sie diese 10% nicht haben, werden Sie in Schwierigkeiten geraten, wenn InnerSource beginnt.“
