pattern/service-vs-library

[MaineC]

I would like to propose an idea for an inner source pattern - not sure if others have seen similar issues in their organisation.

Imagine the following situation: We are looking at an organisation that values devops as an approach to software development and deployment. Teams are responsible end to end: Starting with requirements engineering, software development down to deployment and maintenance, support etc.

Team A has developed service lovelyTree. Team B has a business issue, that could be solved by re-using lovelyTree, except they need a few modifications. When cross team collaboration and inner source is brought to the table, both teams are reluctant to collaborate - it's unclear who should get the wakeup call for the service, also error handling and communication chains are different for both teams.

The solution is to remind the team that this is about inner source, not inner deployment: Much like in open source, the same source code can be deployed in more than one context while still sharing the bulk of the code in one common service (or one common library that encapsulates the business logic).

This is related to the 30-day-warranty pattern, except it gives a bit more flexibility in a micro-services world.

Risk: This pattern breaks in a setup where one team has a vested interest in providing their software as a common service to others, e.g. when trying to collect data to feed into some machine learning training pipeline.

[rrrutledge]

Sounds interesting

[NewMexicoKid]

Isabel, I would encourage you to write this up in a pattern format.

[chchrist]

@MaineC we have a team that developed a service that acts as a facade for another third party SaaS so in the future we could switch to a new same type SaaS without much overhead. Now other teams want to start using this service but the original team does not want to be responsible for problems that other teams might introduce. Does the above pattern fits this case? Does that mean that each new team will have to deploy their own service that does something similar?

[lenucksi]

@MaineC we have a team that developed a service that acts as a facade for another third party SaaS so in the future we could switch to a new same type SaaS without much overhead. Now other teams want to start using this service but the original team does not want to be responsible for problems that other teams might introduce. Does the above pattern fits this case? Does that mean that each new team will have to deploy their own service that does something similar?

Hey @chchrist, thanks for bringing this up! 👍
I think given the short form of "InnerSource not InnerDeployment" this might be interesting. There is also a mention of the "30 days of warranty" pattern in the linked PR discussion that might be of interest to you.

I've also posted a link to your question to our Slack - you are very much invited to join there for more discussion.