Introduction to AWS DevOps – InnerSource Model

Overview

InnerSource is the term that refers to the emerging practice of organizations that adopt open source methodology, albeit to develop proprietary software. This blog will discuss the Inner-Source ecosystem, which leverages multiple AWS services. Services such as CodeCommit, CodeGuru, CodeBuild, CodeArtifact, CodePipeline, and some other AWS services and open source tools.

Exploring InnerSource and its Uniqueness

Nowadays, most IT organizations leverage open source software (OSS) in their products. It is an excellent mechanism for standardizing software and bringing cost-effectiveness via reusing high-quality, time-tested code. Whereas some organizations may allow its use as-is, others may utilize a vetting mechanism to ensure that the OSS adheres to the organization’s security quality, standards, etc. The OSS stems from how these community projects are managed and sustained and the culture of openness, collaboration, and creativity they nurture.
And many organizations building closed-source software are now trying to imitate these development principles and practices. Perhaps this approach is more discussed than adopted and is popularly called “InnerSource.”

InnerSource is an excellent tool for collaborative software development within the organization’s scope while keeping its concerns for IP and legality in check. It offers avenues for collaboration and innovation across organizational boundaries by sharing knowledge and talent. Organizations are reaping the benefits of better code quality and quicker time to market but at a fraction of the cost. 

What composes an InnerSource Ecosystem?

Infrastructures and processes that harbor collaborations stand at the heart of InnerSource ecology. These systems include many supporting tools and features: peer reviews, code hosting, issue tracking, communication & collaboration, Pull Request (PR) approval flow, documentation, automated testing, and continuous integration. There is a significant component in this system, an entry portal that enables the feature for employees to discover the projects based on InnerSource and also join the communities, begin as an ordinary user of the reusable code, and later on graduate the contributors and committers.

InnerSource System to enable a development workflow and Infrastructure

InnerSource thrives on community collaboration and a low entry barrier to enable adaptability. Whereas it should be strategically decided for the projects that if it can be InnerSourced and has a correct licensing model, Businesses should bootstrap the initiatives with seed products that can draw its community, maintainers, and the first set of contributors. Through a meritocracy-based system, many of these users would eventually be promoted to become trusted committers.

The organizations should plan to move from an infra-specific model to a project-specific one over time. In a project-specific InnerSource model, a dedicated team funded by other business units is responsible for a specific software asset. While under the infrastructure-based InnerSource model, the organization provides the infrastructure to create the ecosystem with code and document repositories, communication tools, and so on. It enables anybody from the organization to create new InnerSource projects, whereas the project initiators manage and maintain their own projects. The value of modular architecture in InnerSource projects cannot be understated. This architecture helps the developers better understand the code, and aids code reuse and parallel development, wherein multiple contributors can work on different code modules, avoiding conflicts during code merges.

InnerSource Model Solution

The ultimate purpose of this model solution is to allow a developer workflow as depicted. 

At the core of the InnerSource verse is the distributed version control (AWS CodeCommit in our case). And to maintain system transparency, openness, and participation, we must have a discovery mechanism where users can search for the projects and receive encouragement from contributing to the one they prefer.

The model solution uses an open-source reference implementation of InnerSource Portal. The portal indexes AWS CodeCommit data through a crawler and lists available projects with associated metadata, such as the required skills, average number of commits, and number of active branches. In AWS CodeCommit, we can use the crawler implementation available at the AWS open source code repository. 

Conclusion

Every organization may not be able to integrate InnerSource right away, but it is a great step towards encouraging a culture of quality and innovation and purging silos throughout enhanced collaboration. Backing from leadership support is required to sponsor the engineering initiatives and promote an open, transparent culture that allows developers from across the organization to contribute to projects outside of their teams. Organizations that have already participated in open-source initiatives are the best suited for InnerSource. They Have an engineering team who is adept with CI/CD tools and is willing to participate in OSS practices.

Enterprises are now adopting the open source culture to develop proprietary software by creating an InnerSource, which puts transparency, innovation, and collaboration that results in cost efficiencies & helps to build quality software. In this blog, we are discussing a model solution that helps build and develop the workflow inside an InnerSource ecosystem, including project discovery to deployment and PR approval.

About CloudThat