Remote-First mit InnerSource
innersource

Remote-First mit InnerSource

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.

Using templates to drive standards
innersource

Using templates to drive standards

(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?

Europace's journey to InnerSource
innersource

Europace's journey to InnerSource

Europace is a network-centric organization within a network of organizations (Hypoport). It uses the self-organization framework Holacracy as its operating system—loosely coupled, autonomous teams are working together for a common purpose. But with autonomy also comes a trend towards self-sufficiency. In the years after starting with self-organization we experienced a lot of “reinventing the wheel” instead of company-wide collaboration. In order to find a way out of this dilemma we looked at the open source world, especially on how collaboration works in such a distributed world.

Lazy consensus vs explicit voting
innersource

Lazy consensus vs explicit voting

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.

Issue Use Cases
agile

Issue Use Cases

(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.

Using issues for brainstorming
innersource

Using issues for brainstorming

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.

Meetup organisation
innersource

Meetup organisation

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.

InnerSource: Adding base documentation
innersource

InnerSource: Adding base documentation

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.

Voting in new Trusted Committers
innersource

Voting in new Trusted Committers

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.

Running an InnerSource initiative
innersource

Running an InnerSource initiative

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?

innersource

InnerSource für alle - Europace goes GitHub Enterprise Cloud

Europace und andere Gesellschaften aus dem Hypoport-Netzwerk setzen schon länger auf die Vorteile von InnerSource mit GitHub als Plattform. Um in dem schnell wachsenden Verbund von Unternehmen diese offene Form der Zusammenarbeit auch in Zukunft zu gewährleisten, nutzt Hypoport jetzt GitHub Enterprise Cloud. So haben die autonomen Teams und Gesellschaften von Hypoport die Möglichkeit ihren Code in eigenen GitHub-Organisationen zu verwalten, ohne den Zugang zu den Repositories der anderen Teams zu verlieren.

Europace InnerSource Prinzipien
konferenz

Europace InnerSource Prinzipien

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.

Lessons learnt - Github Review Workflow
innersource

Lessons learnt - Github Review Workflow

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.

InnerSource - nicht nur für Entwickler
innersource

InnerSource - nicht nur für Entwickler

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.