Inner Source

This is a cross-post from the Impala Studios internal blog

Also known as Internal Open Source or Internal Collaborative Development, Impala Studios’ recent change to a single Product Backlog is making it necessary to think about how to maintain our code and how to unify coding in such a way that we all understand each other’s code and can reuse each others work, collaboratively.

Rather than letting management set rules, I am going to try to outline a number of industry best practices that will be presented to the company via this blog and during the Friday afternoon lecture. It will then be up to the development organisation and especially the Codecraft Guild to suggest how we pick this up further.

How is this different?

At Impala Studios we went from two team backlogs with shared maintainership to a single backlog comprised of all of our products, generally in modular and micro-service pieces. You could see our Product being comprised of Apps, Frameworks, 3rd Party modules and Backend services. Each of these modules can be set up into a certain product. Alarm Clock HD for example has an iOS App with an Alarm Clock Framework on the inside. It uses several SDKs and 3rd Party modules for showing ads, collecting data, in app marketing and news and uses our own weather service to get new weather. In our current setup the entire app has one Guardian and a Product Owner but none of the modules have particular ownership.

Basically everyone owns the internally maintained code and no one owns code maintained by outside parties. This creates quite an intricate set of dependencies because the integrated product is composed of the latest version of each of its — continually updated — modules. As modules are updated, integrated products like an App will break. We are also often not aware of breakages because most of the integrations in an App are not covered by automated tests. Currently, the only way of seeing whether an App that has been in the repository for a while still works, is by making and testing the current build and then fixing what we find.

With Innersourcing, the Alarm Clock HD would have an ‘owner’ — namely the Product Owner — but guardianship would now go to each module. Teams would now be responsible for all of the modules that have guardians within their team. Changes to these modules can still be made by everyone, however the team that has guardianship of the module has final approval. The guardian team ensures that it makes a new version of their module that is then available for new builds from then on with a dependency handler like Cocoapods.

Learning from Examples

Google — 2 Billion Lines of Code

Probably the largest example of a single product that uses innersourcing is Google’s implementation. All 25,000 engineers at Google can access almost all the 2 Billion lines of code in just one repository! Things that we could learn from Google:

• They have their code in ‘directories’ that are owned by a team.
• Any change can be made by any developer but outside a directory, your changes have to be approved by the owners.
• Branching — they have a ‘trunk based’ or ‘release branch’ model. A snapshot of the master branch is made, as late as possible, and new features are developed on this. If the master gets updated with something necessary for development, this can be ‘cherry picked’ into the release branch (because of its size, they don’t even have the option of staying synced with the master branch). The release branch is what makes it to production. We could consider GitLab Flow and of course, version freezing with CocoaPods.
• They have code coverage by unit tests that are run at every commit.
• They use pull requests and automated deployment for code reviewing.

Paypal — the edge between Open Source and Inner Source

There are many companies that have always been active in the Open Source community, not as many that have changed from Proprietary or Inner Source and even Open Source. Google and Facebook have part of their code under Open Source licenses, the Apache foundation and Ubuntu/Canonical have completely community-based software.

Paypal was a latecomer to the scene but since the beginning 2014 have adopted Inner Source whilst they started transitioning from Java to JavaScript and Node.js on their kraken.js project. They noticed that to contribute to many projects, they had to adopt a new way of working. One important change was the move to GitHub and the use of Git. The other was to agree on quality standards such as unit testing. Lastly, they noticed that Open Source contributors work distributed, whereas they were moving to co-located teams. The disadvantages of face-to-face communication were that there was no documentation trail for those that did not know the software, they had to learn to use the readme.txt, changelog.txt and to have civilised online, open discussions in their git comments. The communication with outside contributors forced this somewhat as kraken.js was Open Source.

An in-depth look at Inner Source at Paypal is available on O’Reilly.

Things we could learn:

• Use Bitbucket for documentation, readme, changelog and issue tracking.
• Promote quality standards and way of working to introduce unit tests on shared code.
• Civilised, open communication about changes.
• Open Source as much as possible and engage with the community.

Starting on the Inner Source road.

If we want to do Inner Source at Impala Studios, we probably need to handle a few things first:

• Change guardianship to cover all shared modules: Apps, Frameworks, 3rd Party Libraries and Services.
• Publish and make visible which teams are trusted committers for which modules.
• Incrementally make modules modular, buildable and testable.
• Incrementally make documentation in the repository.

Once that is in place, we could:

• Start contributing to the Open Source modules we use.
• Open Source some of our proprietary software.