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? In order to gather people interested in the topic we tried as best as we could to use the same principles and tooling that we were suggesting InnerSource projects should adopt.
Recently more and more people who have been watching this initiative from a farther distance have started asking how this was done. As a personal rule of thumb - for every question I receive more than twice I will write the answer down and make it available via a URL that can be accessed as publicly as possible. That’s the goal of this blog post series. (Though honestly, originally I thought it wouldn’t be more than a short post. Describing all the bigger and smaller patterns that we are using did take more than a handful of blog posts to write down…)
Those patterns, best practices and lessons learnt will be published here in the coming weeks. Have fun reading:
- Voting in new Trusted Committers … how do we find and activate new contributors and turn them into Trusted Committers
- Checklist for internal meetups … internal meetups should be as remote friendly as possible. What do we need for that?
- Checklist for base documentation … which base documentation should we think about when starting a project?
- Issues - for brainstorming … issues not only as digital versions of sticky notes, but also for brainstorming
- Issues - for tracking work and asking questions … tracking work, asking questions, further use cases for issues
- Lazy consensus … avoid waiting endlessly by adopting lazy consensus for non-controversial changes
- Templates to drive standards … pilot recommendations locally, derive a template from the successful pilot, only then roll that pilot out as a standard to others
- External tools? … GitHub only? By far not - if appropriate switch to another tool, but link your content together for better findability. Careful: Search gets harder the more tools you introduce.