Isabel Drost-Fromm

Im Bereich von Open Source Projekten ist es bereits seit Jahrzehnten üblich, im Unternehmensbereich seit einigen Jahren mehr und mehr verbreitet - mit der Pandemie wurde es plötzlich in der Breite zum Alltag: Remote First. Vieles ist anders, manches neu - aber in vielen Aspekten kann man bei der Umstellung von erfolgreichen Open Source Projekten lernen. Einen ersten Einblick in Best Practices gibt die Augustausgabe des Java Magazins. Mit dabei: Patterns und Erkenntnisse, die uns bei Europace in der Entwicklung geholfen haben, Projekte auf remote-first umzustellen - und im gleichen Atemzug Silos abzubauen und Teams näher zusammenzurücken.

We published our experience with standard InnerSource project documentation as well as issue tracker usage as regular InnerSource patterns

(German version below) It was right at the beginning of the Corona crisis in Europe - a day after Easter to be precise - that the InnerSource Summit EU was scheduled to take place in Madrid. Pretty early on we realized that it was unlikely that the summit would be like any other summit. So a decision as made, to move it to a virtual event. Long story very short: The event was very well attended, talks were awesome - in particular attendee interaction during breakout sessions was a great addition.

InnerSource projects rely heavily on a certain set of core tools. However for several tasks it makes sense to use additional dedicated tools.

I love Free Software day 2020 (German version below) Simply saying thank you - something we often forget in the day to day flood of tasks, accountabilities and responsibilities. Today the Free Software Foundation Europe is celebrating the “I love free software day” to express gratitude to those who are underpinning a lot of today’s businesses by developing Free and Open Source Software. Much as last year we would like to join the celebration and say thank you to the developers backing the software that makes our platform perform well on a daily basis.

(German version below) Imagine the following situation: Some team has found a best practice for solving an issue - e.g. they’ve identified that in their projects they are using the same setup over and over again. It would make sense to not only share that best practice with others but establish a standardized way of working around it. But what if others aren’t yet encountering this issue? How should they judge whether the suggested standard is a good idea or whether having a standard around it makes any sense at all?

Knapp 450 Stunden - die Zeit die es bräuchte, um alle Vorträge der FOSDEM 2020 die letztes Wochenende in Brüssel stattfand, anzuschauen. Von Legal and Policy, über Container und Security, Datenbanken, Netzwerk, Java, Go, Quantum Computing, Continuous Integration bis hin zu Embedded/ Automobile und Open Source Design reichte die Themenbreite. Dieses Jahr hat die FOSDEM gezeigt, dass nicht nur technische Themen für den Bereich Open Source entscheidend sind. Im Community and Ethics Main Track hat Danese Cooper gezeigt, welche Schritte notwendig sind, um auf kommunaler Ebene für die Adaption von Freier und Open Source Software zu sorgen.

Imagine the following situation: You would like to drive a change in the gh#innersource repository. You already have commit access. Typically you’d make the change, post it as a pull request and wait until someone has time to review and approve. (German version below) There is another way that we typically choose when the change is relatively uncontroversial: In the original pull request, indicate that the model for the change is a lazy consensus model where the pull request is kept open for a defined number of days - and if nobody objects, it will get merged after this period is passed.

(German translation below) … for asking questions In addition to tracking decisions in the making issues are being used for those who would like to ask InnerSource related questions. Asking them in the issue tracker instead of in 1-on-1 settings has three advantages: There’s more than one knowledgeable individual that can answer the question. Others who may have the same question later on (or even now, in case they are afraid to ask the question) see that there are others who openly learn something new.

Imagine the following situation: You’ve seen a certain discussion pop up multiple times and would like to draw the lessons learned together - but in a way that leaves space for others to provide their knowledge and experience. One setup that turned out to be effective for this type of situation in gh#innersource was the following workflow: Open an issue, post the problem statement at the very top and invite people to discuss steps towards a solution of the stated problem.

For the introduction of InnerSource at Europace we relied on gathering a group of people interested in the topic. While most of the discussion is designed to be remote-first with all issues being discussed in an asynchronous way we also set up an internal monthly InnerSource meetup. That meeting is open to each and everyone for attending. Meeting dates, location, and agenda is posted in advance: In a GitHub issue dedicated to the particular meeting in the gh#innersource project, On the Slack channel with the same name as the GitHub project (slack#innersource), As a calendar invite to those attending regularly and to those who participated the last time.

Starting the InnerSource initiative we needed a place to collect documentation as well as a place for operational coordination. We decided to dogfood suggested tooling and created a GitHub repository. Going forward, I will refer to it as gh#innersource here. Before publicly discussing gh#innersource as a project, a certain amount of base documentation was being created. As a baseline this meant creating an initial README.md. This document serves as an entry point for newcomers to the project.

Trusted committers are the ones responsible not only for software development but also for mentoring, for pulling new people into the project, for helping and supporting downstream users with the goal of adding them to the Trusted Committer team. But how do you go about adding new Trusted Committers? The way this works in the InnerSource project at Europace is that for people showing obvious commitment, one of the existing Trusted Committers will step forward, nominating them as a potential new Trusted Committer - giving a short explanation of why.

Leading by example - how we introduced InnerSource and coordinated adoption of InnerSource best practices inside of Europace. In Adopting InnerSource we described how we were following what Vijay Gurbani (Vijay K. Gurbani, Anita Garvert, and James D. Herbsleb, “Managing a Corporate Open Source SoftwareAsset,” Communications of the ACM 53, no. 2 (2010) 155–159.) describes as an infrastructure based model of introducing InnerSource to a new organisation. What does that mean?

Benjamin Weigel: “Eleganz entsteht nicht durch clever genutzte Workarounds, sondern durch richtig verwendete Features. Wenn es das Feature noch nicht gibt und der Bedarf da ist, dann baut man es eben.” Konkret zum Beispiel in den Projekten Cython und serverless-python-requirements. Auch bei Europace setzen wir bei der Entwicklung unserer Plattform für Baufinanzierungen und nahestehenden Finanzprodukten auf eine Reihe von Open Source Projekten. Über einige Einsatzgebiete, Tools, und unsere Erfahrungen damit berichten wir hier im Tech Blog.

Entscheidungen für alle zugänglich treffen, Transparenz auch in einer wachsenden Organisation schaffen, Autonomie und Kollaboration in Balance bringen, Teams und Verantwortung organisch wachsen lassen: InnerSource kann ein Mittel sein, Teams in wachsenden Organisationen bei der Zusammenarbeit zu unterstützen, und helfen Silos abzubauen. Die Kollaborationsmuster sind so alt wie die OpenSource Bewegung selbst: “Open source focuses on the practical consequences enabled by these licenses: surprisingly effective collaboration on software development.” (opensource.com). Das sind dieses Jahr 20 Jahre.

In den letzten Wochen haben wir etwas genauer auf unsere Github Workflows geschaut. Dabei sind uns einige Patterns aufgefallen, die in vielen Projekten die Zusammenarbeit einfacher gemacht haben, die wir hier teilen wollen. Reviews, Pairing, Sparring Partner Konvention vs. Empfehlung Manche Teams haben zwar informell die Konvention, dass aller Quellcode nach dem vier-Augen-Prinzip entweder im Pair entwickelt wird oder durch ein Review läuft, brechen aber in der Praxis in Einzelfällen mit dieser Konvention.

Am 25./26. August fand an der Hochschule Bonn-Rhein-Sieg in Sankt Augustin die 13. Ausgabe der Free and Open Source Conference statt. Europace war im Vortragsprogramm mit einem Beitrag zum Thema “InnerSource: Open Source collaboration patterns beyond public FOSS projects” dabei, in dem wir unsere Erfahrungen mit InnerSource geteilt haben. Lesson learnt im Rahmen der Fragen im Anschluss an die offizielle Q&A Session: Betrachtet man die Konzepte von InnerSource für ein international zergliedertes Unternehmen, kann es aufgrund interner Verrechnungsprozesse oder steuerrechtlicher Gegebenheiten einfacher sein, ein Projekt direkt als Open Source Projekt zu führen.

Wir haben im April über unsere ersten Schritte in Richtung InnerSource berichtet. Diesmal wollen wir einen Einblick in die Fortschritte in den letzten Monaten geben. Wir haben im Rahmen eines Epics, an dem Vertreter von zwei unserer Units gearbeitet haben, unsere gemeinsame Arbeitsweise weiterentwickeln können. Im Rahmen einer anschließenden Retrospektive haben wir die folgenden Erfahrungen notiert: Besonders Änderungen, von denen viele Stakeholder betroffen sind (prominentes Beispiel hier sind Änderungen an zentralen Schnittstellen) dauern bei einer rein asynchronen Arbeitsweise sehr lange.

InnerSource bedeutet, Prozesse, Erfarhungen und Best Practices aus der Open Source Entwicklung ins Unternehmen zu holen. Bei Europace haben wir im Laufe des vergangenen Jahres insbesondere bei der teamübergreifenden Zusammenarbeit erfolgreich auf InnerSource gesetzt.

Nicht erst im Zuge der Selbstorganisation wählen Teams in ihrer täglichen Arbeit immer wieder Open Source Projekte als technologische Basis für ihre Arbeit aus. Welche Fragen man sich bei dieser Auswahl stellen kann, fasst dieser Artikel zusammen.

Zu voll, zu viele Schlangen, zu wenig Platz - viele freundliche Leute, Belgische Waffeln, Eis, ein ASF Dinner mit den Apache Weisen und einigen neuen Gesichtern, alle paar Schritte gute Freunde treffen die man sonst oft jahrelang nur online sieht, viel zu viele gute Vorträge, um sie alle zu sehen und aufzunehmen: Meine persönliche Zusammenfassung der diesjährigen FOSDEM. Meines Wissens ist die FOSDEM das größte Treffen von Leuten im Umfeld Freier Software das in Europa stattfindet.