Inner source, a term debuted in 2014 at OSCON, refers to applying open source concepts within the organization. In simple terms it is allowing contributors/ engineers of some other team contribute to the code base owned by a your team. For the teams owning critical domain and business struggling to get their idea/initiative prioritized due to limited engineering capacity, this model might just save the day. By allowing contributors/engineers you team to contribute to projects impacting your domain you increase the workforce without hiring( Managers know the pain of getting headcount 🙂). Now this might feel like someone intruding in your territory without understanding the domain and might feel daunting. There are many concerns, “How will we ensure the quality” “ how will we support the code/workflow once the contributor is gone”, “ How will the work align to the north star vision of the team” etc. However using a proper process and discipline this model will allow the domain to accomplish more without compromising its core values.

1. Define the structure/process

• Assign a domain lead from the team to the contributor from the external team for every project to avoid the distraction to the entire team. You might decide to keep the same domain lead across the projects or a different lead for each.

• Define and document the key processes that the contributor needs to follow strictly. Design review, PR review, test case review, code quality standards, rollout guidelines etc

• Over communication is good in this case. Communicate the expectations clearly to avoid any confusion. Be transparent to all the teams involved like engineering, product management and project management.

2. Clarity in responsibilities.

If you are the assigned domain lead supporting the contributor

• You are the gatekeeper for the team and responsible for the quality delivered.

• Understand the initiative/task that the contributor from external team is going to work on.

• Be aware of the expectations and timelines related to the task/initiative. Having said that, the contributor is responsible for managing the timelines.

• Ensure that the contributor follows all the processes defined.

• Primary point of contact for the contributor. The domain lead could seek help from the team if/as needed.

• Ensure that any tech-debt/improvement created as a part of the project is documented and followed up on by the contributor. Dont sign off till then else your team will own the tech debt.

• While the domain lead might not have expertise in all the areas or is able to answer all the questions, guide the contributor in right direction to find the answers.

If you are the contributor contributing to other domain

• Strictly follow all the processes defined by the team. If you don’t agree to a particular process or have ideas for improvement, work with the domain lead instead of deciding to change it yourself.

• Drive the the task/initiative. You are responsible for driving the designs, resolving open issues, managing timelines and expectations, participating in status update meetings, bugs triage meeting and anything else.

• Keep domain lead updated with the progress and the plan.

• Contributors to send the regular project updates to the domain lead(optional : scrum lead and manager of the domain).

In a nutshell, the contributor is responsible for the delivery and domain lead is the gate keeping of the team ensuring the quality of the work.

3. Think about the effort

If some other team is contributing to the initiative in your domain, is the effort/scope for your team zero? Absolutely NO!! Please scope the effort based on your domain and experience of the member contributing. Keep in mind the responsibilities of the domain lead pointed out above what determining the effort.

Hoping this article helps you to have an open mind to the concept and acts as a starting point to define the model that works the best for your team. Happy Inner sourcing..!!